In a way everything in software development are temporary solutions. It's silly to think that one implementation will live on forever. But some tem...
For further actions, you may consider blocking this person and/or reporting abuse
I once wrote a conversion script from scratch, which worked first time through. It was a "one-off", so I didn't bother keeping up with.
A few months later, we figured out that the underlying code that had made this migration necessary never got updated, meaning that we needed to run it again. I couldn't find what I had written, and I must have had 5 or 6 bugs in my original recreation of it. :/
Lesson: always save everything you write, particularly if it's the elusive first-time-worked unicorn...
This happened to me a few months ago : I wrote a "one shot script" which was fully functional but far, far, far away to be optimized.
I remember what my manager said to me : "Da hell no! We don't need to optimized a one shot script! Are you crazy?!"
Today, we keep using this script and he is optimized af... --"
Glad my last few days have been an inspiration for this article 😂
I have found somewhat of a mitigation to temporary solutions. (Because it's all temporary solutions until the software dies, amirite?) The mitigation is obvious in principle: write code that allows itself to be easily refactored or replaced. But how? What works for me is to write important decisions as pure functions 1. Important decisions might mean "whether or not to display this element" for front-end work. Or "what things should happen as the result of this request" for back-end. Decide first, then perform side effects (e.g. modify DOM, save to db) separately from decisions, because once you tangle decisions and side effects, the decisions become harder to understand and even harder still to separate out again. I've also found that pattern matching on these kinds of solutions (separating decision from effect) breeds more of the same in a good way.
If you think about it, humans work this way. Your brain makes the decisions first (sometimes subconsciously), then instructs your body to act on them. Unless you are Ash and your hand has a mind of its own. Can't help you there.
I use a particular paradigm (Functional Programming) and languages (F# / Elm) that encourage me write code this way. But it's possible to do in the OO paradigm / languages with some discipline. The discipline becomes easier once you get bitten pretty bad... the value of it starts to become clear. :)
That doesn't automatically fix the mountain of tangled code I already had, though. :(
This is an important topic. I have seen "temporary solution" last for 10 years (literally), and who knows how many other solutions they "inspired." Comments stating "TEMPORARY SOLUTION - REMOVE BY XYZ" don't change the lifecycle almost at all, but they might help developers not to take inspiration from it.
In general, I have come to believe that "temporary solutions" do not exist. Any solution that is shipped without a clear, scheduled and immediate plan to be replaced, will stay forever. Even with such plan, it takes a lot of discipline to remove something temporary that works.
Well said, Ben! I think what can prevent the virus of temporary solutions from spreading are leaving @todo comments when you need to make them.
ex:
// @todo: this is a temporary solution because ....
This has helped me save a ton of time because I can move on quickly while being sure that it will be revisited. :-)
Ultimately, everything is temporary.
This too shall pass.
The reason temporary solution/hack happens at all is time constraints, developer thrive to write "good" code, but it takes time and business/personal constraint force us to rely on shortcut to deliver product in a reasonable time.
Ideally we should have time to replace these temporary code, but again time is a finite resource.
This exact line of thought comes into my mind when ever someone says this is a temporary fix. All changes we make will live on longer then we first expect. Always good to keep that in mind.
So true, well said.
Bugs will come anytime.