Layers: A System of Patterns

I found this article to be, for the most part, too focused on their example of TCPIP and not worrying about more common (to a software engineer) layers typically used in programs. Perhaps this is because network traffic has been the subject of so much work and such wonderful design that it's difficult not to talk about it.

However, what this paper made me think about, especially when it started talking about how to address applying layers to programs that already exist are the sorts of programs I deal with at work. Most of them are fairly standard sorts of large applications. There's a front-end with some processing power sitting on the user's computer, and a connection to a database sitting somewhere in the network. What gets me thinking is some of the development effort that's going on right now that's trying to replace the front end of the system, which is a strange combination of technologies form various time periods, and how much pain that process seems to be bringing. A lot of discussion these days at the business is focusing on the expanding mobility options that our users are getting, whether it's netbooks, iPhones (or other smartphones), touch tablets, or some other system it seems like our users' demands for greater coverage is running into the fact that our front-end simply isn't designed to handle these things. And I haven't heard a single word that the redesigning we're currently doing on our frontend is focusing at all on making expansion into other platforms easier. I bring this up also because there was an earlier chapter from the Beautiful Architecture book "Making Memories" that talked about how the team put a lot of effort into separating their business logic away from their front-ends as much as possible, and unfortunately, in the products I work on I'm not seeing much of that. This seems like an especially good idea because of the mobility I've pointed out before. Sure you give your teams massive headaches initially in making sure you've split everything out of the frontend, but when it comes time to move your system over to a smaller app, or to work in a totally different environment the engineers will probably be happy not to have to reproduce all of those workflow specific things. To answer my question about where I see the most changes (as though it were not already obvious), I'd like to see more changes on the front-end as I've described (it would also make fixing bugs much easier since workflow issues should cascade automatically). Unfortunately I see more work being done on backends and network efficiencies, like most of the Facebook paper from earlier this week concerned itself with the handling of user data and then talked about the necessity of adding another scripting technology to further impact frontend performance.

In one of my classes recently my group chose to design an simple interactive game. We sat down and went through the initial design steps, and did a good job of getting our major pieces in place and interfaces setup. Unfortunately, as time went on, I kept finding myself having to poke into the calls produced on the other sides of some of the interfaces because the transparency of the data wasn't what I wanted or I didn't know I was going to need something like that again. Thankfully my piece of code was mostly on the backend logic side of things, because the number of relayerings and other reorganizings I saw on the level above me made me glad that my code area remained relatively stable. Perhaps some of the steps from their guide, specifically number 8, Specify Communications between adjacent layers, would have been useful for my segment, whereas the levels above me saw that code shuffling from a lot of issues with decoupling and an unclear understanding of what service they were precisely supposed to be providing (numbers 9 and 6 respectively). From what I can remember, and this is also unfortunately true of some of the code I've seen in other places, we almost totally ignored creating a unified response to the issue of error-handling, and simple discovered them and handled them as we went. It made the system workable, but there was little in the way of a codified approach.