Rigidity, fragility, viscosity, opacity, immobility, needless repetition, and needless complexity are all so called “design smells”. Vague sensations that make software developers pause and think “Hmmmm, something’s off…“They are a natural outgrowth of time; the eventual wear and tear that comes from building software. Since “design smells” are pretty much inevitable, the whole idea behind agile development is to get better at detecting them, diagnosing them and solving them.

This strikes me as a pretty interesting framework and immediately, calls to mind the various parallels software has with living organisms.  Practices like paired programming, testing and refactoring I liken with things like diet and exercise; preventative measures that augment our baseline and familiarize us with our body/code. The use of Agile practices makes better developers who know when their code starts smelling funky.

When diet and exercise aren’t enough and we aren’t at 100%, we try to figure out what’s wrong with us. Enter design principles, the concepts that give some sort of identity to your code’s stank. They tell us why a certain function is being rigid or opaque and that knowledge it is often the first step towards fixing it.

If Agile principles are your visit to the doctor revealing your strep throat, than Agile patterns are the antibiotics you take to make it go away. They give you the tactics to deal with your code’s particular ailment after you know what’s wrong. Sooner or later you/your code are better and you can just focus on Agile practices until something else seems off and your code starts to stink again.

Here’s some interesting way the metaphor seems to extend:

  • The “healthier” your code is from using Agile practices the quicker your recovery time when it gets stinky.
  • Like taking too many vitamins or antibiotics when you aren’t sick principles and patterns can be harmful if the code doesn’t stink.