Sure, lots of you have tinkered with a programming language - perhaps even written a web application (or website) or two. For every professional software engineer creating incredibly complex and scalable systems there are a thousand nOObs that have created rudimentary php, asp, or jsp applications.
Eventually, when people actually began using these applications, you quickly realize your work of art is an unscalable maintenance nightmare. Every requirements change, every renamed field, every unanticipated enhancement request became the bane of your existence as you got lost reading your own code. Even worse, the changes you introduce end up breaking stuff elsewhere in your code.
Your professional application developer buddies start talking to you about 2-tier, 3-tier, and N-tier, but they might as well be explaining quantum physics. What does all this mean? After all, building a good web app just involves creating some tables in your database, and then create some pages to read/write that data, right? RIGHT?
Without going into a lengthy treatise on the wonders of multi-tiered application development, I will, instead, describe the lunch I had today. The cafeteria where I work has a lunch special designed for us wage slaves - soup and sandwich for the princely sum of $1.99. Plain, not very filling, and you'd be hating life if you ate this every day - yet it provides an interesting springboard for my analogy.
The Soup
Imagine your run of the mill minestrone soup. Two dozen ingredients mixed up all together. Like mom used to make.
Ready? Ok, now think of your last web application. You probably had some pages that showed tabular data. Maybe if the user clicked on a particular row it would show some pages that allowed to edit or delete that data. All of these pages probably were wired up so that you take input from the user, stuff it into some SQL, and send it off to the database. You probably also had some code that retrieved some data from your database, and then formatted it to show to the user.
Sounds pretty straight forward, right?
Ok, now what if your database schema changed? What if you had a table with first_name and last_name, but someone decided you need a field called middle_initial. What if every page you had referenced this table in some fashion - all in a slightly different way? Now imagine if you had several hundred pages. That's a LOT of find-and-replace to do.
Perhaps someone wants to make a more fundamental (and involved) functional change. Let's say you were creating an application to approve mortgage loans. You create a very involved algorithm to determine eligibility (your business logic, so to speak) with so many conditions and constants that it's a spaghetti-disaster waiting to happen. All of a sudden your client wants you to use different parts of this algorithm and different variations of this algorithm on different pages of your application.
Give it half a dozen cycles, stir, and you'll end up with one big mess. You'll have pages all over the place. All your business logic (the aforementioned algorithm) is spread out across multiple pages. You have sql statements EVERYWHERE. When creating new pages, you write new functions and queries and begin to worry if they matched the ones you've written on earlier pages. Meanwhile, as requirements are changing, your application starts to increase in size and dozens more pages are added.
Ok, here's the straw that broke the donkeys back. You've built your humongous 500 page web application using MySQL. Your client just asked you to make it work with Microsoft SQL Server. Woah.
Are you still imagining your minestrone? What would happen if I handed you a bowl of that soup and asked you to replace all the carrots with peas? Or perhaps I'm allergic to chicken stock and I ask you to replace the soup base with beef stock. Naturally your first reaction would be to go back to the kitchen and make a new batch of soup - which is exactly what most new developers do when they reach critical mass. They build a new application from scratch with some tips and tricks they've learned.
The second time around, you'll get a bit further but eventually you'll discover that your code has once again turned into one huge homogenous mess, just like a bowl of soup.
The Sandwich
Now imagine a BLT sandwich. Simple cafeteria fare. Ok, got it? If I told you to replace the bacon with chicken - that'd be a no brainer. Take out the bacon, put in chicken, reassemble the sandwich. Don't like lettuce? Fine, just take it out. The sandwich STILL WORKS WITHOUT IT.
You're probably thinking, "Wow! My application should be less like a bowl of soup and more like a sandwich!" Well, at least I hope that's what you're thinking.
