Chapter 5. You Are What You Eat

I love short cuts. On a now infamous hike, my wife was 10 seconds from calling for a helicopter because I'd left the main trail to traverse a swollen Appalachian riverbed. I loved the experience; she was less enthusiastic. Just this week, I hammered in a 1-cent nail with a $30 electric screwdriver rather than climb downstairs to get a hammer. I told myself that in two years, no one will be able to tell what I used to drive that nail home.

Sometimes, short cuts are good. In every chapter of this book so far, I've repeated that you can try simple, even imperfect solutions. After all, you can always refactor them later if you are wrong. And that's mostly true. Be careful, though. Like anything else you build, decisions that affect your foundation last longer. I've spent a good number of years helping customers with deep pocketbooks unmake big decisions. Here are some areas to watch out for:

• Your choice of an RDBMS, and perhaps the persistence layer that sits atop, lasts for the life of an application. RDBMS data and queries may be transferred to a new platform, but usually a database decision is final. Database data and schemas can usually commute, but stored procedures, user-defined functions, and triggers are less portable. Some customers pick the wrong horse and then complicate a serious problem by betting everything on that horse, basing applications on stored procedures, user-defined functions, and triggers.

• Programming languages, and even dialects, dramatically affect your architecture, programming decisions, and even your available talent. For an obvious example, consider two languages as similar as C# and Java. They're alike in many ways but will take your design in dramatically different directions. Some customers naively take small sips of freedom with tools like Visual Basic. Eventually, those departmental tools grow and escape, forcing the customer to gulp from the Microsoft fire hose.

• Beware of tools that couple. Proprietary tools often make it too easy to make sweeping decisions on the fly, without considering consequences. A whole generation of tools, like PowerBuilder and OracleForms, coupled applications to the database in unnatural ways. Only the application and database vendors came away smiling. Often, when you make the decision to tightly couple two subsystems, you lose the practical ability to separate them soon after. One of my clients used a tool that encouraged imbedded SQL in their business tier. When the tool fell out of favor 10 years later, they paid a quarter of a million dollars to rewrite a tiny frontend because they couldn't extract the business logic.

In this chapter, I'll discuss decisions that have far-reaching implications. You are what you eat, and your application is exactly what you feed it. If you give it a steady diet of bloat, you'll build bloatware. If you feed it fad diets full of temperamental, experimental technologies, you'll build finicky, temperamental systems. If you feed it those sweet and sticky frameworks that goop everything together, you'll get applications stuck together in unnatural ways. If instead you feed your code a light, pragmatic diet of the right pieces in the right proportions, then your users will love you. Your applications will take on the personality of the frameworks that you use.