Enabling Agility

Deliver good software by releasing code that is free from defects in both structure and behavior.  A good structure that is free from defects will easily support and encourage changing requirements.  It is more important to make software right than it is to make it work.  Software that is Flexible can easily be made to work and support long-term enhancements.  However, software that works but is Rigid will be difficult to change and will inhibit your ability to support your customers’ future needs.

There are two aspects of software that provide value.  The first is the value of its behavior — which comes from the quality of the functionality for which the customer expects and is willing to pay.  The second is the value of its structure.  This comes from the quality of the design of the software — to the degree that it can be easily extended, tested, maintained, integrated, secured, reused, etc.

It is very common to have software with high quality behavior, yet have low quality structure.  This is often the case with new products.  The first release often delivers the functionality the customer expects.  But when the customer wants to extend or modify that functionality, it can be very difficult to deliver new versions of that product in a timely manner — at least to the level of quality that was originally delivered.

This occurs when the focus of product development is directed toward the behavior of the software, while very little, if any, focus is directed toward the structure of the software.  Many software developers believe they are done with development once the software works as expected.  But software engineers know this is not the case.  As Kent Beck once said, "First make it right, then make it work."  Once the software is made to work as expected, you should always go back to ensure the structure of the software is also of high quality.  And don't ever say "I’ll fix it later" because that rarely happens — there always seems to be something with a higher priority than going back to fix bad code.

One thing that software engineers know very well that software developers rarely do is that the value of software structure is greater than the value of software behavior.  In order for software to have long-term value, it must be able to react to changes in requirements.  Software that is easy to change can easily be made to work, and therefore its value is easily realizable.  Software that works but is hard to change will be difficult to maintain its value once the requirements change.