Would you like mustard on that?

There’s a lot of talk these days about software factories. And books about software development borrowing from practices and processes used in automotive manufacturing. This is based on the premise that developing and delivering an application or functional enhancement is as complex as building an automobile, or locomotive.

When one is working in an IT department, however, many of the work requests that arise are actually fairly simple. If one then takes these simple requests, and treats them as if they were complicated, they become complicated. And this complication leads to extended delivery times, and large expenses, and increased risks of failure.

Here’s the analogy. When one orders an automobile — and they can manufacture it to order and deliver it in only a few days — that’s impressive. But when one orders a pastrami and provolone on rye with roasted peppers and a pickle — that estimate of “only a few days” starts to seem a trifle excessive.

We don’t have methodologies — even “agile” methodologies — that model application delivery in an IT department (or even a part of it) like a delicatessen. Every sandwich order may not require baking the bread, smoking the beef, growing the peppers. Inventory management in a delicatessen is not quite as structured as in an automotive factory. So when somebody from “the business” requests an application from IT — and gets something within the day — it is cause for astonishment.

I’d like to think that with the proliferation of modern tools, libraries, frameworks, and environments, that we could be as responsive — sometimes — as the counterman at the deli.


What's GNU?

What's GNU.jpg

It doesn’t mean what you think it means.

What's GNU back.jpg

History teaches us …

I was on a conference call with a group of IT application architects, and, with a few minutes left until the end of the scheduled hour, the summary of the meeting began with that phrase: “History teaches us …”. As an amateur historian, my interest was immediately piqued. The end of the sentence was “that a three-tier architecture is the best architecture.”

Had it not been for that three-word preamble, I would have let the assertion stand unchallenged. But Clio had been summoned — and I had to disagree.

Frederick Lanchester, was the first person to try to apply mathematical modeling techniques to warfare. In the early part of this century, he developed the Lanchester equations to model armed conflict. I came across an article of his as a child in a collection of books ( © 1956), still available today, The World of Mathematics.. Lanchester looks at the tactics of Napolean in the Italian campaign against Austria and Lord Nelson at Trafalgar to illustrate his point. The lesson that I learned from that history (although there are others to be learned) is that the most effective tactic is to split one’s opponent into two nearly equal halves. The reason for that is related to the effectiveness of the fighting forces being proportional to the square of the size.

Software complexity, also being proportional to the square of the size could very well learn this lesson of history; in which case the correct number of tiers might well be two.

William of Ockham (who lived in the fourteenth century) is famous for Occam’s Razor (also known as the “law of parsimony”):

“Entia non sunt multiplicanda praeter necessitatem” (“Entities should not be
multiplied unnecessarily.”)

This is often simplified to “keep it simple, Simon”.

Although famous today for the Razor, in his own time, William was famous for being a nominalist. Nominalism holds that there is no underlying “truth” to be discovered — rather, things mean what we all agree that they mean — and we can choose to agree differently — which will change our perception of reality. In other words: That word does not mean what you think it means.

So, when someone asks the question: “Do you agree that a three-tier architecture is the best architecture?” some people might think that a “tier” has some divinely-inspired (if they are Medieval) or expert-defined (if they are contemporary) meaning, and that the question was meant to elicit a discussion around the variable “three”.

But a nominalist, who has read Lanchester’s article in The World of Mathematics might know that the number is a constant; that that constant is “two”; that the variable is “tier”; that the question is wrong; and that the correct question is “What is the meaning of “tier” for which a two-tier architecture is the best architecture?”

Aha!, the discerning reader exclaims. Why not assert a priori that “three” is the correct number — having attended Catholic school, this seems perfectly reasonable — and the correct question is “What is the meaning of “tier” for which a three-tier architecture is the best architecture?” Then, I would have agreed a priori with the initial premise, and we would have all move forward unanimously. But this line of reasoning springs the trap laid by William with his nominalist Razor.

For if it is true that there is a definition of “tier” for which a two-tier architecture is the best architecture, and there is a definition of “tier” for which a three-tier architecture is the best architecture, then by choosing “three” a priori, you have multiplied an entity (entia multiplicanda) needlessly.

Therefore, history teaches us that a two-tier architecture is the best architecture.

The lessons of history are not easy to identify, interpret, or internalize. I love the fact that I work at a place where we try to learn them.