We are taught, in the schools of software development, computer science, and Microsoft Certified Solutions Developer, that programs, systems, what mortals may know as “applications”, should be designed and built as three tiers. It’s a famous notion, even covered in detail on the Wikipedia. Admittedly, the Wikipedia article talks about “n-tier” systems. Same difference. The point is, you got layers, well-defined, with harsh edges of interface between them. The nod to “n-tier” was probably just some overly-academic computer scientologist somewhere who decided that we gotta go general with this, make it abstract. I suppose sometimes you need more than three tiers.
How much more?
I was born in the World of network and system administration, and my native language is Windows point-n-click. If you’ve done that for a while, and then gone on to see other sorts of systems, you’ll probably agree that there isn’t much “tiering” going on in a typical Windows operating system. There’s bits of it, sure, but little bitty bits, I’d say. To be fair, it probably gets to feel like that in any sufficiently large computing system, eventually.
But the World in which I was born has undoubtedly (that’s a pretentious word, isn’t it – “undoubtedly”) had an effect on me. Simply put, even though I took Pascal in high school, and assembly language in college, I just didn’t have some of the rigorous or experience-based computer programming education that I probably should have gotten. I grew up in more of an attention-deficited World, where expedience was highly important. I learned to CLICK, often before I pointed. That has its good side and bad side.
On the bad side, when it came time for me to fully immerse in a complex language and development environment, where there seems to be an unending opportunity to find ways to over-engineer – well, I started building “3.14-tier” systems. C# and the related technologies of a .NET system on a Microsoft network are just such an environment.
If you haven’t gotten the joke yet, please note that “3.14” is the most recognizable layman’s form of the irrational number called pi. Note too, it is more than the magic number of “3” (as in, “tiers”), and it is IRRATIONAL.
Please note that “irrational”, in mathematics, means something very specific. It means that the number cannot be expressed as the quotient of any two “rational” numbers. For example, twenty-two divided by seven comes close to pi, but not really.
“Irrational” also means that a thing does not make sense.
Irrational numbers are very interesting, as are irrationally designed and developed software systems.
I am a great gatherer of ideas, books, thoughts, articles, essays, favorite trusted authors, etc, etc.. (In a future post, I will compile much of this into “A C# Programmer’s Book Shelf” – stay tuned.) A few years ago, I somehow came across a wonderful book called The Art of UNIX Programming. You can buy it from that link (and I’ll get an Amazon affiliate commission). Or you can easily find it online for free in various file formats. Either way, I’d highly recommend you read it even if:
- .. you are not a UNIX programmer.
- .. you are not a programmer at all.
It’s really that good.
On to some techie stuff: Each time I pick-up this book, I find some true insights into my own relationship to my work. For example, the quote below is from a chapter which talks all about this tiered system design concept. Reading it, I realized, first, that many of my designs were really quite nasty. And second, I realized one of the reasons that many of them have probably turned out that way.
One of the lessons Unix programmers have learned over decades is that glue is nasty stuff and that it is vitally important to keep glue layers as thin as possible. Glue should stick things together, but should not be used to hide cracks and unevenness in the layers.
The Art of UNIX Programming, by Eric Raymond
You see, I’ve created a lot of layers with cracks and unevenness.
A designer who is aware that the glue layer exists, and tries to organize it into a middle layer around its own set of data structures or objects, can end up with two layers of glue — one above the midlayer and one below. Programmers who are bright but unseasoned are particularly apt to fall into this trap; they’ll get each fundamental set of classes (application logic, midlayer, and domain primitives) right and make them look like the textbook examples, only to flounder as the multiple layers of glue needed to integrate all that pretty code get thicker and thicker.
The Art of UNIX Programming, by Eric Raymond
I think I once heard that situation described as “ravioli code” (as opposed to “spaghetti code”).
So, they say that once you recognize a problem, you can move on to dealing with it. Truly, I am only a few years into my career as a full-fledged software developer. I’m just getting to the top of my first mountain, and ready to run free down into a great valley.
All I’ve got to do is remove the extra .14 from all of my systems.