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