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