A matter of principles
May 18, 2010 at 01:13 2 comments
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 
Entry filed under: Uncategorized. Tags: architecture.
1.
Keith Braithwaite | May 18, 2010 at 06:19
Designers and architects both typically have a great deal of professional integrity. If architects are ‘I’ shaped and designers are ‘T’ shaped then both have that vertical depth-in-craft.
Neither are ‘_’ shaped.
I don’t think I said anything about principles, but if I had I’d say that being flexible in applying principles to the right situation is part of having professional integrity. And so is not being flexible about not applying principles in the right situation. And so is not applying principles wrongly in the wrong situation.
What I see with too many software architectures is a very inflexible approach to applying fads and fashions.
Multiple logical layers distributed over multiple physical tiers with message-based middleware carrying XML (for example) isn’t a “principle” it’s a set of engineering tradeoffs which embody a principle (loose coupling)—and it’s more appropriate in some situations and less so in others. Yet I see system architects cleaving to ideas like that, to the contingent manifestation of a principle, without assessment of its suitability. Nor a recognition that this suitability can vary over time.
2.
dolsonagile | May 18, 2010 at 23:42
Keith,
I’ve worked with a few architects like you describe, so I know what you mean. Your post (and Simon’s talk) just got me thinking about what i’m experiencing now.
I guess I interpreted your post (albeit incorrectly) as describing the architect as a dogmatic applicator of principles, while the designer was more pragmatic, taking into account other factors to base decisions on. I see a lot of advice about how we need to put business value first, and be pragmatic about application of tools / technologies / practice / principles in design and code. It’s all good and well founded advice of course.
I was just trying to relate that with my experience lately which is of professional integrity being stretched. Design something dirty now to meet an urgent business need, believing (not necessarily knowing, I admit) that it will actually hurt the business later. It’s very conflicting.
It is so appealing, to be able to apply the best of practices and tools. I can understand how architects that are not in touch with the realities of development, can go off on wild design fantasies. I wanted to clap when i heard Simon say that he thinks all software architects should code!