Revenge of the Fallen

Did you think you were constructing this:  but you were actually delivering this instead:
In my post Now That’s an Active Engine – Agile Dissected and Skewered I shot you over to a post that fairly made the case that the waterfall approach is not such a bad thing.  Summarizing what the author Bill Miller said:

Once we understand the customer’s changing needs, we can architect the solution in a way that supports making those changes easier, faster, and with higher quality.  This may involve one or more of the following approaches

• Provide a messaging protocol in a standard format such as XML.
• Provide an API to the functionality that a customer may want to reuse in other ways or to customize the application such as done with WordPress.
• Provide an editing interface to the application for the features that are likely to require changes by the customer. For example, if the system is rules driven, provide the user with the ability to edit rules for themselves. Make the rules data driven, don’t hard code the rules in whatever chosen language the system is implemented.
• Provide tools that change the behavior of the system. Some of these tools can be pushed out to the end users, customer teams, and even business partners. In other cases, the tools would generate the code that needs to be built by the development team.
• Provide a rich architecture that more closely mirrors the problem domain, is easily extensible, and is orthogonal.

These are only a few of the many possibilities that are available to us. In many cases, the possibilities are unique to the domain. Some of these options need to be attenuated by the life expectancy of the product as providing these capabilities require an investment, and the return may not support the investment with a product having a short life expectancy.

Delivering architecture and tools with these capabilities requires a large investment in up front analysis and design. Developing these solutions often requires a long development lead time before the first build is available for test – it’s typically longer than a few months. What you give up on the front end, though, you gain in leaps and bounds in the back end. After all, if we are to believe the tired maxim that 80% of the effort is spent in maintenance, doesn’t it make sense to design solutions that will optimize the maintenance phase?

Great wisdom in those words.  What Bill describes is an ActiveEngine, a machine that is constructed to respond, to adapt to their client’s needs.  Built to empower and spur productivity.

But without constant interaction by gathering feedback upfront, the development team runs the risk of becoming a team Internet Scientists who are working on tube technology, a futuristic system of the “future” where we travel in tubes, and wear jumpsuits.  Unflattering, wrinkled aluminum jumpsuits.  Or worse, like Pilgar of the Future to the right.   If too much time is spent in isolation the deliverables and expectations can become mis-aligned.  I mean really, could David Hasselhoff be any more absurd than this dude I found?  I Googled “aluminum jumpsuit” and came up with that.  Forget the homo-erotic presentation of the crotch here – do you really think the designer of this outfit ever expected it to be associated with “aluminum jumpsuit” of the future?  How about some dude trying to prove a point about software development, Waterfall, and Agile?  Life can be that weird!!!

There is a need for a hybrid approach.  I am in agreement with Bill in that up front work must be done on large systems in order to build what is referred in Agile as the “backlog”.  Once done this pipeline is completed, Agile can take over, as the front end will need to be influenced heavily by the end user.  Consider it your prime directive.