As IMVU and its engineering team have grown, we've encountered an increasing amount of overhead while implementing features that affect the original code for the client and web site (you may even call some of it prototype code). You know, this effort even goes back to when I started. Most of my early days at IMVU involved fixing bugs, adding test coverage, and making small changes to the product. There were a lot of things about the code that I didn't particularly like, but I chalked that up to the first time I've ever had to deal intimately with a large code base that I did not write. That doesn't mean I didn't try to improve the things that I found; in fact, it's been an excellent exercise in articulating engineering practices I've internalized so deeply that I take them for granted.

At IMVU, we practice test driven development, which means that we always* add a unit test exposing a bug in the system before fixing the bug. In practice, this means we should never see the same bug twice. Some areas of the code have seen more love than others, of course.

Recently, Andy has been trying to implement a tiny new feature in the buddy window. The kind of change that should only take 15 minutes to write the tests and maybe another 15 to implement. (And we wouldn't have to worry about other features breaking, or other changes breaking this feature, and all the other TDD goodness.) That is, if we have good tests in that area of the code. But we don't, so it's not that easy. So he gets to be the lucky engineer, adding tests to this module, which is involving a lot of refactoring. The code's style has a lot of internal consistency, and there definitely is a design, but adding tests around it has proven to be a huge time loss. So we've been trying to articulate why the code is such a pain. But James Shore explains it exactly:

"...the goodness of a design is inversely proportional to the cost of change."

And there we go. That sums it up.

* Ideally. We're always improving.