when relevant content is
added and updated.
Hard-coded test directories on the server.
Hard-coded test databases in the code.
Exception handling that couldn’t actually handle the exception at the level it was called for.
I reported the errors to my management, and they replied that I did not understand the code review process. It was not my job to give an up-or-down vote, but instead to review the code. The code review had occurred, therefore I needed to check the box for code review and move the code into production. If it were ugly or not was merely a matter of my opinion.
If only I had known what to say — that ugly code is bad code. Code so complex I cannot understand what is happening.
Code that bad will have errors that we cannot even find, because we cannot figure out what the code is doing.
How does code become ugly?
One change at a time.
Let’s talk about that.
How Code Becomes Ugly Code
Imagine a software application that solved a real need. Fueled by pizza and mountain dew, programmers worked late hours to deliver working software. That working software generated real business value. It got people employed and kept them employed. Over the years, other programmers added to that code, finding exceptions, comparability problems, work-arounds, bug fixes, and, yes even a few new features. Eventually, you are hired. The programmers before you left you a gift: Working software that provides your employment. You might even gift such a gift a name. You might call it …
If you’re reading this, odds are good that you don’t need to imagine it.
Somewhere, a programmer gets a new requirement. It is a new checkbox at the user-interface level, to lock the page to only authorized editors. The programmer adds a boolean variable to the method, bOnlyAuthorizedUsers, adds an if statement around the edit function combined with a lookup, cutting and pasting some code to both sides of the if.
The programmer also adds a comment in the code, as it is getting ugly:
//beware! Here be dragons …
Enter the Junior Programmer
Six months later there is a need to change the code. The senior programmer removes the comment and assigns our young hero, who will now have touched the code and will therefore “own” it. The junior programmer makes and tests the change at the top of the if statement, but fails to recognize the change also needs to happen in the bottom of the if statement, the special case where edit is locked.
There are a lot of checkboxes.
It is unlikely that even a tester connects the dots, having the intuition to connect edit permissions with the new change that is unrelated in substance. That assumes the team even has someone with a deep expertise in testing. Nor will automation check it, as the number of combinations are simply too high.
That’s not ugly code, it is buggy code.
It is one example, a trivial example, of how ugly code leads to defects.
The problem is the transformation from ugly (and buggy) code to clean code is harder than it looks. That transformation takes skill, which can be identified, practiced, and improved on.
So how do you fix ugly code?
One change at a time.
Let’s keep talking.