This is a pattern I have observed frequently in software development. Let’s call it “patching vs. solving”. I am sure it occurs in other areas of engineering as well. I have observed it in all cycles that involve correcting problems in software. Patching – as I interpret it – fixes the …
Patching – as I interpret it – fixes the symptom for a problem. It is like applying a patch to a wound. It doesn’t heal it, but will cover it up. At least for a while. If you are lucky, it will even make it go away. Not knowing what it is may – however – not just not solve the underlying problem, but make it worse. Patching is short-term.
Solving a problem will – at least – try to determine the root cause for a problem, then address it and try to permanently correct it. If necessary, it may even require a new design, or a redesign to a given solution, in order to be able to correct it. It is long-term.
Naturally, solving a problem is much harder than patching a problem because it requires understanding the issue you are trying to solve. In addition, you also need to understand the solution that has been used so far. In order to be able to correct it’s problem(s).
This is why – I imagine – we see much more patched problems than solved problems. Naturally, this concerns me as Architect. Because patched problems are the ones that: will resurface sooner or later, will turn the code into patch-work, will decrease the maintainability of your code-base, reduce the overall quality of the code-base, will make development slower and consequently more expensive.
It really bothered me. So I thought about it. I tried to come up with an explanation for the root cause, and related it to three principal areas:
- Not enough experience: On the one hand it could be too little experience. Too little experience as software developer on the one hand, and/or too little experience with the code-base you are working on. For you as leader this is the easy one. Assign more experienced individuals, or – if you think your juniors are up for the challenge – help them with guidance or mentoring.
- Too much focus on functionality: We have all seen it. Too much focus on making functional progress. This often goes to the expense of quality. I.e. the more pressure you put on tour team to make functional progress, the more likely it is that they are going to skip one or the other “not so important” test. And this is where your spiral of doom will start: issue ► no time ► quick-fix ► new issue ► even less time ► quick-fix ► new issue ► even less time than when we already had less time ► quick-fix ► … get it? Yes, functionality is important. But keep in mind that too much focus on (too) quickly resolving one or the other issue will just create more issues in the mid- or long-run. Put focus on throughput, but not on the expense of quality. Take the time to solve your issues.
- Insufficient skill: This is an unpleasant one. Yes, the skill available may not be adequate. This can happen as well. If it does, you need to act on it. Plain and simple.
Copyright © 2012 Michael Pichler