The Tyranny of the Dancing Bear

As a software engineer, I see a lot of Dancing Bears. All too often they are a form of technical debt that comes back to hurt you in the end.

“The important thing isn’t that the bear dances well, rather that the bear dances at all!”
— Unknown Smart Person

(I really wish I knew the source of that quote; I’ve relied on it for years.)

In the course of developing any interesting project, there is a lot to build. Some parts are so sexy you are willing to sink as much time as possible into them. Some are … perhaps not so sexy, but are necessary engineering, so you do the grunt work. In both cases you may find yourself leaving Dancing Bears behind you as you code.

A Dancing Bear is a piece of code written to do a task; not to do it well, not to do it optimally, but to do it at all. Often, its value derives from how quickly you got it working and moved on to something else — sometimes unit tests are skipped for this code. Speed of development is the main driver.

Once coded, Dancing Bears come in two flavors:

1. Dancing Bears which are in dull, or interesting parts of code
2. Dancing Bears which cover sufficiently hard problems that you are just relieved you get that bear to dance at all

The first category comprise fine and lovely places for Dancing Bears to live. They bother no one with their uninspired design. Indeed, their simple, often straight-ahead approach to solving a problem makes them maintenance-friendly. Best of all you rarely need to feed those bears.

The second category is the one that really piles up the technical debt. Over time, it becomes much less interesting that your software works at all; if it is good, useful software people are going to want it to work well. And software with lots of critical-path Dancing Bears usually has trouble with performance over time.

I am big believer in the primacy of functioning code. Code that works is infinitely better than new, trim, sexy code that doesn’t work. You developers ignore this all too often. But … while those Bears dance they don’t dance well. So these Bears need care and feeding. They are signposts to parts of your code that need a further look; you can almost always improve the performance of your code by going back, patting them on the head, then throwing them out. Use the current functioning code to write tests, then use the tests to replace that Bear.

Dancing Bears are not intrinsically bad — sometimes they are necessary, sometimes they are useful for proof-of-concept, sometimes they really are good enough forever. But think about code you wrote in the past, especially code written in the early days of a project. If you look closely I bet you find a bunch of Dancing Bears, smiling up at you as they dance, albeit poorly, in you code. Smile at them, then rip them out. Your software will thank you.

Explore posts in the same categories: Tech

Tags: Design By Gravity, Software Development

You can comment below, or link to this permanent URL from your own site.