How to Improve
After a particularly bad round of golf recently, I was thinking about how to improve my game. I thought about how we go about making improvements in anything we do. We evaluate what we have done, and based on that evaluation, we try to make changes that we think will help us get better results in the future.
I thought about what I do when evaluating and improving my database and software development efforts. And I realized how different that process is from trying to improve a physical activity like golf.
Feedback
In golf, getting this feedback is easy and automatic. You get instant feedback after every stroke. The ball either flies toward the green, or in my case, into the water. It’s easy to know when we suck at golf (though that does not mean it is easy to fix). And at the end of the round, we know how many strokes it took us to complete the round. Instant Feedback, like it or not!
Software development and database design are quite different. We don’t know until well after our software is delivered whether we did a good job. The quality of our work is best measured by how well our software empowers our customers to do better work, and in how long it empowers them to do so. Sure there are shorter term measures, like the software defect rate, and immediate customer satisfaction, but they don’t tell the real story. A truly effective software developer or database designer builds systems that last years and survive business process changes, personnel changes, and technology changes.
There is no automatic or immediate feedback here. So it is important that we stay in touch and actively ask our current and past customers (whether internal or external) how our software or database is holding up. Is it still empowering our users one year, five years, ten years after we created it? If yes — why, if not — why not. Only then will we be able to make the necessary adjustments to ensure that the next system we build will be even better.
Keep Asking
As with golf, knowing how well (or how poorly) we did in the past is definitely not enough to ensure future excellence, but measuring success and recognizing design flaws in past work is essential to making progress toward that goal in database design and software development. So keep asking.
