jonr originally posted this on Jon Rose's Blog.

Well, I haven’t had much time to play with my new favorite technology lately (Adobe Flex). So, I figured I would blog about one of the other software topics that peaks my curiosity.

 

For a few weeks, I have been thinking through a simple but odd idea, as it would seem to be an oxymoron, “Agile without the implementation.” Those of you that embrace Agile methodologies will immediately want to smack me down, as that statement would seem to be a complete contradiction.

 

There is however, no matter how much the Agile advocates want to argue the point, a mismatch between Agile and a number of the environments that software is developed within. The most obvious example being the government, as all Agile methodologies are based in an anti-bureaucracy mentality, and our government agencies are anything but.

 

In the last couple of months, the great state of Colorado, which I call home, started clamping down on state agency software projects. Our new governor, Bill Ritter, issued an executive order that all software projects over $10,000 are subject to oversight and management from a single state office (http://www.rockymountainnews.com/drmn/local/article/0,1299,DRMN_15_5641110,00.html). Experienced software engineers immediately understand this will only exacerbate the difficulty of building quality software, rather than help to minimize the failures that different technical groups within our state government have experienced.

 

This is obviously (or maybe ‘hopefully’) the extreme of government bureaucracy, but even within the most relaxed government agencies there is typically the requirement to do a big-up-front analysis/design to even get funding. As we all know, a main tenant of virtually all Agile methodologies is the aim to eliminate this very practice, as it almost always leads right into a waterfall like implementation methodology.

 

So, how are government software managers to succeed in circumstances that are clearly not conducive to building great software? As crazy as it sounds, I think the answer is ‘Agile without the implementation.’ The concept is based on being able to validate and execute requirements, without implementing them. Thus, a team is still able to produce tangible artifacts that are validated, while not getting stuck with the time or cost of implementation details.

 

Most must be asking, “How would one truly validate and execute requirements?” The company I work for has developed a product for executing UML 2.0 models, the Gorilla Execution Engine (GXE). This allows a small team of developers/analysts to create a true code ready specification, which has been validated by the end user through a functional user interface generated from the UML.

 

Here is how I would see the process of Agile without the implementation working. To be true to the concept of Agile, features would still be digested in small chunks iteratively. Stakeholders and users would still get a functioning user interface through each iteration that allows them to validate that the requirements have been captured correctly. The ‘domain model’ that is being executed acts as a code ready specification that would be implemented down the road in separate implementation iterations.

 

This would bring a number of benefits to government agencies. First off, they would be able to reap real benefits from the up-front requirements time that they are typically required to provide, as they would have validated requirements. Second, it allows them to still borrow from proven Agile techniques while still satisfying the bureaucratic requirements. Third, it would allow governments groups to more accurately estimate the cost of implementing the system, as they would be working from validated requirements.

 

As I work through this idea on paper, it seems fairly obvious that developing software like this could help to close the gap that governments have between there innate bureaucracy and Agile methodologies. Taking it a step further, I am starting to really embrace one of my company’s core philosophies behind the GXE, which basically says we should avoid implementation details when trying to digest requirements. Tools like the GXE give us the abstraction to be able to do this. At first I question this as incompatible with Agile, but the reality is that when done as part of feature based iterations, then it can only serve to enhance an Agile project.

 

To take one more leap from this thought process, this idea is really just a stop gap. With all the work currently being done in the declarative programming space, soon modeling will just become the core implementation. Thus, making this whole idea a moot point anyway as the requirements and implementation will simply be a model.

This entry was posted on Thursday, July 26th, 2007 at 1:19 pm and is filed under Jon Rose. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.