Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, take a look around and give NDepend a try.
I write for a number of different outfits and earn my living consulting around software and IT. Because of the intersection of these three concerns — writing, offering advice professionally, and software — I field a lot of requests for advice on how to do the right technical thing without everyone around you shooting holes in it. Consider an example.
“How can we get started with unit testing?”
Considered as a technical question alone, this invites a fairly obtuse response. “First, write a unit test. Second, run the unit test.” Obviously, that’s not really what anyone is asking when they ask this question.
Instead, they want to know something orders of magnitude more complex. “How can we overcome years of inertia, a nasty legacy codebase, Bill, who has been around for 40 years and hates everything new, and the fact that management doesn’t want to pay us to write ‘extra’ code… and then start unit testing?” Oh, yeah, that. Well, that’s complicated.
I frequently hear such apparently-innocuous-but-actually-complex questions about code quality. “This idiot on my team is writing mountains of the most unmaintainable garbage imaginable — what should I do?”
Usually, this sort of question comes to me from people at client sites. And, accordingly, I have to balance the answer that makes the most sense for the individual with the one that keeps the client’s best interests in mind. The client pays my bill, and I have a charter to lower the cost of ownership and development of their code.
But when I’m in writer mode, and only the asker’s interests matter, I’l give a subtly different answer. Today, I’d like to offer advice on what you should do in this situation.