I work 8 hours per day. If I’m in a normal mood and health and averagely motivated, I spend only 2 to 6 hours per day developing software, with average of 4 hours per day. The rest time I spend on other activities.

This is an absolutely deliberate decision of mine.

I can only be productive so many hours a day. If I would try to force me and develop software in my unproductive state, I would create more bugs than software. This effect is widely known among software developers and many cool names are assigned to that, for example the Flow that can happen in the Zone, in The Cave.

No matter how you call it, the lenght of the Flow can be trained: the best software developers I’ve even seen could develop software productively 6 – 7 hours a day on average, in a course of several weeks. The worst programmers I’ve ever met could only bring a half an hour once during the whole week.

Experience and training not only raise Flow duration, but also deepens understanding of the process: novice programmers don’t even feel when they are in the Flow and when not. Somewhat experienced developers can tell Flow zone apart of unproductive time, but would force themselves to work outside of the Flow time, sometimes because of a wrong understood discipline or loyalty, and sometimes in a hope to engage the next Flow period. And the most experienced developers would just switch and do something else.

There are plenty things to do. Communicating, documenting, specifying, installing, testing, participating in UI design and in business concept creation, trying out new things or just catching up with the news. Not that those things don’t require to be creative, but they require different brain parts than software development. And most of those things are either expected to be done anyway, or can be done by software developer and would bring additional profit to the company (as opposed to spending unproductive time with surfing on the Facebook or coffee klatching).

By being consequently self-disciplined and replacing software development outside of the Flow zone with these other activities, experienced software developers raise their efficiency (in terms of ROI on their salary).

So that is undoubtfully a Good Thing.

Having agreed on that, two logical consequences of mis-management can be considered.

The first one is that you cannot speed up software development by increasing working time. One can cleary see that increasing working time can only increase the time outside of the Flow, so that less experienced developers would produce additional bugs (but not additional software), and more experienced developers would produce more documentation or tests, but not software. The burn out after a couple of weeks will complete the desaster. The very best outcome of overtime are bugs that look like a usable software in the short-term perspective (so called clickdummies or throw-away code), which might have sense sometimes. Fortunately, most of people know about this effect and generally consider overtime as a “no go”. Many software developer contracts here in Germany prohibit overtime explicitely (you may not regularly work more than 40 hours a week), and that’s good thing too.

Another consequence is not that much known: you cannot speed up software development by freeing up the software developer from some of his non-development activities. Speaking of me as an example, I need 2 to 6 hours per day of a non-development tasks to fill up the time outside of my Flow. If you free me from some of those tasks, it doesn’t mean my Flow time will increase and I would produce software more quickly. No, it would only mean I will have to find out and do some other, may be less important, non-development tasks.

The only really working way to speed up software development is to increase the average Flow time. Speak with your software developer to find out more about how to do that.