Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Quotes for Software Developers #2: Architecture vs Design

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. [Grady Booch]

My take on it:

I've worked on systems where every developer does their own thing. Highly interactive business web apps where there is no over arching pattern and everyone takes the path of least resistance... which is usually the way they did it at their last job or worse, whatever seems clever at the moment. These systems are pure hell to work on and maintain.

Every significant decision (ones difficult to change or make consistent later) is part of the architecture. From how you construct user controls, to what is done in code behind and what in javascript, to how you do ajax behavior... it's all architecture and it all matters. There must be a cohesive vision for how everything is constructed. The team must share and enforce that vision.

A lot of this comes down to communication. If someone is doing something that hasn't been done before on the project then they should grab a few team members for five or ten minutes and discuss it. Doing it right the first time is very important because one tendency of developers in a hurry is to simply see how things were done the last time and copy that. If the first set of code was bad you'll end up with six one off copies (each worse than the last) in a blink.

From what I've seen, the more developers have time to discuss the code and how things are constructed (and then run the decisions by their manager or architect for sanity check) the better and more cohesive the architecture will be over time. Peer discussions of architecture must be part of the culture. This means everything from new pages and new features to old code and refactoring. It doesn't have to be long and it doesn't have to be everyone together but small discussions must take place between team members throughout the day.

If developers share in the architecture of the system, if the own it and take pride in the architecture as a part of the team culture, then there will be little need for management to police it because the team members will police it on their own. New members, through peer pressure and team interaction, will quickly be indoctrinated into the culture and the team's pride in the architecture thus perpetuating the system.

0 - What do you think?: