Blog

Recently, I’ve been introduced to the IDesign methodology. While I have yet to implement it, or see it in action, I do have some comments based on my introduction to IDesign.

These comments are based on preliminary research, YouTube videos, and 8 hours of training. I have yet to read the book, Righting Software.

Pros

1. The cost and risk analysis looks convincing up front
2. Some elements of implementing IDesign in a .NET system are really slick
3. Architecting around use cases and volatility is an excellent way to go
4. Organizing a Visual Studio solution consistently is a fantastic idea and should be adopted as widely as possible
5. The “one-way traffic” concept will block some of the stupid things we developers do when in a hurry or when we are more junior

Cons

1. The lack of scientific data to back up claims (unlike, say, Dave Farley’s book on Modern Software Engineering)
2. The lack of information in Internet search results on IDesign, and the lack of IDesign examples done by other engineers
3. The attitudes of “everyone else does software wrong” or “this is the only right way to do software”
4. Despite the hype, it’s mostly a compilation of some of the known better practices in the industry into one package
5. The muddy waters between IDesign and specific coding approaches (Dependency injection vs factory patterns)

Clarifications

Not enough engineers consider system volatility up front.

Some of the better practices already known include use cases as the starting point of the design, breaking down the system along the lines of use cases and behavior, asking good questions of business, architecting a system in layers, and more.

IDesign Initial Conclusions

The methodology has merit in a number of areas, if one can get past the attitudes presented in videos and training. Remember, though, there’s no one-size-fits-all in software engineering. This methodology is not the right methodology for every situation, and no one expert has all the answers.