Out of ten bullets on software architecture, this is the third: the thought that software architecture is not decided by features, or at least: that features usually only have a minor impact on the whole topic Continue reading Features. Software Architecture (3/10)
Category Archives: Software
Whatever has to do directly with software: Architecture, implementation techniques, patterns etc.
No good, no bad: Software Architecture (2/10)
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)
Software Architecture in ten bullets
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.
Bibles of Software Engineering II: “Winning with Software”
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.
Continue reading Bibles of Software Engineering II: “Winning with Software”
Quote of the day: Software Development is …
One of my favorite aphorisms about software development:
Continue reading Quote of the day: Software Development is …
Bibles of Software Engineering I
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.
The truth about the truth, and why it matters for software development
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.
Continue reading The truth about the truth, and why it matters for software development
Three types of bad design decisions
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
The importance of respect in the business of software
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”.
“Thinking Product”
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.