Build for what is, not what if. We are not building buildings (the seeming immutable and hard to change), we’re building software.
It seems to me that more often than not we end up having technical debt; not because of crappy code or inattention to detail (though those do contribute) but because we spend too much time on the fringe. Have you ever known a successful golfer that spent an obsessive amount of time “figuring out” the fringe - no, they pay attention to the fairway, the green, and the traps to avoid - not “how do I play the fringe?”
As ridiculous as it may seem architects spend an inordinate amount of time talking about the “what if,” instead of doing the “what is.” We get hung up on some random business requirement and tout that the solution will fail every time because that requirement cannot be met.
Rather than building roadblocks, we seek to improve our ecosystems through refactoring and iteration - peeling away technical debt, right? So why should new functionality be any different? Instead of eating the elephant by running at it with your mouth open, brake it up, deliver reality, check out the results, then re-factor or add to it.
Rinse and repeat. It’s not difficult, but it can be perceived as boring or mundane. To that perception I say pfffft! I seek opportunities where people tell me “it can’t” or “it won’t.” Really!? I don’t buy it. If you’re sticking to a real need based on real things then why can’t it be better than it was before, and why can’t achieving that be exciting.
If you’re thinking leave refactoring for someone else to do, I’ve got future stuff to do, architect guy stuff - stop right there and get real with yourself:
When was the last time you blueprinted something that: 1. Made it to prod, into the customers hands, 2. Never had to be re-factored
Much of what we do is make mistakes, not always but some times more often than not - so why not approach the problem with that in mind; making the static “x” really good. Then go stomp around the what if (variable “y”) and if something shakes out then at least you have something solid to try it against.
I’m definitely not suggesting we ignore the “what if,” just don’t use it as a crutch to stop you from doing the “what is.”
{end-of-line}
I listend to