I was literally told to set up this new service as quickly as possible and it didn’t need to be correct or best practice because this was just a proof of concept.
Here we are 6 months later and I’m still cleaning up my own mess.
The motto I got from working at an ISP was “There is nothing more permanent then a temporary fix.”
Similarly, I’ve heard, “nothing more permanent than a 3/4 solution”, i.e. it works well enough that fixing other things always ends up taking priority.
You should read the Red hat article about decommissioning a data center. Over the period of 20 years there is a crazy amount of works well enough and no one documented it.
It will be in production for 10 years
In 25 years someone’s going to discover a dust covered raspberry pi hosting the poc service in the back of a network cabinet and unplug it, bringing down the rest of production
Young people will be hired and spend months to learn “how it was done in the old days” (it was just old stuff piled upon other old stuff).
Always implement like you’re going to turn it on tomorrow
Same with “lift-and-shift now and fix after migration” . Everyone knows nothing will be fixed and the same problems will exist, just in the new environment.
This is why I put an end date on anything temporary. If you want it longer than that, it’ll have to be fully built out.
For me it is always the emergency script for fix a problem with production that ends up being forgotten about.
You fell victim to one of the classic blunders.
And this is why bug bounty hunters get paid.
Even as a PoC, you’ll want a strong foundation to build on. Even as a temporary solution, you want to know the fix won’t fail the next time its under pressure. Even under time constraints, you want a solution that you are confident works when it goes live.
This is one reason I love test driven development. Once you have the solution, there’s somehow never time to write tests. If you write the tests first, then find the solution, there is somehow time to write them.
What’s poc?
“Proof of concept”. Only meant to demonstrate something, not actually to be used.
Don’t let the perfect be the enemy of the good. That said, it’s vanishingly rare that I’ve regretted designing something for long term use rather than just hacking it together.
Taking the extra time to document stuff, to add guard rails/error handling, to make a piece of script easier to re-use, to actually plan something rather than building it as you go… almost always a good use of time.
Amen, wizardbeard.
My boss convinced me to make a pricing calculator for our contracts using Excel with macros. I pushed back and said we need to use Power Apps, CRM, or anything other than Excel. He said it would just be a POC/wireframe we’d use to build a more permanent solution with later.
Well 5 years later, there are like 2 dozen versions floating around with different macros, pricing, etc. And of course I’m the one who gets messaged every time some makes a change and breaks the damn thing, or some sales person is convinced it’s not calculating correctly. I fucking HATE that Excel sheet.
If it’s on Excel365, you can edit permissions for specific cell ranges. That way your colleagues can only give input but they can’t change formulas or fixed pricing.
