In My Framework is More Productive than Your Framework, Ken DeLong examines approaches to making software projects more productive. He finds that despite the hype about frameworks, languages, and project management tools, these tend not to be the bottlenecks. Ken believes that the largest productivity gains are likely to come from improved communication, code readability and debugability.
From the Theory of Constraints, we know that the only way to substantially increase productivity is to attack the bottlenecks. Gains made in other areas will still be dominated and subsumed by the bottleneck constraint.
Ken notes that frameworks often tout how easy it is to get a project set up and ready for real development. Certainly this is useful, but over the life of a project, the setup time is not likely to be significant.
Another area of optimization that is likely to have only minor impact on productivity is reducing the time it takes to write code. While certain languages, frameworks or programming techniques can significantly reduce the amount of code that must be written, this is not likely to translate into big productivity gains for the project.
This is where I get really suspicious of "expressive" programming languages. There are many ways to be "expressive" - which typically means cramming large amounts of functionality on a single line. Those who have struggled with reading "expressive" Perl or C might care to comment about how wonderful it is to have the whole program on a single line of code. I would assert that readability of code is orders of magnitude more important that writeability.
A recent poster on Stack Overflow appeared to want to improve productivity by hiring coders who could type fast. Respondents indicated that typing speed was an irrelevant metric for judging the productivity of developers, and warned against using a typing test as part of the interviewing process. In Pair Programming Misconceptions, Martin Fowler points out that pair programming increases productivity, not reduces it, in part because typing is not the hardest part of programming.
After pointing out things that are not likely to be the bottleneck constraint for developers, Ken goes on to discuss several areas that are more likely to be, including: communication with business stakeholders, understanding preexisting code, and debugging.
Ken says: "Trying to hammer out requirements, understanding the true business goal, and finding compromises that are technically feasible, surely takes the most of my time." In his case, it is likely that the greatest productivity gains would come from embracing the aspects of agile development that improve communication between developers and the business. For example, colocating with a product owner or on-site customer would allow frequent collaboration and promote understanding of the business goals and requirements. Similarly, replacing heavyweight written requirement specifications with: user stories, conversations, and acceptance tests (sometimes called executable requirements), would reduce ambiguity and misunderstanding of requirements.
What is the bottleneck constraint for developers in your environment? Leave a comment and share.
