What do I do for a living? Magic stuff…

People don't understand me. Well, people at work don't really understand what I do. Especially, project managers get frustrated when I (or my team) haven't delivered some obscurely titled document. I broke their check list, and now they have to worry about the project running late. The people who believe they pay for the new IT … Continue reading What do I do for a living? Magic stuff…

Ghost structures

Geoff Manaugh's blog post about "ghost streets" (Bldgblog) is fascinating. Cities around the world are filled with streets that are no longer streets. It isn't too hard to spot the diagonal, no-longer-street "street" in the above photo because of its clear impact to the surrounding buildings. It seems to me that this phenomenon doesn't just apply … Continue reading Ghost structures

Spot the Agile cowboys

We live in interesting times. Microsoft is selling Linux-based software. Banks are adopting Agile. I must admit that I've had a mixed relationship with Agile, but I was pleasantly surprised after attending Ilan's Scrum training this week. I left with a sense of relief as common sense seems to prevail. Agile isn't about speed; it's about delivering business value … Continue reading Spot the Agile cowboys

Compound interest of alignment

If software solidifies organisational structure, then what happens if you re-structure? Brooks in his "The Mythical Man-month" cited Conway's seminal paper on the relationship between software and organisational structures - the basic idea is phrased as: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the … Continue reading Compound interest of alignment

The answer is obvious

My "old" research supervisor once told me (slightly paraphrased): "Once you know the right question, then the answer is obvious". Of course, the real trick is to find the questions that you can answer with very limited resources - without limiting yourself to what you already know; or think you know. And therein lies the all to … Continue reading The answer is obvious

To-be or not to-be; as-is the question

I did a quick survey of the software architecture literature on my book shelf (physical and virtual) this rainy Easter weekend for guidance on how to model a "transition" or "interim" architecture. As there was almost nothing on the topic, the next stop was Google - only to re-affirm my growing suspicion that book authors perceived … Continue reading To-be or not to-be; as-is the question

Everyone is (not) an architect!

It continue to amaze me how willingly people offer their advice on software architecture. Most people would struggle to understand the inner-workings of email, but that doesn't seem to stop them. And if they do have some experience with the topic - regardless of how long ago - some people think they are experts. I'd never give … Continue reading Everyone is (not) an architect!

Simplicity, Design Elegance and Architecture

Chris Aitken's article "Simplicity is the ultimate sophistication" had me intrigued and well worth a read. If nothing else to acquaint yourself with the described architectural principles and the idea of 'principle assertions' – statements that are either ‘true’ or ‘false’ depending on whether the principle is evident or not in a given architecture specification. The Principle of … Continue reading Simplicity, Design Elegance and Architecture

Bob, iPhones and software vendors

You meet Bob at the local coffee shop. You don't really know Bob, but one of your acquaintances suggested Bob after you casually mentioned your need for a new mobile phone. You checked out Bob's website and you are fairly sure that Bob didn't write any of the available material himself. At the coffee shop, you … Continue reading Bob, iPhones and software vendors

Conway’s Law and Technical Debt

Everyone wants to be agile. It is the catch cry of the day, along with cloud computing, big data and payments processing. Agile software development boils down to do more with less, and communicate more with less. Do more with less is about using fewer but better suited tools to improve productivity. Communicate more with less is … Continue reading Conway’s Law and Technical Debt