Another interesting Google Tech Talk about software engineering. The theory is that the most common architecture for deployed software is a big ball of mud. The deployed code is a mess, it has been extended over time with no apparent thought for maintainability and it stinks (sound familiar?).

But if it's so bad why is it so common? I'm sure that the theory is actual fact. So it is important to look at why this is so and does it really matter? If it does matter but we can't stop it then we need to learn how to cope with it.

As an engineer you always worry when you work with another engineer who just doesn't seem to care about the quality of the code. They probably do care about the quality of the product they are making but they just don't seem to see the relationship between the code quality and final product a customer sees. There is a selfish aspect to this relationship. You know they are not going to fix the code when it starts to decay and you honestly feel that they know you are going to pick up the pieces for them.

Equally as unnerving is working with an engineer who can't see beyond code to the reality of actually shipping a product for someone to use. All they see is architecture and broken windows. For them a product is a master piece and nothing as lowly as a schedule or cash flow should get in the way.

Once again there is an illusive and uncharted middle ground that must be found for each product and many times during the life time of a product as the environment changes around the code.

Anyway, take some time out and watch the tech and read the original paper.