Don't confuse a band-aid solution with a bad solution.

Sometimes people confuse a "band-aid solution" as a bad solution.

In any business, and in particular in software development processes break. Things go wrong, or stop working. The environment changes and what once worked, no longer works. Other times, people just break things.

A "band-aid solution" to such problems is one that isn't going to last forever. It might be perfectly sound, well thought out, even brilliant. It's going to hold, cover up the problem until it is properly healed.

That's half the value - coming up with an idea, or a solution to a problem that is sound, complete and clever. The second half is in the execution. The delivery - delivery you solution in a way that sticks. In a way that is complete, and that scales - for everyone.  Otherwise it's just a band aid.

If there's a problem with something at work, at your sporting club, at home, to fix it and have it stay fixed you need to get to the heart of it. But the fix needs to be implemented in such a way that no-one else needs to fix it next time - in fact, no-one else will ever even notice the problem.

Identify what's wrong, identify what's missing, design a solution that rectifies this, and implement it - but don't just patch the gap. Put enough infrastructure, or support around your solution that it lasts. Your solution becomes part of the fabric of the system you've solved, so it can never happen again.

This might mean going right back to basics - documenting your process, garnering support for a change to the process or the adoption of a new one, roll it out, monitor it, make it "business" as usual. Then, it's fixed, for everyone, until it needs changing, or someone else decides, your solution, is a problem. Then, they can do the same. Identify, what's wrong, design a solution....

In the meantime, what was broken, can be should be fixed with the help of a band aid.

We need to fix things, so they stay fixed. Band-aids can help.