Thursday, August 17, 2006

The Age of the Design Review

Is programming an art or a science? That question has been asked for many decades and it will probably be asked for many decades to come. We've been searching for the construction equivalent of standardized parts like screws, nuts, bolts with which to construct software. We've treated coding languages and code libraries like silver-bullets and have been disappointed every time.

My question, is Software Engineering showing signs of maturity? In a post named "Leaky Abstractions and the Last Responsible Moment for Design" Jeremy Miller gives a good example of looking at a design and reviewing it.

I believe that we are seeing the beginnings of the common language needed to really improve the ability of practitioners to objectively discuss, evaluate, and correct the designs of others. One solution that is often suggested is to perform code reviews, which assumes that code standards have been put in place. Code reviews are nice but they usually come in two flavors, either examining the syntax or the design. Syntax reviews can be simple 'proper use of braces' to more detailed like patterns for using virtual destructors. There is a limit to syntax reviews because the code has already been written, like shutting the barn door after the horse has already escaped. What is frequently mentioned is the need for a design review which has been the holy grail. How do you do that without a common language? Design reviews no longer seem beyond our grasp. I've seen plenty of stories where time after time, software injuries are self-inflicted by Code Monkeys and Cowboy Programmers. Design reviews might not create world peace or feed the hungry but it might make it easier to keep apprentices or journeymen from masquerading as master craftsmen.

Between Anti-Patterns, Code Smells, and Refactorings I have the impression that the industry is reaching a point where we have the tools to properly review and critique software designs consistently. A common set of terms for describing and understanding problems; a common set of tools for describing and implementing solutions.
Delicious Bookmark this on Delicious

1 comment:

  1. I agree that syntax reviews, coding practices, etc. shouldn't be checked in a formal, everybody-stop-down-and-join-in review. Instead, teams should use tools to continuously monitor those aspects of the project's health, preferrably in a continuous integration environment. Java has all manner of open-source tools to do static and dynamic analysis of code -- Checkstyle, PMD, FindBugs, JUnit/TestNG and attendant extensions, Emma, Cobertura, ...


I reserve the right to delete inappropriate comments at my discretion