architecture by accident

I’ve been on a number of projects with a common problem set:

• architecture is deteriorating with time, and was never strong to begin with
  
• there is no architect or designer with project-wide authority
  
• nobody views this as a problem–including the development team
  
• time to add a feature is increasing
  
• quality issues continually surface as new features affect older ones
  

The introduction to Booch/Rumbaugh/Jacobson "The Unified Modeling Language User Guide" makes the case for design modeling thusly:

"If you want to build a dog house, you can pretty much start with a pile of lumber, some nails, and a few basic tools...

"If you want to build a house for your family, you can start with a pile of lumber, some nails, and a few basic tools, but it's going to take you a lot longer, and your family will certainly be more demanding than the dog. ...

"If you want to build a high-rise office building, it would be infinitely stupid for you to start with a big pile of lumber, some nails, and a few basic tools. ... You will want to do extensive planning, because the cost of failure is high. ...

"Curiously, a lot of software development organizations start out by wanting to build high rises but approach the problem as if they were knocking out a dog house."

(The full text is entertaining; go forth and read the whole thing.)

As a developer, there are a couple of approaches I use to at least try to address this:

• When adding new features myself, try to talk with everyone with code touching mine. Often there is a conceptual design in each area's designer's mind--there just is no globally-available expression of it.
  
• I document my own designs with diagrams and written discussion, which I pass around for comment. I try to include global information about the global concept objects I touch. This has the effect of (often) flushing out different views of the responsibilities and limitations of key objects.
  
• I transfer design information into javadoc, so the next developer can see it as (s)he codes.
  

Design is key to success in anything but the smallest projects. I use "success" very carefully here; some more recommended reading:

http://thedailywtf.com/Articles/What_Could_Possibly_Be_Worse_Than_Failure_0×3f_.aspx
"When an enterprise software application is deployed to production, it’s almost universally considered to be a success. In most other industries, equating completion and success would be ludicrous. After all, few in the construction industry would deem a two-year-old house with a leaky roof and a shifting foundation anything but a disaster — and an outright liability.

"Yet, had the VCF system gone live, almost everyone involved — from the business analysts to the programmers to the project managers — would have called their work a success. Even after the code devolved into an unsustainable mess, many would still refuse to admit that they had failed. The result is a cycle of failure, as dev shops refuse to recognize and correct issues that plague their projects."