One of the most important metrics for the effectiveness of a software development team is one that I often find managers pay little attention to. The metric is how much time developers actually spend coding.
If our goal as software developers is to produce features in software then our process has to support us by allowing us time to create those features. But oftentimes I find that writing software is just a part of the software developer’s duties in many companies. Developers are also responsible to attend meetings, write test plans, interpret requirements and dozens of other duties. Some developers that I know spend so much time in meetings that they actually can’t get their work done and have to code during their lunch hour because the rest of their day is packed with other responsibilities.
It only makes logical sense that if you’re not given a lot of time to write software then you won’t write much software. The other thing that I find, which is almost universally true is that most software developers would prefer to be writing software then doing just about anything else. Writing code is what we do. It’s how we create value. And we know it. Forcing a developer to go to work but not write code is like keeping a racehorse in the stables all day. We want to get out and flex our muscles.
This is one of the main reasons that I am an advocate for Extreme Programming practices. Virtually all the Extreme Programming practices resolves to some form of writing software. One of the central practices of XP is test-driven development which is not a testing activity but really a developer activity. It’s writing software in the form of tests.
Doing TDD greatly reduces the amount of other non-coding work that developers have to do. Unit tests call software the way that they are intended to be used so we find that there is much less need to write internal programmer documentation for the code that we’re developing and that’s great because who likes writing internal programmer documentation? Very few.
We also find that when we have unit tests supporting us as we’re developing software, we make far fewer mistakes so were spending less time debugging code and more time writing code. We developers like that as well.
When software developers recognize that doing test-first development has us doing more development and less activities aren’t coding then they tend to get really on board with doing TDD on projects.
So, how much time should developers spend writing software every day? In some ways this is an individual decision but I think it’s very unrealistic to assume that an average software developer will write code for eight hours every day five days a week. That is an unrealistic expectation for managers to place on developers or for developers to place on themselves. Writers don’t write starting at 8 AM and ending at 5 PM every day with a break for lunch in between. Some days the ideas flow and others they don’t.
If I get four good hours of focused work done a day then I’m really happy. Of course, I’m an old guy and when I was younger I could put in eight hours or 10 hours or even 12 hour days on occasion. I don’t think many of us could do this consistently without burning out, but like many young people I could burn the midnight oil for several days in a row before I needed to take breaks.
Today, I believe that if we want to have a true industry around developing software then it has to be sustainable. Overtime and long hours can’t be the norm or we will burn out. We have to treat our profession like a real profession. Additionally, study after study has proven that when you take a developer and you make them work long, hard hours that the number of bugs that they produce increases exponentially and that ultimately slows the project down even more.
I generally believe that it makes more sense for us to measure our software development process rather than measuring individuals because very often it’s our process that has the most room for improvement. When I’m looking to measure the efficiency of a software development process the very first place I start is by asking how much quality time do your developers spend actually writing code. I find that by increasing the quality of the time or the quantity of the time, we can get a lot of low hanging fruit for improving the efficiency of a software development process.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Measure Time-to-Value
Next Post: Measure Defect Density »