Productivity and Code Design

One of our developers suggested an important relationship that I haven't discussed yet: that of productivity and code design.  Most of the productivity benefits of good code design come after the original code is written -- they affect the ability to improve and expand the code.

You can write code designed to increase productivity by focusing on a few simple ideas:

• It should be easy to understand, so that additions or changes can be made more quickly
• It should be easy to expand, so that future enhancements don't have to re-factor the core logic
• It should be easy to deploy, so that changes don't require a massive regression testing effort

In Rapid Development, Steve McConnell makes similar points in the chapter, "Designing for Change."  The chapter suggests identifying areas likely to change, using information hiding, and using object-oriented programming, among other ideas.

Fortunately, a lot of these ideas piggyback off of good coding practices.  But the emphasis on these practices is usually towards maintainability.  It's interesting to reflect on their strong relationship to productivity, too.

This is another good way to understand how older codebases tend to reduce productivity.  Inevitably, design boundaries will have gotten blurred, shortcuts will have been taken, and "just get it done" projects will have reduced readability.  This all affects future productivity, and is another argument for periodic refactoring.