Just the other day a colleague of mine started a small rant of how little time in a development project that was actually writing & fixing code. I think the final crescendo was a Tweet that read:
“My dream is simple. One day, developers can spend their time on actual development..”
It seems that developers don’t riot in the street, they post a message on Twitter or Facebook. Anyway, the nerd-rage was released and so we went back to our tasks as usual.
Could this actually be a problem?
Thinking a bit more about this I got struck by how often this aspect of the development process is ignored. Even when talking about efficient and lean processes we hardly ever discuss how the time is actually spent within sprints, tasks or days. Maybe it never made the cool-aid list, I don’t know.
Looking back on some projects, how much time was spent coding and troubleshooting the code-base (i.e. delivering business value) and how much time was spent handling deployments, redeployments, dependencies, classloader issues, external integrations and configuration? None of the latter actually contributed to any business value, but were nothing but a time sink that prevented you to be productive.
Here’s an example; I worked on a project for a big company a while ago that used a JEE container (Glassfish). The start up procedure for the server took about 15 minutes. I kid you not. This was due to failing external integration components that was not trivial to track down (we did manage to get this down to about 1-2 minutes after a while). Even if the wait process is just 30 second, what happens? I and many people I know will open a browser to check the mail or something similar and just like that you have lost track of your thoughts and you have a context switch in your head.
A deceptive problem here is that you get used to it so quick. Oh, 5 minutes start up time, well I just get up and get a coffee every time I need to start up the server. 7 minutes compilation time? Ah, time for the (first) daily dose of reddit.com. You start to accept the way things are handled, the time they take and you adjust your flow for it.
What’s the typical response when you work in a project with a system like that? “Well, yes, it is a somewhat complicated setup.” Indeed. I understand the undesired need for complexity sometimes, but I have never heard the cost of this complexity for the development process being discussed.
Nor have I ever seen any attempt to measure this.
In theory it would be relatively simple, just place a guy with a stop-watch next to a developer and time him for a day. Figure out the relative time spent coding and the relative time spent trying to get the latest maven snapshot dependency work with the different class loaded from within JBoss (or similar tasks). Hmm, perhaps a stopwatch guy would would not go well with the developers, so maybe it is not that simple, but you can at least have them estimate the time spent in the various tasks. Make this cost visible and transparent for everyone (especially for the system architect, head of development or CTO that may not be aware of this cost and could work pro-actively to fix it).
Agile? Lean? TDD?
There has been a lot of focus on the development process the last x years, from one side we have all the latest and greatest processes and methods from Agile and Lean. These are great tools in helping us to work on what produces the most business value. But it does not focus on the effectiveness of the day-to-day production in the aspect of this article.
On a lower level we have XP and TDD. Neither of these really addresses how your time is spent, continuous integrations may set the bar higher and incite you find a quick integration and rapid feedback cycle, but there is nothing inherent in them that lifts out and makes the costs of slow cycles visible. TDD will help you focus on the coding process when TDD is applicable. TDD is awesome for coding a linked list or any other type of isolated logic but if you are, god help you, trying to fetch a data source from JNDI in a JBoss container that is wrapped by a third party lib mashed into the container without any respect to the forces of nature, then TDD will probably not help you very much.
Then we have the personal productivity tools such as Pomodoro. These are great for letting you focus and work continuously on a task, but once again they do nothing for the transparency of what you are actually spending your time with.
Efficiency?
Imagine a company that would actually address this and work actively with it. By introducing better integrations, easier setups, configurations etc etc I think that a 10% overall boost in productivity would be very easy to gain. If you have 10 developers then this is comparable to an additional resource working full time. With domain knowledge. From day one. Imagine that 😉
Solutions?
Make the cost transparent. The first step would be to actually try and get a feel for how much time is wasted in non-productive development related tasks (sounds easy right?). But here is the crux, what is non-productive and what should consider part of the regular development process? Naturally, this is something that will differ from companies and projects, but if you can find a measurement for this I think there is much time and money to be saved. Not to mention how much more enjoyable the whole developing process will become for everyone involved!
That’s the end of my rant. Sound off in the comments!
You can contact him at: fredrik.johansson(at)cubeia.com