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.
Community comments
Disagree
by Jules Jacobs,
Re: Disagree
by Amr Elssamadisy,
Re: Disagree
by Jules Jacobs,
Re: Disagree
by Jules Jacobs,
Language relates to the way we think
by Dmitry Tsygankov,
Disagree
by Jules Jacobs,
Your message is awaiting moderation. Thank you for participating in the discussion.
He writes that project setup time is not really important, because he only spent 3 hours setting up a new project. I agree. But still, why does that take 2 minutes with Rails? Yes, it doesn't save a lot of time, but why wait if you don't have to? If setting up a project takes that long that's a good indication that your tools are too complex.
Coding time. This is actually very important. I agree that coding itself doesn't take that much time, but you can trade coding for communication. If you can implement a feature fast enough you can do it live in a meeting (I do this with my clients). This means that you have to discuss it less because you can check immediately if this is what the client wants. Last time I implemented two prototypes in Django after the first meeting. This also saves a lot of communication time because in the next meeting the client can say "this is what I want, and not that" and point at the screen. If they have to describe exactly what they want that will take a lot longer, and I certainly don't get what they mean the first try (often THEY don't even know what they want).
Short code is not only easier to write, but also easier to read. This is obvious. Java code may be easier to read per line. I'd rather read Ruby code because it will be fewer lines with less irrelevant stuff.
He actually has an example of this in his article:
It's called == in Ruby, and I never forget it.
In his last bullet point, "Reasonable Frameworks" he argues that his frameworks are "good enough".
I doubt the high factors (100x) and I don't think that another framework can give a factor of 10 soon. If we scale down the factors a bit, yeah I think 2x over Rails is possible.
Language relates to the way we think
by Dmitry Tsygankov,
Your message is awaiting moderation. Thank you for participating in the discussion.
This one is a good point, it really amazes me how some Ruby guys claim they are 10 times more productive based on project setup time comparisons.
Yes, that is true. But when you get those requirements, find compromises, etc., how do you fit that stuff into your brain? A structure of some sort? Some object structure with responsibilities of particular objects (object-oriented approach) or what the system should do in response to some user action (more like the functional one)? User stories? Сard of accounts? These are all languages of some sort. The more of the languages you understand the easier you fit stuff into your brain. I find that some of the hype around the languages is about realizing that a class diagram is not everything and there are other ways to describe what's happening. Another part of the hype is about what's mentioned in the first paragraph - code readability and debugability. And some of the hype is, well, just hype.
Re: Disagree
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't think you are addressing the point. If indeed the bottleneck is not in programming, it is a waste of time and irrelevant talking about languages and frameworks.
The real question is, where is your organization's bottleneck? If it is in programming, then everything you say makes sense. If it is not, then no matter how fast you program, product will NOT come out faster.
Re: Disagree
by Jules Jacobs,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, my main point is:
1) Why use an inferior language if you have a choice? Even if it doesn't matter much, I'll save a few hours if I have the choice.
2) Shortening coding time can alleviate the communication bottleneck
3) Better frameworks also deal with "Understanding Preexisting Code" and "Debugging Errors"
I actually disagree with this "Theory of Constrains". The world isn't that simple.
Re: Disagree
by Jules Jacobs,
Your message is awaiting moderation. Thank you for participating in the discussion.
Let me clarify this: "Even if it doesn't matter much, I'll save a few hours if I have the choice.". I mean even if it doesn't make the project come out faster because you're waiting for other things. Then you can play minesweeper or something in the extra free time.