Sustainable Design and Development

No, I don’t mean design that uses trees and development on green laptops powered by solar panels icon smile Sustainable Design and Development

When I say “sustainable” in this context I’m talking about the ability to keep working on a piece of software over the long term without it becoming so difficult to add new business value that it’s easier to throw it away and start over, or at the least to refactor very significantly.

When working in an Agile methodology, we mustn’t think that everything we need to know is contained within the user story we’re working on. How that story fits into the existing system, how it affects other (existing and new) stories, how it affects system design, performance, maintainability – these are all factors that professional developers must be keeping in mind as they read a story. We must be ready to relay concerns over possible negative impacts in any of these areas to the story originator, as often there is sufficient flexibility in a story to allow it to be refined so that such concerns are removed. It is our responsibility as software practitioners to ensure that adding a new story doesn’t reduce our codebase’s quality, even if it requires work beyond the scope of the story itself.

This is where automated tools to help try to measure some facets of code related to code quality can come in handy: you then have a yardstick to ensure that quality is not heading downhill as new features get added. For instance, if you’ve got a static analysis tool that measures your cyclomatic complexity, you might set a max limit on that complexity that is not to be exceeded by any new code. Of course, that’s just one facet, and not every important aspect of software quality can be measured mechanically, but it does provide some assistance to have such tools. Code coverage is another area: if you’ve established 100% as your target for coverage, then new features should ensure they don’t violate that.

The trick is to make sure that every new story incorporated into code leaves the code at least as clean as it started, if not better, both from a pure code point of view and from a design point of view. This is of course, a tall order, but one well worth trying to hold to.

Principles and Practices

Tired of the Software Development Grind? Know it can be done better? Check out my book: Principles and Practices of Software Craftsmanship or sign up for my Craftsmanship Dispatches newsletter.