Posted by David Hamrick on
One of my favorite programming books is The Pragmatic Programmer by Andrew Hunt and David Thomas. I have re-read this book so many times now you might think I would have the hang out of it by now. But each time I read it reminds me that I should be doing something better. This time while reading it the following passage stood out.
Details mess up our pristine code - especially if they change frequently. Every time we have to go in and change the code to accomadate some change in the business logic, or in the law, or in management’s personal tastes of the day, we run the risk of breaking the system - of introducing a new bug.
I can’t count how many times I’ve been in a situation like this. Someone will come to me and ask for a simple change. Change the font from Helvetica to something else everywhere inside the app, make a setting to access a staging server instead of a production server, or change the frequency that an advertisement will show up in some list. All of these details don’t belong in the main codebase, they should be in some kind of a configuration file. But when there is a deadline looming it’s easy to make decisions that are short sighted.
One of the great things about doing work for clients is that you get to start fresh every few months. It’s true that you have to maintain older projects. This is a great opportunity to learn from the mistakes I’ve made in the past and improve upon them in new projects, and possibly bring those ideas back in to older projects.
In 2012 I am going to make a conscience effort to create metadata-driven applications. It will take more effort up front, but I believe that the payoff will be worth it. Because requirements and details change, and I want to be ready for them before they happen.