Extreme Development Efficiency
Posted by Dan Vanderboom on December 20, 2007
I feel this overwhelming need to be a highly productive and efficient developer through constant attention and continuous improvement to the processes, techniques, and tools that I use. Whenever there are bottlenecks in the process, frustrations and annoyances with the tools, or intuitive discomfort with the techniques and patterns that I’m using, I seek to eliminate the largest obstacle in my path to approach perfect fluidity and rapid development.
It’s important to move the big boulders first before filling in with smaller rocks and pebbles. The big boulders: defining the right goals, collecting the right requirements, solving the right problems, and using the right processes. If you’re heading in the wrong direction, it doesn’t really matter how fast you’re going. Misunderstand your customer’s needs, and your chosen programming language won’t mean diddly squat. The medium-sized rocks: applying the right design patterns and using the right tools for the job. You can accomplish more with the right 100 lines of code than you can with 2000 lines of a rushed, poorly planned mess that will require constant maintenance and an eventual rewrite. The small pebbles get really specific. They may involve using code snippets or IDE plug-ins to more rapidly configure or develop projects, altering your workflow to circumvent predictable social distractions, standardizing on naming conventions, and so on.
I’ve spent a great deal of time studying architecture, design, and agile processes, and I admit that I’m constantly learning new things in these areas. These things fascinate and stimulate me. But I’ve been writing code for 24 years (starting with Apple 2 Basic), and I’ve developed an intuitive feel for how to write code, formulate complex algorithms, and design components and their interactions. Explaining these concepts and techniques to less experienced developers, even with the vocabulary that I’ve acquired over the past few years on these topics, proves to be a great challenge.
But the small pebbles, the little tweaks of efficiency that I make to shave 5 to 10 minutes off each day, are easier to explain, much like the end game is easier to teach a beginner of chess than the middle or beginning game. It’s more tactical, and more tangible, because it’s easier to measure and demonstrate.
It also offers a less competitive market to produce tools for, as these optimizations tend to be very specific to the technologies and tools, as well as the developers who use them.
So I’ve spent a lot of effort recently reducing build times, optimizing data synchronization strategies, applying multithreading to minimize application startup times, and developing some tools to improve development speed and reduce risk and errors. One purpose of these efforts is to attain greater performance in the applications and systems that I build. The end users will appreciate this effort, but there’s a selfish aim here as well: if I can speed things up to the point where I’m saving 10 minutes a day here, 15 minutes a day there, and more or less in other areas, I can easily recoup an hour or two a day that I would normally spend waiting around for a build to complete, an application to start up, or a query to run. Per developer.
Development time is very expensive. If we can minimize the time spent waiting around for things to happen (which is boring anyways), and maximize our productivity (which is exciting and satisfying), everyone will be happier in the end. Developers will crank out new features and products quicker and customers will get their needed functionality sooner.
On the other hand, I’ve made a number of decisions to trade application performance for developer productivity. My priority is usually to create correctly functioning software first, not with complete disregard to performance, but with performance considerations not automatically being at the forefront. If the code is 20% slower than it could be, but the development team can refactor and extend the solution 250% faster, sometimes that trade-off is worthwhile. And I’ve programmed in assembly language, so I’m familiar with the attitude that we have to preserve every byte, and reduce every unnecessary processing cycle we can to get the most out of the hardware. It’s just not sensible to think this way anymore (except for very specialized functions or embedded systems).
Just as our perspective of hardware and software systems has matured to include concepts like total cost of ownership (TCO) once the system has been deployed into production, so too must we consider all of the ramifications of software design and performance on developer productivity and the flexibility of product evolution, and therefore the total cost of development. If it’s cheap to build, it might be expensive to support. In the end, we’ll have to pay for it one way or another. We need to think about more than what it will cost us now. What design and process decisions will minimize the cost over the entire lifetime of our products?