Out of ten bullets on software architecture, this is the second: the realization that no software architecture is good or bad – at best, it is appropriate (or not). Continue reading No good, no bad: Software Architecture (2/10)
A while ago, someone provoked me to put software architecture in ten bullets. Nothing that short does such an important topic justice, but these ten held up pretty well in day-to-day discussions – even though I don’t consider myself an architect.
One of the less well-known software engineering classics, “Winning with Software“, seems to have lost a bit to the current agile mainstream. But even for successful agile adoption, there is a lot to learn from this apparently waterfall-heavy masterpiece.
One of my favorite aphorisms about software development:
Some books about software engineering are timeless classics. Among them, written as early as 1975 and still unbelievably relevant, is “The Mythical Man-Month” by Fred Brooks.
Ever wondered why there is so much friction between software developers and product managers? I wouldn’t claim to have found the philosopher’s stone, though I’d offer the following partial solution, partly rooted in philosophy. In a nutshell: they are using different types of truth, and once these two are distinguished consciously, everything becomes a lot easier.
A long time ago, I had to think about architecture trade-offs and design decisions when building widely adopted frameworks. Surely you’d tell me that one just shouldn’t do such trade-offs, but in a corporate world that may or may not be an option.
At that time, it appeared to me that there are three types of bad design decisions (also known as work-arounds), and they mostly differ in their cost, and how that cost scales. So far, in every discussion I was told that it’s trivial. Still, it’s usually not observed.
Continue reading Three types of bad design decisions
I found a reference to the article “Opinion: The unspoken truth about managing geeks“.
The reference is from Awasu’s “Anti-stupidity“. Thanks for drawing my attention to it!
Thanks to both your articles, I have nothing to add.
Hmmm… there’s always something to add, so how about this: The IT geniuses I’ve had the good fortune to meet all behave like that. But with IT becoming more of a profession and less of a vocation, I see first signs of IT pros turning “normal”. I don’t like it. Respect is – for all people involved – a better currency than credit.
I’ve been fiddling with the notion of trust, especially in distributed teams, for quite a while now, but respect is something that matters as much. I guess that – keeping honest respect in mind – even the quote “Unlike in many industries, the fight in most IT groups is in how to get things done, not how to avoid work. IT pros will self-organize, disrupt and subvert in the name of accomplishing work…” is not correct: I believe where mutual, honest respect is handled well, it will lead anybody to accomplishing their best and a little more. Which in turn tells us a bit about “most industries”.
The other day, a friend gave his parting presentation titled “Thinking Product!”. One really nice metaphor he used was: Making standard software is, in many ways, like making cognac:
- First, we try to bring the essence of market demand into the product, along the entire value chain – very much like good cognac brings the essence of the grapes through the distillery.
- It’s the essence of the market (not just the wishes of one individual customer) that we are trying to realize – very much like no cognac fan is looking for the taste of a grape – that can be achieved by eating the grapes individually (or making custom development, respectively)
- Eventually, when the time comes, cognac is sold by emotion, not because the company has the best chemical processing equipment. In the same way, we shouldn’t sell the how the software was made but the benefit it brings.
One may like brandy or not, but I do like this example.
Now this may or may not be rocket science, but introducing a systematic architecture approach has turned out rather tricky in the past.
What I’m doing now is working with the Architecture Challenges paper by Charlie Alfred.
In an environment where nobody has the time to “sharpen the saw”, introducing this as a mindset was tricky – and then again, eventually it worked out.
I’d like to thank the colleague in question to keep an open mind and, “despite” 20 years of industry experience, still experiment with a newbie program lead on such questions. Continue reading Architecture Challenges