Things almost never take the amount of time we initially think they will, do they?
Programming is no exception. We can sorta kinda figure out how long a task will take to complete using yesterdays weather, but todays weather is complicated.
Here is the dirty secret. Well, it isn’t all that secret.
Developers work long hours, often late into the night toward the end of a development cycle, to get things done. Done as in something that can be shipped. This isn’t because of estimate problems, though they certainly don’t help. This usually isn’t because of misunderstanding scope, there are many ways to solve that problem.
The work never gets done on time because the programmers can’t get it done on time. There are too many impediments for them to do the work.
Let’s talk about that.
Lean uses the phrase ‘touch time’ to describe the amount of time over the life of a project that people are actually working. I mean, ‘hands on the keyboard’, value-add work. Stuff that moves the project forward and closer to the customers hands.
This number is usually depressingly low.
The usual suspects
There are plenty of phenomena that slow the work down: hand offs, churning work between groups, and waiting in queues.
Handoffs occur when work has to change hands between groups that operate completely independently. Churn is the nasty result of handoffs, this happens when there are misunderstandings and mistakes that happen when work is traded between groups like you see in games of telephone. Waiting is what you do when you can’t do anything. Usually this means that you’re waiting on someone else to finish their part so you can begin on yours.
Disruptions are probably the king of productivity killers for programmers. They come in many forms: meetings, required status updates, people walking by asking questions here and there, email, and instant messengers. Disruptions are the reason programmers get next to nothing done during the day and end up making pull requests at 3 am when their family is asleep and they finally have quiet time.
Regularly scheduled meetings can ruin full days.
In past lives a normal day saw me getting to the office around 8 or 8:30 am, I’d go over what I did the day before and see what was coming up today in time for scrum at 930. It wasn’t uncommon to have some sort of meeting between scrum and the lunch break. Depending on the day, there might be one or two more meetings before the official day ends.
That example looks pretty extreme in print, but it definitely happened many many times. Having that happen during the second half of a sprint. I’m sure you can imagine how much project work got done on days like this, very little.
The problem isn’t really the meetings, meetings are of course work too. The real problem is the time slicing.
Orchestrating the work
The book Artful Making: What Managers Need to Know About How Artists Work isn’t actually a book about artists. It is a book that draws parallels between traditionally creative work like theater to programming and technical work. Programming work is often thought of as technical, and very structured but the reality is that good programming is creative. It takes time and sometimes mental gymnastics to design and implement solutions to problems on demand every day.
The point is that managing programmers like assembly line workers that can do each task in an exact known amount of time is old and wrong.
When putting a a play or performance together, the group gets a script or sheet music. That is only words or notes on paper though. The script isn’t the play in the same way that the spec isn’t the software.
Interpretation and creation are happening at most steps in putting together a production and building software.
Understanding that software isn’t a Ford Model T rolling down the assembly line having bits and pieces added is a good place to start.