What to Do When the Code Sucks

DZone 's Guide to

What to Do When the Code Sucks

Simply saying that code is bad isn't terribly helpful, and from a leader's perspective, could reflect badly on developers.

· Agile Zone ·
Free Resource

I've written a few times about people saying, "This code sucks." Most of the time the sucky code in question was written by somebody else — another employee or a different vendor.

On occasion, it was written by the very person who is talking to me about it, usually 6 months or more in the past. That is always a fascinating conversation, but that is not what this blog is about. This blog is about the other situation: "This bad code was written by somebody else and it is bad, bad code."

As a manager, I just believe now that every developer (yes, I'm talking about you, team leads and architects) is always going to say that. Even people I trust.

Is that fair? Probably not. Is it prejudicial? Yes. Has anyone ever proven me wrong? Sometimes, but rarely.

Does it mean that the code is good? No, it doesn't.

But here's the thing. I've worked with tons of developers, some great, some good, some mediocre, but they're all pretty clever at some level. The cleverness manifests itself in all sorts of ways. Even many of the mediocre ones work hard and deliver working solutions to clients and bosses.

And, of course, clients and bosses appreciate things that work.

So if you think most code is junk, you're probably seeing artifacts of something besides talent. What do you think it may be an artifact of? Here's a great question: "If we work with this client with this sloppy code base, what do we need to look out for?"

Code can be a great artifact for thinking about that question.

Chances are, in the middle of the sloppy mess are some bits of brilliance or cleverness. Finding them will give you some indication of both the motivations of the original developer and of the business realities this code faces in the real world.

Telling me one good or interesting thing about the code would prove that you had read the code. Telling me two good or interesting things about the code would tell me that you probably have a good grasp on it.

Providing me, as a development manager, solid context for understanding that you have read and understood the code allows you to judge the code, and allows me as a manager more leeway to listen to you and understand your criticisms.

Here is my list of phrases and statements that cause me to judge people when I hear them without any further explanation:

  • "The code is fragile."
  • "This is spaghetti code."
  • "This was not designed properly."
  • "The code sucks."
  • "The code is over-engineered."
  • "The code is under-engineered."
  • "I make a change and it has unintended side effects."

The last one, especially, is a huge one for me. Unintended side effects? In the best case scenario, you're really just saying "I didn't read the code, and I don't understand it." In the worst case, you're saying, "I don't know how to do my job very well."

When unjustified, all of those statements are smokescreens, avoidance, and hand-waving. Even if you have a point, you aren't proving it.

How do you prove that you read the code? Well, pointing out a thing or two that is good can be helpful, but there are other ways, too. Here are two that can be helpful if you're specific about it — Technical Debt and Code Smell.

If they're used generically, they have the same problem (they're handing waving or avoidance or griping for the sake of griping); if they're used specifically they can be meaningful.

Before you start to talk about the "bad code," you can use these types of statements to be much more specific.

Here are some things to read:

agile, agile leadership, bad code, code, technical leader

Published at DZone with permission of Jonathan Fries , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}