There are many metaphors about software design that I think are useful. Unless you’ve written code, it’s very hard to describe the software engineering process in a palatable way. More specifically, it’s very hard to explain what decisions we have to make, why, when and how we have to make them. That’s where a good metaphor comes in. Here’s the latest one I’ve thought of.
Software engineering is a lot like driving a stick. As you start, you’re on first gear- coding away at a steady pace. The more you code, the less efficient you become. At some point, you have to shift up a gear.
Shifting up a gear, in programming terms, is cleaning up your code. Taking a step back to refactor, abstract, or implement a pattern. It means taking time to consider how to change your habits at a particular point in the development process. Doing this does not mean you’ve made a mistake (as some might argue). It’s natural and necessary. You have to shift in code just as you have to when you’re driving. But, if you do it too soon, you’ll spend a lot of time trying to regain your speed. Do it too late (or not at all), and you’re code will burn out. Knowing when to shift is essential. It keeps the development process running as efficiently as possible. You don’t shift just to shift… you have to do it when it’s right.
The one drawback is that software engineers cannot undo or shift down a gear with ease. If we want to start back at first gear, we have to idle the car. We’re starting over. (Unfortunately, this happens sometimes).
The one benefit, however, is that there are no set amount of gears in software development. We can choose to have just 5 or 500 gears in our programming transmission. This depends on the complexity and scale of the project. For more complex projects, having more gears means we can shift a lot more often. It means that if we shift a little too early, it won’t take us too long to get back to speed. A little too late, and we haven’t experienced to much burnout. For smaller ones, just a few gear shifts will do.