Someone asked me to define world-class code. Here’s what I say:
World class code to me is code that you’re rightly not afraid of changing.
There is code that you should be afraid of – I’ve maintained code before where I was not afraid of it but a more seasoned developer was, and the more seasoned guy was right: once I learned the code more and realized the obscure and unexpected effects my changes often had on the system’s functionality, I became afraid of the code too.
Code that is difficult to change without breaking something drains an organization’s energy away from innovation as more stress and struggle and people power is needed to keep the existing system running. Abandoning the code base is expensive; it’s also risky: will you really do differently with the new system?
The only way I know to make world-class code is with automated unit tests and integration tests (in the enterprise application domain, at least — maybe you don’t have to write unit tests to have world-class web apps, I don’t know). These let me make a change and find out what it did to the unit and to the rest of the system, quickly. The automated testability also drives cleaner designs, in my experience: If your code is not world-class, it will be a pain to write the unit tests for in the first place, so you’ll know earlier that your design is lacking. So, though not all thoroughly unit tested code is world class, once you have tried to write good unit tests you can tell from your experience doing so whether your code is world class.
(I am indebted to Michael Feathers’ Working Effectively with Legacy Code (Prentice Hall, 2005) for getting me thinking along some of these lines.)