I’ve got Appmageddon breathing down my neck, and every time I turn around there seems to be another page which worked for years and years just fine turning up with a failure of some sort. A new customer isn’t found in the query. The contact search page renders a ’80020009′ error. I spend three, maybe four days fixing it, only to discover it would’ve been easier and faster to just rebuild the darned thing. I can’t put enough hours together to just redo the entire system, though.
Adding to the frustration, there are about six hundred thousand individual pages to convert. I look at the sheer volume of work and get night terrors. The biggest and best thing I can do for this puppy is put it out of its misery and build an N-tiered application so we can simply add layers to it as we need to.
For those who aren’t savvy computer programmers (me, for one), N-tiered applications segregate the data from the presentation (the “show me the data all pretty” part) with distinct layers, or tiers, of processing. You have your database(s) living happily on a server somewhere, and you have your web page living happily on a server in a different somewhere (even if it’s the same physical machine), and you can get your data into your web page by making calls to a “go get my data” layer in the server. Then, when you do something crazy — like, say, migrate your data from a desktop database client to an enterprise database client, for instance — you only need to make your changes in the “go get my data” layer. All the other layers will automatically receive the right data because “go get my data” knows how to get it and what to get.
And let’s say you constantly need to calculate a date…you know, like the end of the fiscal year, and the start of it, for certain pages. Or maybe you need to calculate the beginning and end of the month. Or you need to cycle through a period of six months prior to the current month. Well, all your date calculations live in a “figure out this date for me” layer, separate from your “go get my data” layer and your “show me the data all pretty” layer. This is technically the “business logic” layer, but many would argue that’s an oxymoron. There are other things the “figure this out for me” layer could do besides dates, too. For instance, you could have it figure out things like how many parts have shipped in a month in dollars. You’d go to the “go get my data” layer and then send the returned data to the “figure this out for me” layer to sum the cost or sales amount for those shipments. The total is returned to you and you can put it in your “show me the data all pretty” part as you need to.
N-tiered applications bring a lot of advantages to the table. They’re easier to maintain. Have a change to your data? Change the “go get my data” layer and the change fixes all the “show me the data all pretty” parts which use it. Need to change how stuff is calculated? Make the change in the “figure this out for me” layer and it propagates throughout the “show me the data all pretty” parts which rely on it. Very simple, very clean, very nice. But we don’t have an N-tiered application in our system.
One drawback to an N-tiered system is, you need to plan for it. You can’t just hurry up and slap it together, because you have to figure out how these things work over the long term. One advantage of being a formally trained developer is, you learn how to plan for N-tiered architecture. And you also learn the languages and tools you need to build it. I am not a formally trained developer. And my predecessor wasn’t either. Both of us are self-taught, and the consequences of that show because we have a 2-tiered system right now. The “go get my data” parts and the “show me the data all pretty” parts and the “figure this out for me” parts are all living happily (or not so happily) together on the pages themselves. So the two layers, in this kind of system, are the data layer (the database(s) themselves) and the “go get the data/figure this out for me/show me the data” parts together in one happy, crappy slop of code-dung.
A further disadvantage of a 2-tiered system is maintenance. When the database(s) change or are renamed or are somehow altered, it’s not easy to update all the stuff relying on that data. Each and every page pointed at the data will break, give you an ugly and unhelpful message, and stop showing the data all pretty. The developer maintaining such a system has to crawl through it and find every instance of that pointer and update it to the new location, on every single page, in every single application pointing to the old location. It’s a maintenance nightmare, to say the least. And it’s something my predecessor either never thought about, didn’t care about, didn’t know about, or wasn’t allowed to address.
I’m not sure why he chose to use a desktop database for his backend. Microsoft doesn’t recommend it, doesn’t support it, and offers a compact and personal version of their SQL Server absolutely free, which they do support and recommend for use in distributed applications. (They want you to use SQL Server and spend the thousands of dollars on licensing and support, but will tell you it’s okay to use the personal/compact version if you must.) A distributed application, for those of you who aren’t savvy computer programmers (me, for one), a distributed application is one which many users can access simultaneously through a network or intranet structure on an enterprise-wide basis. For me, the system I’m supporting is an enterprise system accessed by people nationwide through the intranet.
But it’s a 2-tiered application built on a desktop database backend and it’s my responsibility to make sure it works, and that I scale it up as I need to for use by more and more people in more and more locations.
It’s my dream to one day figure out how to be able to build an N-tiered application with a “go get my data” layer, a “figure this out for me” layer, and a “show me the data all pretty” layer in nice, distinct assemblies which I can call from the individual applications or pages which need to use them. To be honest, I don’t know how to do that. I can make the data come down easy enough, but I can’t figure out to how reference the assemblies doing that in the individual apps or pages needing the data. Once I figure that out, I’m well on my way to developing a system which I can proudly pass to my successor knowing it’s ready, it’s maintainable, and it’s easily scalable.
Until then, prayers for my sanity and job security are appreciated.
Have a great weekend, and I’ll see you on the other side.