Focus Improvement on Bottleneck Constraints
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.
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:
Cripes, I can't even remember in Java whether its Object.equal() or Object.equals() because I haven't typed the whole method even once since I installed Eclipse about 9 years ago.
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".
Struts was a big step up from bare servlets, and Spring MVC is another order of magnitude. Spring+Hibernate must be 100 times more productive than bare servlets and JDBC ... I can easily imagine Comet giving you a 10-100 X productivity boost over the bare technologies. Is there another framework better than Comet? No idea. Would it give another factor of 10? I strongly doubt it.
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
over the life of a project, the setup time is not likely to be significant
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.
Trying to hammer out requirements, understanding the true business goal, and finding compromises that are technically feasible, surely takes the most of my time.
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.
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.
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.