The two most dangerous words in software engineering are what if – as in “what if the customer wants to…” and “what if some obscure thing happens when…” I’m not talking about all uses of what if – it’s critical if you’re Thomas Edison and you’re dreaming up the next great breakthrough, but if you’re building software, what if will bury you. A what if does not imply a requirement – and spending too much time on theoretical needs prevents you from meeting real ones.
The next time you are in a meeting and someone says “what if…” stifle the scream welling up within you and politely remind your team of the YAGNI principle. Ask for the specific requirement. Inevitably, when you’re reviewing your design, someone will point out that you need to account for their favorite obscure situation. This revelation will spur someone else to mention another arcane circumstance. Some developers will consider your design a failure if it can’t easily handle these exceptional cases. Don’t succumb. Build a class that makes the common case simple and easy – tattoo the 80/20 rule to your forearm (or their forehead). Remember – making the atypical possible does not equate to making it effortless.
I’ve seen too many projects that get caught up in the cup holders and the chrome forgetting that they don’t have steering or brakes. Plan to refactor – you will anyway. It may be boring, but doing ordinary things extraordinarily well can lead to pretty phenomenal results. 37signals hits it on the head – Simple means launching something (yes Phil, I can relate!). To quote:
Moral: If you find yourself talking more than walking, shut up, cut the vision in half, and launch it. You can always fill in the gaps later. In fact, youâ€™ll know more about what gaps need to be filled after youâ€™ve launched â€œhalf a featureâ€ than if you tried to fill them in before launching anything.
I couldn’t have said it better myself.