Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about reversible design decisions, the cost of change curve, going beyond the requirements, and making systems configurable.
Andy Hunt and Dave Thomas are the Pragmatic Programmers, recognized internationally as experts in the development of high-quality software. Their best-selling book of software best practices, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999), is filled with practical advice on a wide range of software development issues. They also authored Programming Ruby: A Pragmatic Programmer's Guide (Addison-Wesley, 2000), and helped to write the now famous Agile Manifesto.
In this interview, which is being published in ten weekly installments, Andy Hunt and Dave Thomas discuss many aspects of software development:
Bill Venners: In your book, The Pragmatic Programmer, you suggest keeping in mind that design decisions are not necessarily final. You recommend organizing the system so design decisions are reversible. How do you balance reversibility with other concerns, such as speed of development, performance, clarity, simplicity? For example, say I decide today that I'll use an Oracle database. Do I use an Oracle-specific API to talk to the database, or a generic database API? Perhaps the Oracle-specific API is clearer or faster, but makes it harder to change databases later. Either way I'm taking a risk.
Andy Hunt:You're taking a risk either way, but I would say that approach is backwards. Instead of committing to the Oracle-specific API now and hoping it's faster, use the more general API first. If the general API is not fast enough, then make the conscious optimization decision to use the specific API for certain performance critical parts. Everybody going back to the K&R book has warned against premature optimization, and I think that's an example of it.
Dave Thomas: It also comes down to our old friend the cost of change curve. The cost of change curve basically says that the cost of making a change increases exponentially over time. There are various expressions of it. For example, the cost of fixing a bug after a system has been deployed is 1000 times more than fixing it when the system is being designed. But the general agreement is that the curve goes up non-linearly as time goes on.
The meter of the cost of change curve starts running when you make a decision. If you don't make a decision, then there's nothing to change, and the curve is still flat.
Andy Hunt: The world can change its mind as many times as it wants. If you haven't made a decision or committed yet, your cost is zero.
Dave Thomas: So rather than make a whole bunch of decisions up front and start the meter running, we try to defer each decision as long as we can. We end up with a lot of small cost of change curves, because each one hasn't had a chance to get up too high. Cumulatively, the effect of adding up those small curves is a lot less than having one curve that starts at zero that ramps up to infinity real quickly.