Comparing the IDesign process with Agile

Roy attended a week of our IDesign Advanced .NET Master Class last week, taught (and authored) by Juval Lowy, which includes a module on our recommended approach to software development process. Roy did a great job summarizing the key points in his article here, but seemed to have picked up a little too strong of a tone on certain points than was intended, based on my knowledge of the material (from being an instructor for the class myself) and from discussions with Juval.

Specifically, in the section of his article where he talks about the differences between our process and Agile, Roy talks about the ~30% effort dedicated to architecture and makes it sound like we are recommending a big-bang, all up front, try to think of everything to do with the product before doing any construction (aka waterfall), which is not what is intended. The ~30% effort dedicated to architecture and design is in fact done up front – but done up front for each stage of the product development, which distributes that effort fairly evenly across the product development lifecycle. It is one initial up front architecture piece, where you decide on the overall architecture of the system, what the major subsystems and components will be along with their interactions, security boundaries, transactions, identities, packaging, and so on, and then a bunch of smaller architecture and design pieces associated with the specific requirements for each component or subsystem in each stage of the development.

What we don’t subscribe to is the concept that you can just sit down at a keyboard and start coding and come up with a coherent design for a large scale enterprise system as you go without some up front architecture and design work. We also believe that a majority of coders do not have the experience or big picture about the product for larger systems to be making all the design decisions themselves, thus the need for a dedicated architect who makes those architecture and design decisions throughout the development (with input from the team of course).

Another point I wanted to clarify is the use of test clients. I am not a true believer (yet) in full blown TDD, mainly because of the disconnect between our approach to actually doing some design and documentation before coding, at which point the benefit of writing tests before code becomes limited. But we definitely push that you should have tests for everything, preferably written in a way that you can automate the execution of those test, at a minimum the smoke test portion of them. Those test should be written and run by the developer, and canbe used by QA for their testing as well. As such NUnit style tests are perfectly acceptable for component based testing of business logic and data access components, but some things really need a UI to test them, so for those we use simple UI test clients (typically WinForms). If you have not yet adopted NUnit testing and don’t want to add that to your list of technologies to conquer, then you can write your tests how ever you like (such as all little WinForms and console test clients), but you should do so in a way that is not just total throw away.

Other than those minor points, I thought Roy’s article did a great job of summarizing what I know Juval taught in the class.