Dirty code? If it works, leave it says Thoughtworks CTO

Dirty code is a fact of life, and working out which software really needs changing and leaving the rest will help many IT organizations gain at least some of the benefits of going Agile, ThoughtWorks’ CTO told the Continuous Lifecycle conference today.

Keynote speeches at software conferences often paint grand visions for development nirvana, which might make sense if you’re building systems in a green field or can simply declare IT year zero.

But Dr Rebecca Parsons said that few organizations were really able to kick off with a clean sheet.

She said her career has spanned academia and the “real world.”

She put software quality at the top of a list of actions to ensure that companies can adopt agile methodologies. This would allow them to perform more “experiments” or make more bets that would get features to users more quickly, and contribute to their firms’ longer-term survival, rather than relying on five-year plans that will be rapidly overtaken by real-world events.

But, she said, this still had to be done from a pragmatic standpoint: “The academic in me would love to say no dirty code should ever exist and everybody should be on a mission to get rid of all dirty code ... I would love to be able to say that, but I can’t ... but we do have to take software quality into account because bad code is harder to change.”

She said this meant at least starting to build “evolvability” into code, which meant “having the system be easy to change, regardless of how you need to change it. Because if you’ve made something adaptable and you need to change it this way, all of the work you’ve put in on this [other] dimension is wasted.

“The single most important [metric for success] we’ve found is readability and understandability. If you can understand a piece of code, it’s much easier to change.”

When dealing with existing systems, she said, you should check the source control log, but also talk to business users to see what their plans were – and to operations, support and other departments to find where the problems were. “And then compare all of those different lists.”

“You might have a complete disaster in code ... that hasn’t been touched in four years, that is actually working pretty well now finally, even if it is being held together with duct tape and baling wire. And hopefully by the time I have to change it, it’ll be so far out of date that I can throw it away.”

“The purist in me would like to say you still need to clean it up because it’s terrible. The pragmatist says ignore it, it’ll go away. I want to focus my attention on the things that are changing, or are contributing to current instability, or operations having a tough time. Look for those places and focus your attention on making those places understandable – so you can start understanding the changes you’re going to make.”

This fits in with a world where lowly IT functionaries could not hold up change anymore, but where businesses were demanding systems work the way the business did, she argued.

Parsons added that after years of IT being seen as a cost center, where costs had to be squeezed out and standardization imposed, businesses were now demanding they support experimentation and innovation. IT departments had to be able to experiment, and those experiments had to be allowed to fail – sometimes, at least.

“It’s not OK to be stupid,” she said. “It is OK to try something that has a good chance of success ... and you test that out in the market and it doesn’t work.” ®