Layers Are Cheap, But Doing It Right Is Priceless

I've often pondered over, discussed, and lightly debated the process of designing small applications and the extent to their architecture and implementation. Usually the conversation surrounds doing it 'quick and dirty' vs. creating a 'well built and thought out' application.

Think of this old saying:

Why do we use that saying? The idea is if you do a job hastily, it will have to be thrown out and started all over again. On a larger scale maybe something like this could occur :P

This is not unlike the process of building software. Odds are if you build an app poorly to try and save time, or create a 'throw away' app not supposed to be used in production both situations will yield a front running Enterprise application. Well, not always but it happens more times tan one probably realizes when making these decisions.  If you create a poorly made application, there is a strong likelihood in the future that it will also be 'thrown out' and targeted for the old 're-write.'

I know in my years of experience I have opened many of applications of all types (web, desktop, services, etc.) that were a huge mess of code. No wonder the passionate in our industry scream from the mountaintops about things like code standards, design, architecture, OOP, unit testing and the like. Who in their right mind with any experience places 1000 lines of code behind a form with a mix of binding, rules, data access, service calls, etc. that cares about the craft of software engineering? All this does is create a pile of frustration for the next developer to jump in someone else's mind to figure out their goo of an application mess. And is there ever any commenting to help with the goo? Of course not, these same developers believe that code should be 'self-documenting.' Yes thank you, please leave me the manual to your brain so I can decipher the poop you wrote, thank you.

So why waste time with re-writing application, if we can do it right the 1st go around? Well typically this scares those concerned with timelines, as doing an application properly is perceived to take longer to create. 

"Ah this is just a little old app, do we really need that fancy design?"

Yes. Or at least closer to 'Yes' than 'No'. In the end the word 'fancy' or 'complex' is overrated and misused anyway. It's cheaper to do than you think. Let's make a real-world example to discuss. Say we are tasked with creating a small web app with a few pages pulling data from the database and in the midst we need to apply a few simple business rules. As usual, it needed to be done yesterday.

1st let's say we choose to use web forms because of it's plethora of server controls which lend themselves to RAD. You could just as easily say WinForms, WPF, or MVC here as well. MVC would naturally have a leg up here because of it's M-V-C architecture that helps start us on the proper path of separating our concerns. However we could still have fat Controllers in MVC and be in the same conversation, so the technology choice here is not the main focal point. We can screw up the implementation using any technology.

Using web forms though we might be tempted with our objective to use one of the more robust data binding controls offered that includes built in data access methods. On the other hand another quick approach would be to use basic server controls and fatten up the single code behind file to get all the requirements complete and done quickly.  All of this are poor decisions that are leading us down the path I described earlier.

I'm not advocating for a full blown Domain Model or Onion Architecture, but a simple 3-layer (UI-BLL-DAL) architecture is leaps and bounds better than a code behind file with 3000 lines of code. If you are an experienced developer or have experience designing apps, how much longer does it truly take to set up the additional logical layers?

Let's see:

1. Right-click, 'Add New Project' (BLL)
2. Right-click, 'Add New Project' (DAL)
3. Add references to new layers, create a few classes for busniess rules and data access.

OK, so this is the super simplified steps but in reality how long does it really take to add a few layers and segregate the application code? Maybe 1/2 day to 1 day for a small application. Possibly a few minutes to hours is more the reality. If you have used this in other applications, there will be some copying and pasting of basic logic (if not already refactored into a common unit) and visually copying of solution structure to help speed things along.

What's the payoff for this small bit of work up front? A MUCH better and well understood application, as well as an application that can scale better and stand the test of time longer. Splash on some code standards and common best-practices and we are making giant strides toward a better application.

I think the reality and success to this is having engineers/leaders/etc. with some experience doing this to articulate how easy this process is. Inexperienced engineers combined with nervous management concerned with timelines will most likely 9 out of 10 times agree together that the 'quick and dirty' route is a great option, and sell themselves on this idea because it's a small, unimportant application. The term 'architecture astronaut' or 'over architechting' are common buzz words that kill a good design and make those in charge feel good about essentially creating sloppy applications.

The summary of my experience is dealing with these poorly written apps is frustrating, and 5x time consuming in the long run as opposed to working on a well laid out application, no matter the size of the application. Since the cost of doing it 'right' or 'better' is so cheap up front, why not just do it? The answer should be that there is no excuse or discussion around not building applications with a well thought out design. The thought process should be applications small to large will all be done well, to prevent the known and true pitfalls that exist when creating applications 'quickly' to save time (which is an oxymoron by nature).