In my last post, I championed both feature prioritization and cost/benefit analysis as essential ingredients in achieving software results, with results defined as generating the greatest possible value for the investment in programmer time. But just how much “programmer time” does your organization really posses?
More often than not, during tight economic times – like what we are experiencing today – many companies not only cut costs (and typically this means people), but they also focus their attention in two seemingly contradictory ways:
1. “Doing more with less.”
2. Asking for more innovation and creativity from their employees.
Can software projects meet these two demands? You can – if you understand your true programming capacity in relation to your planning.
My experience is that most software projects are trying to do too much with the staff that they have. Instead of “doing more with less,” I feel that your motto should be: “Decrease time spent on low-value work and increase time spent on high-value work.” Yes, it’s a bit of a qualifier, but I advocate concentrating your efforts on performing more high-value work with the reduced staff that you have in order to improve results.
Ask yourself the following questions: How good is your organization about meeting project schedules? Are you hitting your dates with quality code? Are your programmers contributing in innovative and creative ways? Do your users feel that they are receiving value from the software that you deliver? If you are achieving all of these things, congratulations!
One common complaint that is often voiced with software projects is that developers are optimistic when it comes to estimating, but they aren’t the only ones guilty of this. I’ve seen entire organizations believe in schedules that they really shouldn’t. This ultimately leads into heads-down, aggressive programming and testing, with no time left over for anything but the essentials. Innovation and creativity take a back seat to the schedule.
The main problem is that many people believe that they have more programming capacity than they really do. Consider how project schedules are typically created. Many times, programming estimates are provided in days or hours. Do you schedule – and subsequently plan and bank on – eight productive hours per day, per programmer? I hope not! At my company, we recognized that interruptions and general “administrivia” will get in the way. At one point we attempted to use six-hour days as our “ideal developer day” for planning purposes, but this didn’t work out.
One simple reality is that there are hours in a day, and then there are productive hours. This isn’t just a programmer problem. It surfaces in any white-collar work. While your actual experience may vary, mine has demonstrated that four genuinely productive programming hours per day is the norm. Why? Because there is more to programming than coding; things like thinking and designing come into play. I’m interested to hear what your thoughts are.
Another problem stems from the abuse of the word “estimate.” Unless the same person is writing same application that they wrote last week, estimates should be viewed as an approximation, a ballpark. There is a uniqueness to every development project that makes defining exactly how long it will take to deliver a feature (or set of features) difficult to determine with great precision.
While this can be mitigated by ensuring that the requirements are very precise and that sufficient time to design the feature(s) has been provided, the tendency is to short-change this process and hold programmers accountable for meeting their “commitments.” This situation is in part why Agile development has taken root.
Also consider the following: If you want programmers to contribute in creative and innovative ways, they need time to keep up with technology, to understand the task at hand, and to think about and collaborate with others in applying technology. If people are pulling out all of the stops to meet aggressive deadlines, there won’t be any think time available.
I have another data point related to the scarcity of available programming – specifically the amount of programming that you should expect – that I find extremely interesting: Lines of code per day. No, I am not attempting to measure productivity! This is all about pointing out the scarceness of programming resources.
An industry example is Microsoft Vista. From what I have read, Vista comprises approximately 50 million lines of code. Reports seem to vary on this, but the typical programmer on Vista is said to have produced an average of about 8-20 lines of code per day, with a maximum reaching 50 lines of code per day. Using 230 working days per year as an average, we’re talking about 4,600 lines of code per year, per typical programmer (if you use the figure of 20 lines of code per day). I’ve seen other estimates that put the average lines of code per programmer on Vista nearer to 5 lines of code per day, or about 1,150 lines of code per year, per programmer.
If these numbers sound low to you, take a hard look at the realities in your company. And remember that there is more to programming than just producing code; For example, the problem domain needs to be understood and design work has to take place. Poorly-designed code that does not meet the business need will result in waste and more defects that must be fixed before the software is deemed usable. (Consider the knocks Vista has taken in the marketplace.)
To summarize, programming is a complex, detailed undertaking that requires a lot of planning, designing, and old-fashioned thinking. Programmers need to be working on those projects that provide the highest possible value, period. And don’t waste their time, there is so little available to waste!