- #1: Build Classes, Not Individual Databases
- #2: Don't Ignore History
- #3: Automate All Changes to Every Database Instance
- #4: Test Every Change to Database Design
- #5: Force Clients to Break Fast When Interfaces Change
- #6: Encapsulate Database Behavior
- #7: Drive Behavior from Information
- #8: Keep a Complete Unit Test Suite
- #9: Build Only What You Need
- #10: DON'T PANIC
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
#9: Build Only What You Need
Overbuild is the great destroyer of productivity. Never have I seen that effect more pronounced than in the case of database designs. A database that does too much impedes not only its own progress but also the progress of everything that touches it.
The impulse to build more than you need now stems from the delusion that designs are commitments; that they cannot change. If you can’t change a design later, then you need to make sure what you do now will not prevent any of the features you “know” you might need later. The way people try to ensure that future features will not be prohibitively expensive is often by planning for them at the very beginning of a database design’s development. This thinking is depicted in Figure 14.
)
However, that’s hardly what happens, is it? Typically, the perfect design never gets completed and, when it does, it is anything but perfect (Figure 15). Instead, it is an impediment, stuffed full of dead weight that makes developing against it a chore.
)
The problem, depicted in Figure 16, is that you cannot successfully predict very far ahead in the future. Typically, you know what you need to do right now. You can maybe make a few good guesses about what needs to be done next. Try to guess much further out than that and the details start to fade into an impenetrable fog.
)
Because you know what you need to do right now, your best course of action is to build only the features you need right now. You can learn what a database design needs from what its client programs demand, the same way those clients were based on customer demands (Figure 17).
)
The proper way to plan for the future is to build exactly what you need now and do it in such a way that it is easy for you to change your mind. How do you make it easy to change a design later? By making sure that design encapsulates implementation details, has all its behaviors specified in tests, projects public interface changes into its clients’ code, and has the proper defenses built in against data loss.