Standards
In life, an ounce of prevention is worth a pound of cure because it is almost always much more expensive to fix a problem than it is to avoid that problem in the first place. Software development is an extreme example of this simple observation. Unlike physical systems, software is as close as it gets to pure thought, and there are no physical constrains on complexity. Coupled with inexperience, misguided concepts, time pressure, and expediencies, many software projects spend too much time and effort resolving problems and fail to deliver on their commitments. Developers can avoid wasting time and money by adopting a comprehensive coding standard which enforces proven best practices, avoids pitfalls, and enables knowledge dissemination across the team.
Traditionally, such coding standards were thick, laborious documents detailing the rationale behind every item in the standard. While these are still better than no standard at all, such efforts are usually indigestible. A good standard should be very thin on the "why" and very detailed on the "what." While fully understanding every insight that goes into a particular decision may require years of experience, applying the standard should not. This motivated Juval Lowy in 2003 to publish the C# coding standard (which has since become the de-facto industry standard for .NET development), followed in 2007 with the WCF coding standard.
Software architects must be more proactive than software developers in adhering to a standard simply because of the pendulum effect—even small mistakes at design time have drastic consequences at development time and over the life of the system. Furthermore, fundamental (and often avoidable) design mistakes are almost always catastrophic, resulting in disproportional cost in time, market position, reputation, and careers. Similar to a coding standard, Juval saw the need to define a design standard for software engineering, which will facilitate absorbing and adhering to correct design directives and guidelines. All other engineering disciplines apply design standards, such as those used with buildings, airplanes, and power plants.
The IDesign design standard, contains the best practices from the book Righting Software (Addison-Wesley, © 2019) and the IDesign Master Classes—ideas that we have practiced successfully at IDesign across countless projects. The design standard directives are simple and consistent, both internally and with every other engineering discipline. Over time and with practice, applying these concepts becomes second nature.
Note that the elements of the standard on their own may not mean much because you still must know the context for each item. Nevertheless, the standard ensures that you do not omit an important attribute or consideration. This makes the standard essential for architects in driving successful system and project designs.
