Don’t Predict the Future
Today at a Glance
Don’t Predict the Future
Poll of the Day
Ask Paul Anything
Bonus Links
Don’t Predict the Future
Introduction
“But what if..” I hear this phrase often from less experienced engineers when discussion the functionality we need to build. Usually it’s suggesting functionality that isn’t even in scope.
If we’re able to think ahead, we can work more efficiently by building the extra functionality we need now. What a time saving! Right?
I remind the engineers that part of Agile is specifically not building stuff we don’t need now, and that revisiting code later is okay. Even still, there’s a look of disappointment. “But what if..”
Why it matters
I cannot predict the future. If you can, you’re wasted in software engineering. I recommend the lottery. For me, at best I can use my experience to avoid repeating past mistakes.
If we build functionality we don’t need now, and even if we’re discussing the possibilities, which can waste even more time, it’s burning resources that at best has a 50:50 pay off.
The best line of code is the one you don’t have to write
Functionality we don’t need still needs to be reviewed, tested, debugged, and maintained. I see code bases littered with unused ‘but what ifs’.
How to apply it
Even though I cannot predict the future, what I can tell you fairly confidently is that for a given code base at least some code will be added or change.
If we write code with the knowledge that this is not the last time it will be worked on, we don’t need to “kitchen sink” the code with every last feature we think will possibly be needed.
What ifs come along because we expect writing code to be the last time we’ll touch it. It won’t be, and that’s not a bad thing either. Ensure we can adapt and refactor the code later, and code necessities, not “what ifs”.
Poll of the Day
Do you plan your work before you start?
Polls are anonymous and just for fun. Voting will show you the results, but you can also view results directly here.
Do you enjoy this newsletter? It would help me out if you could share it with a friend.
Ask Paul Anything
If you have a question, large or small, you can send it here. It’s anonymous if you want.
Bonus Links
Zawinski’s Law - Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
You Aren't Gonna Need It - An excellent article by Martin Fowler on not building future requirements.
Thank you for reading Paul Codes. If you know someone that would enjoy this newsletter feel free to forward it or refer them. Referrals earn rewards.
PS. If you’re a business and would like to sponsor this newsletter, please reach out!