Necessary Evil

In one of the codebases I've worked with we had a module called "NecessaryEvil". All of the dirty hacks were put in there. This had three good outcomes:

  1. We could track our technical debt by looking at the size of the module (and the references to it)
  2. Every time you saw a reference to a method in NecessaryEvil, your brain made a shortcut and instantly reminded you of how the thing you were looking at "worked" (that is: via a dirty hack, or in a non-intuitive way). This alone saved a lot of time in debugging.
  3. Over time the framework we used got more features. Every now and then we looked at stuff in "NecessaryEvil" and found things that could now be solved properly. This was highly motivational to the developers, because (a) it gave them a sense of ownership and (b) they saw the progress of the framework we used.

I highly recommend to make your "dirty hacks" explicit in your code base. Here is how you should do it:

  1. Put all the dirty hacks in a directory / module / package where possible.
  2. Where #1 is not possible: add `dirty_hack_` or `DirtyHack` in the function or variable names. Don't put this in the comments, because comments don't show up in references, call stacks or stacktraces.
  3. Add a measurement to your CI infrasture that counts the amount of DirtyHacks and references to DirtyHacks in your codebase.
Happy hacking!

Popular posts from this blog

The unreasonable effectiveness of i3, or: ten years of a boring desktop environment

Idea time: RFID+E-Ink, electronic price tags without batteries

Parsing 10TB of Metadata, 26M Domain Names and 1.4M SSL Certs for $10 on AWS