So, when is the design of a software system “right”?
Oh, how about never.
A certain amount of cynicism has set into the industry as regards to software architecture. A cynicism borne of the fact that when object oriented architecture became mainstream in the 1990s, the prevailing wisdom was to get the design right up front and then build it. Well, we all know about the ‘best laid plans of mice and men’. The architect, of course, bears the brunt of this as they were responsible for coming up with those ‘best laid plans’. This is why industry decided to hedge its bets with regards to software design. To do this, iterative methods of design were introduced, starting with RUP and now Agile. Each of these introduces some sort of mechanism for ‘checking up on things’ at all stages of the project.
To many, the problems of the 1990s acted to dilute the perceived worth of an architect. However, the fault was as much with the process as it was with the person. Whilst the above mentioned methodologies have addressed this, there is still some cynicism out there. This is apparent in the number of architectural positions that involve mostly hands on work. The only hands on work an architect should be doing is that pertaining to frameworks, proof of concepts and prototyping.
Coupled with the cynicism is an obsession with short term results. Yes, in many cases, it will be possible to build something that will get you through to the next quarter with your deliverables (mostly) intact. Maybe for the next few quarters too. However, without paying due respects to design, eventually it will take so long to add the new feature or fix the high priority bug, any continued progress will be mired in vapidity. Not to mention the associated staff turnover. Not that it matters of course as the initial sponsor of the project (CEO, etc.) has long since departed with their golden parachute having successfully delivered version 1.0. Shame about v2.0.