You are here

Man witnessing bad code

How terrible code gets written by perfectly sane people

Christian Maioli M, Senior Web Developer, Freelance

When I found out that I would be working on porting an old Python codebase to Node, I was slightly excited. These kinds of projects always give you more creative freedom than an ordinary code maintenance gig, and something about the challenge of rewriting other people's code makes it as fun as hell.

But the excitement quickly faded once I actually got a look at what we were going to work with. Legacy code can be nasty, but I've been programming for 15 years and only a couple of times had I seen something like this. The authors had created their own framework, and it was a perfect storm of anti-patterns: no separation of concerns, mixed spaces/tabs for indentation, multiple names for the same concept, variables being overwritten by the exact same data coming from a different yet nearly identical method, magic strings, and so on. This mess could only have been the product of a room full of babbling monkeys copying code randomly from Google.


And yet, it was not the code's dismal quality that piqued my interest and led me to write this article. What I discovered after some months working there, was that the authors were actually an experienced group of senior developers with good technical skills. So, what could lead a team of competent developers to produce and actually deliver something like this?

What I've come up with is a list. Here are some bad habits that even experienced teams can get into which will severely affect your end product—more than any static code checker or development methodology could rescue it from.


Giving excessive importance to estimates


Typically it's more difficult to over-estimate because the effects are immediately evidenced on project cost, so your developers might choose to over-promise instead, and then skip important work such as thinking about architectural problems, or how to automate tasks, in order to meet an unrealistic deadline. These tasks are often seen as added value, so they get cut without notice. Product quality will decline as you accumulate technical debt, and you'll find out about it later than you'd really want to, because reorganizing code later in a project costs exponentially more.


Sometimes estimates can even be deceiving. For example, Agile has a term called "velocity." The idea is to calculate how fast your team can deliver, and make the necessary changes to go faster. The problem is that it's not possible to come up with an accurate velocity in the short to mid-term. The law of averages says that you can't look at past performance to judge how fast you can go right now, because past performance is not a good indicator of future results.



Giving no importance to project knowledge


As this was a full rewrite of old code, it was particularly interesting in this regard, because it serves to show whether your team's management understands project knowledge and how it impacts development. If you're in a large project and there are modules for which you have no expert, no-one to ask about, that's a big red flag.  The value in rewriting code rests entirely on taking advantage of what you learned the first time around, so value that knowledge dearly.

If you put a different team to do the rewriting, as was done in my case, you are ignoring all your learnings and relying solely on your new team's skills, which likely won't make up for the lack of information. A mediocre developer is going to do a better job at rewriting something he wrote himself, and he'll do it faster, than if you give the job to someone else entirely.

Even hiring is impacted by project knowledge. The more information the project carriers, the longer it will take to bring people up to speed, so not only is domain knowledge more valuable then, it's also important to focus on hiring good people. If you don’t hire well, you’ll get tied up to a bad team that will go nowhere for months.



When a measure becomes a target, it ceases to be a good measure. —Goodhart’s law


One metric that few seem to focus on is regression rate of issues. There are bugs such as null pointer exceptions that might show up much later, and if you're not tracking regressions, it will seem as if bugs keep springing up out of nowhere. In this situation, you'll never find the source of your problems, because you're looking in the wrong place.



Assuming that good process fixes bad people


It never ends, and this entire problem can be disregarded by just fixing the hiring. Talent makes up for any other inefficiency in your team. That's the entire point of favoring smart work over hard work.



Ignoring proven practices such as code reviews and unit testing


Imagine my dismay when I had to collaborate with a colleague on that legacy project and his screen displayed Notepad in its full glory. Using "search" to find methods might have been rad back in the nineties, but these days, refraining from using tools such as modern IDEs, version control and code inspection will set you back tremendously. They are now  absolutely required for projects of any size.


Hiring developers with no people skills

It's not that developers can't talk to other people. I was once a shy developer myself and eventually managed to stand in front of an audience and give a talk just fine.

The problem comes when someone isn't willing to even try, or becomes annoyed by requests to improve communication. If there's one thing that can speed up development time more than anything else that I've mentioned, it's improving communication. Particularly when you reduce distances and work on informational proximity, you enable a more fervent and articulate connection in the workplace. It doesn't matter that the other guy might be ten thousand miles away. One Skype call can turn a long coding marathon into a five-minute fix.

Agile and done? Um, no

When you enable and encourage working smart by using the best tools, proven techniques, and great communication, software development will definitely flow more naturally. What you can't assume is that just because you've signed up to apply Agile or some other tool, that nothing else matters and things will sort themselves out. There's a synergistic effect in action here which can make a team exponentially more productive if they're set up right, and terribly slow and sloppy when no attention is paid to the details.


Image source: Flickr
