Developer Productivity
On Wednesday afternoon at the Cortina Software Architecture Workshop, Erik “it depends” Dörnenburg started a session entitled Developer Productivity. We’re all looking for ways to increase the productivity, but what works and what doesn’t?
Frameworks
Everyone present at the session agreed that frameworks can offer a gain in productivity. A good framework allows one to focus on writing business logic, instead of writing plumbing code. This improves developer efficiency.
However, a bad framework can decrease productivity. If a framework does not offer the required functionality, every developer will create their own solution. If it forces a certain way of working which is impractical, workarounds will be created. Sometimes, developers are forced to use a framework, because it was developed by the project architect, or because it is part of the Infallible Reference Architecture. While a reference architecture can help less experienced developers; it can frustrate the more experienced.
In conclusion: a good framework helps you. If a framework does not help you, stop using it1.
Capturing Abstractions and Intentions
If a tool can capture a set of concepts and build an abstraction over it, it can increase productivity. Also, productivity can increase if a tool can capture out your intentions, if it “knows what you want”.
An interesting example put forth in the session was that of GUI builders. GUIs mostly consist of labels with fields that are tied to variables. If the variable is a string, a edit box should be shown; if it is a boolean, a checkbox. One would imagine that GUI builders gain a lot by adding an abstraction which captures this combination. In practice, few GUI builders have it. Perhaps this isn’t such a great abstraction after all, and the Law of Leaky Abstractions applies here.
1 - Political and business decisions complicate things.
Alef Arendsen said,
February 15, 2006 @ 11:20
I agree it’s a good thing if a framework ‘knows what you want’ to some extent. However, tools, should never do things automagically, without offering the developer insight in what the framework is actually doing behind the scenes. Not doing so would result in ambiguous results and intensive debug sessions only finding out after hours that the framework did something you didn’t want it to do.
Thought Leadership said,
March 3, 2006 @ 13:18
Agilists who practice Command and Control
In my travels I have ran across lots of folks who have savagely read many of the books on enterprise architecture and still have gotten it wrong…