Uncharted Waters

Jun 28 2018   10:34PM GMT

Beyond Ugly Code

Matt Heusser Matt Heusser Profile: Matt Heusser


Ugly Code Imagined as a structureTen years ago, I was asked to code review an application. The code was the ugliest I had ever seen – by far. The code was so bad that I could see bugs by looking at it.

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

Ugly Code CommentsImagine 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 …

A legacy.

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

Clean Code Is Not Ugly CodeSix 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.

5  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • DavidGlynn
    Well written article that should hopefully inspire conversation.  

    Small point...I had to read the following sentence a couple of times before I realized the word "now" should be "not".

    "If it were ugly or now was merely a matter of my opinion."
    10 pointsBadges:
  • Matt Heusser
    Thank you David, I've fixed it.
    4,860 pointsBadges:
  • BigKat
    I worked on some code once that had an if that "grew" over time, getting additional OR branches and new validation fields.  I analyzed it and did a Boolean set reduction on it.  It turned out by the time they had kept adding "new" conditions for it to run, that it ALWAYS ran.

    I knocked out the whole if (and the endif) and the program ran 10% faster.
    9,460 pointsBadges:
  • HemaDass
    And I would like to add something on this. With the advent of many low-code and no-code platforms in the market, the necessity to learn and execute coding is gradually decreasing. This is a positive growth and every business needs to concentrate on the benefits of low-code app development to empower every employees.
    10 pointsBadges:
  • TheRealRaven
    'One change at a time' might or might not be appropriate. I've done it often enough, but I've also regularly simply tossed the whole mess and replaced it. I've also lobbied management groups to approve abandoning current long-term 'one change at a time' efforts and beginning new version efforts.

    Choosing between the two extremes can be a real trick.
    35,650 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: