Singular Technology

My son is nearly two and has encountered his first homonym. His word for horse is “neigh-neigh,” which makes perfect sense given that R’s are still too difficult for him to pronounce. He calls his Aunt Renee “neigh-neigh”, presumably for the same reason. He seems to have no difficulty grasping that two completely different words are pronounced the same way.

This occurred to me the other day when someone remarked that technology choices are singular. That’s actually a double entendre. It was meant in the sense that one’s technology choices have a distinguished role in the success (or failure) of a software project. Use an ORM if that would simplify development, for example. Consider using CORBA if you have communicating programs written in different languages running on heterogeneous hardware. That sort of thing.

I however misinterpreted the term to be meant in its linear algebra sense. A singular operation is not invertible. For example, after you square a number, there’s no way to know which square root was fed into the squaring operation. Nine is the square of both three and negative three. Given this flavor of singular, the phrase “technology choices are singular” seems even more true to me than the other interpretation.

I think it was Ted Husted who remarked that with so many Java web application frameworks to choose from (Struts, JSF, Shale, etc), it’s more important just to choose one than what the particular choice is. However once such architectural choices are made, it’s extremely expensive to undo them. This is actually one of the working definitions of architecture that I hold in my mind.

Architectural decisions (as opposed to plain old design decisions) are the ones that are too expensive to get wrong.

That’s not a complete definition, obviously, but it’s brief and useful. As an architect, on those occasions where I can’t persuade, nor am I persuaded, I have to consider pulling rank to get my way. Unless the cost of taking the team in the wrong direction is too great, I usually concede technical decisions to be design decisions, and therefore not in my bailiwick.

I once worked on a team that got an important architectural decision wrong. We chose CORBA to allow cooperating programs to communicate. That might have been a good move if we had to worry about

• Endianness


• Different languages, or


• Operating system independence

Unfortunately none of those factors were in play. Moreover, our code ran on embedded hardware, and the CORBA footprint turned out to be uncomfortably large. Years later, they’re still stuck with it. Some of the reasons for the inertia are enumerated below.

• Resources are allocated to develop new features instead -- Refactoring is often hard to justify to management


• Lack of training in new technology -- An obvious point for developers, but don’t forget sales and support!
• Previous decision is exposed to customers --It’s hard enough to change, let alone retire, public APIs


• No clear roadmap to migrate to new technology --Typically must keep existing product running, but should avoid big-bang integrations


• Emotional ties make change difficult --Thanks for working 60 hour weeks, now we’re scrapping it

Therefore, costs are not only financial. Many factors can conspire to make decisions singular. Pun intended.

That team got other architectural decisions right, and I’m sure I’ve worked on other teams that got many architectural decisions right. But I hardly remember those decisions. In my memory, the only choices of note are the ones where I’ve later been asked to take the square root.