Always Ready Software

Software is all design, with construction being automated or at least automatically tested. So said Jack W. Reeves in his article What is Software Design back in 1992. James Shore followed up and defined good design as one which:

“… minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.”

Always Ready to Run (and Install)

Continuous Integration with Test-Driven Development (and other automated tests on the build) ensures that functionality is always ready. Include automated build of installation script and the software is always ready to install and run.

The automated build system part of continuous integration knows how to return the essential “broke the build” or “build OK” message. The first follows the “fail early” principle. The second indicates perfect functional quality of the features that are in the build; all functional discussions can focus on which features are ready and whether they are as desired.

What about changes and new features?

What ensures, though, that the software is always ready to easily modify and extend?

Static analysis tools and complexity measures can help, but there’s a lot of important stuff that no machine can tell you.

For example, just one key attribute of easy-to-change code is:

Meaningful entity names

Write me a rule that finds the ones that aren’t.

A much easier way to find, and recommend improvements to, such people-oriented code attributes is code review.

On top of a continuous integration system with automated analysis and test, and a developer practice of TDD and constant refactoring (at the lowest level — not turning the entire design upside-down every week), all new code, and the edges of the existing code it interfaces with, should be reviewed.

Automated static analysis should find the language or construction-related problems, leaving human code reviewers to focus on things like readability, simplicity, and other design principles that only a person can find.

What kind of code review?

Pre-check-in review is an absolute minimum so that code review issues prevent check-in and thus prevent a build that runs, but whose code (design) isn’t ready to work with.

Pair programming is a nice idea but must need good pairing and people who are very comfortable with each other to make a difference.

Weekly desk review (the reviewer’s desk, by him or herself first) and discussion of all code written that week is best: it allows reviewer to see and advise on the bigger picture.

It’s the only way to keep the design which is in your code, as well as its functionality, Always Ready.

Advertisement