Fear, uncertainty, and doubt almost surely lead to technical debt when they are left to fester in the software development process. Chances are good that you’ve seen the symptoms of FUD in your own code at some point, or at least in someone else’s. The following are a few examples I’ve run across recently, coupled with hopefully useful suggestions on how to keep FUD and its associated debt out of your software.
Unused
It is all too common to find unused variables, subroutines, or unnecessary libraries included in a program. Often they are remnants of a shoddy refactoring effort, or the result of a developer who is outside their comfort zone with the language and tools being used. This excess code can confuse unwary maintainers or, in the worst cases, cause errant behavior in the software. Clean up anything that is not necessary in your own code, and encourage others to do the same. If you are unsure whether removing a variable or library will break your code, test your suspicion instead of letting your uncertainty remain.
Duplication & Stagnation
When confronting someone with a refactoring need, how often have you heard the excuse, “But I’m afraid I’ll break something.”? The fear of refactoring can lead to duplication of code, lingering problems, and general stagnation of the code base. As Andy Lester mentions in his technical debt presentations, even the feeling that code is broken affects how we deal with it (the broken window effect). We hopefully learn more about our craft every day, and refactoring is a valuable way to apply new knowledge and best practices to our work.
Probably the best way to give confidence in refactoring is to have a solid suite of tests covering the affected code. It is very reassuring to see tests pass before and after large changes. Spending time to develop a deeper understanding of a program’s function also lends a degree of confidence — I suggest spending that time writing or improving the test suite.
Why does it work?
As software developers, we ought to be able to explain how and why our software functions, not just declare that it passes the tests. A lack of understanding can lead to unexpected behavior in untested situations and nightmares for anyone left to maintain the code. If the person who wrote it can’t explain how it works, what hope does anyone else have?
Pair programming requires talking through code as it is written, and that helps understanding a lot. If you find yourself alone, talk it through yourself or find someone to explain it to later (as part of a code review process, perhaps). Ask questions of your fellow developers when you don’t understand what they’ve written, and be prepared to question your assumptions when things don’t work how you thought they should.