About this Book
As a codebase grows large and more complicated, and they often do, there usually comes a time when you want to improve portions of it to meet new functional requirements, new legal requirements, or a new business model. You may also just want to change it to make it more comprehensible. For small changes, you can keep things straight in your head, but for larger ones the chances of getting lost on a sea of broken code increases dramatically.
As you desperately try to navigate that sea, it’s easy to start labeling the code. You can come up with all sorts of names for the code, especially bad code that isn’t fit for its purpose. Legacy code is one of the more popular terms, which literally means code someone (else) wrote and that you are now responsible for. Michael Feathers, in Working Effectively with Legacy Code (Prentice Hall, 2004), suggested it can be defined as code without tests, which has since become the de facto definition.
Another term for bad code is big ball of mud, popularized by Brian Foote and Joseph Yoder in their paper Big Ball of Mud (http://laputan.org/mud/). This paper describes a big ball of mud as “a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.” Some synonyms for this type of code are crap or a mess, and we can think of quite a few more in our native language (Swedish).