We talked a bit about cargo-cult programming in Chapter 10, Creating a Multiplayer Experience in VR, and made you promise not to do it. To take this idea further, let's look at a phrase we'd like you never to utter: It works—don't touch it!
This isn't how we describe a robust system. If you feel tempted to say this, congratulations! You're at step one of the make it work; make it right; make it fast process, and that means you're not done. What you've created is a successful example of what your ultimate solution may look like, but now it's time to start the make it right phase. You've met the requirements for this step of your development when you can give three answers about your solution in positive terms:
- It needs to solve X
- I know it solves X because....
- I know it's safe because....
Remember these three statements. Don't skip them. You should be able to describe in clear, simple terms what you're trying to do. (Your rubber duck is a good listener for this too.) You should be able to explain why the thing you just did takes care of the thing you're trying to do, and you should be able to do this in positive terms: We needed to make sure the player can't fire their weapon while the pause menu is up. This takes care of it by having the input handler check for a paused state before it calls the fire function. Finally, you should be able to explain why this thing is safe to do: I know this is safe because we're ensuring that we clear any existing input when the pause state begins, and the input handler knows to allow only the unpause command through.
Discipline yourself to do this, and use clear, positive terms. If you're being vague, you're hiding from a thing you need to solve. Make this a habit: describe what you're trying to do, why you know your solution does it, and why you know it's safe to do it. You'll head off a lot of bugs before they ever even have a chance to make it into your software this way.