The Secret Assumption of Agile

I assert that there is a secret assumption behind successful Agile. "Secret" may be a bit too strong, but it is certainly under-articulated if not completely unarticulated.

Agile succeeds when you write code that is easy to change.

I grew up with phased (waterfall) processes. I was taught that a needed design change discovered during the coding phase would cost you ten times the cost of knowing about the need during design. A design problem found in test would cost 100 times the cost of avoiding the problem during the design phase. Based on this cost model (which seemed correct in my experience following it for 20 years), code reviews, design reviews, detailed diagrams, rigorous architecture specifications were all cost saving techniques no sane project would ever do without.

Agile touts that it can easily accommodate change at a reasonable cost. That is, if you knew about the requirement in some detail before the project started, the cost to implement the requirement would be 1x. If you find out about this requirement in the middle of an Agile project, the cost to implement will be about 1x as well (maybe 1.1x, for example) and not the 10x or 100x a waterfall process would predict for a change that would affect the design and adjacent code.

What is going on here? Are all our experiences in waterfall development simply calculation mistakes? Were we using the wrong languages? Were we simply stupid?

"No!" to all of this (although I have had my moments of brilliant stupidity). What has happened is that we have discovered ways to write programs that minimizes the excessive cost of change. I count several technologies that facilitate change, including:

• Normalized relational databases
• Rules engines
• Object-oriented programming
• SOA (decomposition of an application into loosely coupled entities)

All of these techniques share two aspects in common:

1. They simplify the problem to allow other sound techniques to be applied, and
2. They eliminate duplication so that when change is needed, it can be applied to one and only one place with confidence.

My favorite among these techniques is object-oriented programming. By this, I do not mean using an OO language, although that is very helpful. I speak about a style of programming that exploits the fundamental OO concepts.

An example may help here. At a client a few years ago, we were asked to rewrite an existing system. The existing system was a Web-based application, Java platform, with Oracle database backend. The new system was a Web-based application, Java platform, with Oracle database backend. No difference. The reason for the rewrite: The system could no longer be changed in a timely fashion, and business was being lost. The rewritten system has exceeded expectations, met all business needs, and is easy to maintain and enhance (which has been done.) The original system had 79 Java classes. When we finished with the new system, it had 1400 Java classes. We found 1400 different, unique things to model. When a new requirement was being considered, it may impact 20 classes. But the remaining 1380 classes were untouched and ran their unit tests perfectly. Writing code in this particular OO style is different.

Are the Agile pundits (and I am one of them) deliberately hiding this "secret" assumption of Agile? I don't think so. But all the luminaries in Agile that I know have been programming in this style for many years (and most for decades). It is inate to their thinking. When I was exposed to this style of programming 15 years ago, it took a while for me to understand. But after that point, even my Excel macros in VBA are structured very differently.

There will be more discussion of how to learn this style in future posts.