A matter of principles

I attended a talk by Simon Brown on software architecture tonight. I thought it was very well presented and had some very relevant content for me. I then read a 2 day old blog post by Keith Braithwaite on the need for designers to be “T” shaped.

Simon’s talk mentioned that an architecture is produced by the combined forces of requirements, constraints and principles. Software architects need to be flexible in applying principles to the right situation. Keith’s article is also in this spirit (they both talk about “T” shaped people!) and blind application of concepts and principles can produce something that is of very little value. That delivering business value is the goal, not architectural perfection.

My experience over the past few years however, takes these pragmatic ideas a bit to the extreme. Abandoning good principles and practices over the long term to satisfy the business. In my opinion this isn’t sustainable. I’d equate it to a house that has the perfect living space, the most comfortable furniture, but wicked subsidence.

Of course I tend to paint a grim picture sometimes. The fact is, the business got to where it is today because of the sacrifices made in the past, this can’t be denied. We need to work on our technical debt and move to that utopian middle ground, where software engineering principles meet business value.

Something we’re still trying to work out is how to quantify this debt in a way that business people can understand (bugs == £££?). We’ve started cataloging ugly code and tracking quick fixes and trying to evaluate their long term impact. It’s all about trading time to build marketable functionality, for time to underpin the foundations.

I agree with Simon and Keith. Principles are there to guide us, and we should use them when necessary. The techie within me though is crying for just a bit of professional integrity!

Another thing Simon introduced me too…the project triangle. I liked that