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.
|
