Summary
Think code can't lie? Think again.

Has this ever happened to you? You're sitting at your computer, mired deep in code, trying to understand what is going on, and trying to figure how to approach your changes.. and all of a sudden it strikes you -- you're looking at a piece of code and you're not even sure it's being used any place!

I have to admit that I've literally lost days of work dodging and working around problems caused by code that, well, simply wasn't being used any place. I don't think I'm alone.

When we look at code in a code base, the default assumption is that it is being used someplace. If it isn't, it's a subtle lie. It's something that could trip us up.

I think that, fundamentally, there are two different modes of software development. In one mode, we write libraries and frameworks. When we write libraries and frameworks, we don't know how much of our code is being used by our end-users so we have to assume it's all used. In the other mode, we write applications. When we write applications the only code we have to write is the code that we are going to use.

Application code has to be kept honest and the way to do that is to ruthlessly delete things that aren't being used. It's less work in the long run, and it's nice to know, when you look at a piece of code, that it is there for a reason and that you aren't wasting your time.

Talk Back!

Have an opinion? Readers have already posted 11 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.