DEV Community

Ben Halpern
Ben Halpern

Posted on

The problem with temporary solutions

In a way everything in software development are temporary solutions. It's silly to think that one implementation will live on forever. But some temporary solutions are more temporary than others. In an ideal world we have the time and energy to make everything perfect, but in reality it's always a tradeoff. Temporary solutions are a perfectly natural occurrence and if we didn't rely on them we'd never get anything done.

Temporary solutions often don't turn out so temporary. This is a problem, and it shouldn't be all that shocking. We move on and never find the time or energy to come back to it. Overcoming this usually involves reliable testing/monitoring to give people the confidence to make changes, along with the managerial will to accept the importance of "backtracking".

But that is not really the issue I want to talk about. The more difficult problem is the virus that temporary solutions create through pattern matching. In the absence of perfect communication and leadership, software developers rightly rely on pattern matching to contribute to a codebase. This is great a lot of the time. It is how people figure out how to be helpful on their own. Ideally developers will graduate to a greater fundamental understanding of the domain, but if that was a necessary precursor to contribution, we'd never get anything done.

When a codebase is littered with temporary fixes and implementations, those become guidelines for future contributions and bad approaches spread like viruses. The original implementer typically knows what they see as ideal even if the current approach does not fit the standard. But it's easy to forgive contributors for pattern matching and allow these sorts of contributions with the feeling of "we can keep up this style for now, eventually we'll remedy it". This is a dangerous path to tread.

It is hard to escape our present mindset when contributing code, but we must think of our code direction as something not fully in our control. Assuming any reasonable amount of success, future developers will be all sorts of different people. Experience levels and personality types will vary, and the best we can do today is set ourselves up for success and hope for the best.

Top comments (11)

danieljsummers profile image
Daniel J. Summers

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...

martyonthefly profile image
Sylvain Marty

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... --"

jess profile image
Jess Lee

Glad my last few days have been an inspiration for this article πŸ˜‚

kspeakman profile image
Kasey Speakman • Edited

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.

smashes plate on head

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. :(

lpasqualis profile image
Lorenzo Pasqualis

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.

clickclickonsal profile image
Sal Hernandez

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. :-)

eljayadobe profile image

Ultimately, everything is temporary.

This too shall pass.

dvhh profile image

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.

mrlarson2007 profile image
Michael Larson

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.

cschmitz81 profile image

So true, well said.

kenvy profile image

Bugs will come anytime.