Where Science Meets Art
One of my favorite reasons to advise people to move to agile is simply because it works. Not everyone would agree. The Internet is full of tales of woe and failed agile projects. But I stand by my statement and will back it up not with facts, but with an analogy.
When interviewing project manager candidates, I always end with a question that tells me whether they truly understand software development or not. The question: “Is software development more like building a bridge or painting a picture?” The answer is both.
Agile has the tools and techniques to handle both the science and the art of software development, while other approaches do not. At the risk of tipping off the next round of prospects for our PMO, I am going to explain why.
Software development is like building a bridge in that there are standard approaches and sound engineering practices for creating the end product. Developers can and should rely on proven database designs and architectural designs just like civil engineers follow solid architectural/engineering principles. Modularization with loose coupling of components, automated unit tests, continuous integration and team ownership are all engineering practices that apply to bridge building. It is the rise of extreme programing that has developed these foundational principles for building great software.
Likewise, the agile approach to emergent architecture has parallels in bridge-building. Emergent architecture is simply the principle that you build only what you need to do the job as you know it today. No one builds more piers for a bridge than needed to carry the the number of lanes and traffic expected to go over the bridge. A bridge is designed with a standard safety factor to make sure it will stand under the highest expected stress. Likewise, software should be built to meet only the stress it is expected to handle and no more. Doing more only wastes money.
Under more traditional approaches to software development, the architecture is seen as the necessary foundation that must be built before incorporating any actual features. Not only are the known issues designed into the architecture, but every conceivable contingency is built in. The result is a bloated architecture that is ready for features that may never materialize. It is like building the piers for the Brooklyn Bridge to support a two lane road across a local creek.
With emergent architecture, as you identify features that will require more architectural pieces, then you add those pieces to the foundation. It is like adding piers or strengthening the existing piers so you can add another lane or level to the bridge. The difference between software and bridge building is that with software, the adding of more piers or strengthening the existing piers should be far easier. All the more reason to only build what is needed and no more.
This is where the analogy to bridge building ends. In Part II of this article, I will show how software development is like painting a picture and how agile works as art as well as science.
