Thursday, April 21, 2005

Automate to Reduce Variation

The power of tooling to reduce variation is often overlooked. Together is tool that significantly reduces variation in software development when used correctly. Microsoft Visual Studio 2005 Team Architect is another one, though its 2005 features address different problems such as design of distributed systems and deployment across data centers. Nevertheless, there is a common theme - right first time! The automation in the tool reduces rework and provides validation of one rendering of the knowledge captured in the product against another rendering. The chance of source code incorrectly implementing a design when Together is used correctly is greatly reduced. This reduces defects. Reduced defects reduces rework. Reduced rework improves planning accuracy and improves productivity through greater productive use of capacity constrained resources.

But Together is even more powerful when correctly used with The Coad Method and the architectural ideas that come with Peter Coad’s teachings. With The Coad Method, the domain analysis is kept is synch with the design and the source code. There is significant reduction in variation across a greater span of the lifecycle. With the resultant productivity gains. This is the paradigm shifting power of Together - a tool designed to implement The Coad Method. I’ve always been amazed at how lousy Togethersoft and more recently Borland have been at communicating that message. Perhaps the widespread adoption of J2EE and Enterprise Java Beans is what caused the problem. The J2EE simply got in the way of good Coad Method implementations. [I’ve got data that shows FDD teams practicing the Coad Method significantly outperform teams doing J2EE EJB’s. The difference in architecture wasn’t the only variable so these aren’t scientific results but anecdotal, empirical data is good enough for me as a manager to know that I’d never recommend building a J2EE based application ever again.]

I am hoping that we can drive similar ideas into Team System and Team Architect with respect to Service Oriented Architecture. The end product would be a version of MSF which was optimized for SOA and prescribed analysis and modeling techniques, implemented with domain specific languages (DSL’s) in Team Architect that significantly reduce variation throughout the lifecycle from requirements through to deployment. In other words, it would be nice if we could learn the lessons from Coad and FDD and apply them in a 21st Century SOA context.

Returning to yesterday’s post, there also exists tooling to drive variation out of user interface design and development. My old friend Brían O’Byrne founded Statesoft to solve this problem. His tool implements Ian Horrock’s method of using Statecharts for modeling the interaction design - an equivalent to the Visual Vocabulary technique I described yesterday but more rigorous, more directly mapped to the source code. Brían and I first developed this technique as a framework when we worked together in Ireland in 1999. His latest tool works for Java and .Net and allows you to draw a Statechart model of a UI screen flow and then generate the View-Control code for either GUI or web deployment. It’s a tool which reduces the variation from the designers vision to the implemented working code. [And it was developed using FDD.] The domain specific extensions that we made to Statecharts to handle exceptions and transactions also greatly reduce the possibility of defects in error handling code. Once again, tight coupling of analysis, design and code reduces defects. Reduced defects reduces rework. Reduced rework improves planning accuracy.

If your constraint, today, right now in 2005, on .Net software development, is coding productivity, then you simply have to look seriously at tools like Together and View Control as additions to Visual Studio and consider training your people in how to use them properly - model-driven design!-Analysis, design and code always in synch significantly reduces the opportunities for defects and the actual numbers of defects. Drive variation out of your software development lifecycle!

[In the interests of balance, if anyone else is producing tools which they can demonstrate significantly reduce variation across the lifecycle in a similar fashion please comment]