On the Test.ical.ly blog there's a recent post asking about good software architecture and how you could define it simply without having to muck around with all of the details it tends to conjure up.

What is a good architecture and why are there apparently two opposing trenches supporting quality on the one side and speed of development on the other side? After having had enough time to think about this whilst flying to Spain I came to the conclusion that Nils question whether it would be better to start quick and dirty to fail cheap in case the project is a looser or to stick to a clean and solid architecture and spend more time and money. Does quick always have to be dirty, clean always have to be slow, is dirty always quicker?

He suggests that "good architecture" and "quick and dirty" are the two opposite ends of the same spectrum. Instead, he suggests that a pragmatic approach is the best - focusing on what needs to be done rather that how to get there. Also by applying the "don't fix it if it's not broken" mentality to current methods and technologies, you can save a lot of hassle in the long run.