Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

March 27th, 2011 at 12:19 pm

The obsession with beautiful code, the refactor syndrome.

with 18 comments

There is lately an emerging obsession with beatiful code, up to the point where some programmers are overprioritizing it over more important goals such as:

  • Correctness
  • Robustness
  • Traceability
  • Supportability

When this is taken to the extreme, and all that the programmer cares about is the beauty of the code, can cause him/her to fall under the refactor syndrome.

The refactor syndrome has the following symptoms:

And usually causes:

  • An explosion of services, managers, helpers or other utility like classes.
  • Integration bugs.
  • Lack of robustness.
  • Loss of productivity.

The main issue with the refactoring syndrome is that is based in the beauty of the code, and this, upfront, has three big issues.

  1. Not achievable. All code is crap. This is one of my favorite quotes, and to me is proven by the following facts:
    • Exclusion principle. All programmers tend to think that only their code is the only good code in the universe.
    • Legacy code principle. As a programmer, as you learn new stuff, you even consider your not so new code to be crap.
    • Experience principle.I have never seen, or produced any real code which I thought it was beautiful.
  2. Not so important. Even if beatiful code was achievable, it doesn’t prove that the code is correct, and among other things, correctness is way more important than beauty.
  3. Wrong perspective. Focusing in the code itself, and not in the application makes the programmer forget about other more important areas.

This refactor syndrome seems to be associated with some programmers taking the last agile tendencies as religious dogmas. This happens when programmers confuse the tools and engineering practies like TDD, refactoring, pairing and unit testing… with what needs to be achieved. This would be comparable to a builder who believes that having shiny, new and clean tools, is more important than the house he is building.

It is important to understand that none of the tools or engineering process that the different agile family of processes propose are bad per se, they are usually great. Is just that when we decide to overuse them that we might be getting close to the refactoring syndrome.

In summary, is important to remember that:

  1. It is not important how beatiful is your code if it doesn’t work.
  2. Refactor only when is necessary, not only when you don’t like the code or you think you are going to make it more beatiful. Not liking something IS NOT a reason enough to change it.
  3. Unit tests have very limited value when it comes to integration and end to end issues. Do real end to end test!!
  4. Know all the different tools and engineering practices, but don’t take them as dogmas, learn what is good and bad from each and apply them when necessary.
  5. Good programmers are gonna keep doing good software, bad programmers are gonna keep doing bad software, no matter what processes they follow.


Apparently this article is causing some controversy, so I want to make clear some points which I see after the comments I didn’t made clear enough.

  1. I do think that Unit Test is great, I just want to point out that it CAN’T and it SHOULDN’T pretend to substitute integration and end to end test from the developer.
  2. When I say that a bad programmer is going to write bad software, no matter what process he follows, I didn’t mean to say as in, a bad programmer also will always be a bad programmer, we all have been very bad programmers when we started, and we only hope that we improve as we aquire more experience.

18 Responses to 'The obsession with beautiful code, the refactor syndrome.'

Subscribe to comments with RSS or TrackBack to 'The obsession with beautiful code, the refactor syndrome.'.

  1. I like your article, but I have to slightly disagree with 5th rule. IMHO when is programmer bad, he can improve his skills because of some process like pair programming. Which means that he could be better programmer => better code.


    27 Mar 11 at 1:29 pm

  2. I like your article, but it’s going to be controversial as hell…

    I’m going to subscribe to the comments and relax while I read (and perhaps even inflame) a good flame war. I kind of miss that…


    28 Mar 11 at 2:55 am

  3. Great article. Beautiful code in many cases over complicate functional code. Refactoring is needed to enhance the performance of your code, and not it’s appearance.

    Users of our software does not care about anything but the usability of the software.


    28 Mar 11 at 5:28 am

  4. Omg so stupid


    28 Mar 11 at 6:47 am

  5. I read every posting ASA they publish here. In this one, I agree with most except the #3 in the summary.

    I love unit tests that’s because I care about what I write. Limited value, I don’t get what exactly you mean. It have extraordinary value. If I have a chance to re-write that point, I would say:

    “Unit tests are great, but make sure to take care of integration and real end to end tests as well.”


    28 Mar 11 at 7:21 am

  6. Wow, couldn’t disagree more. I simpatize with the subject itself but the train of thought is such a mix of arguments. IMHO, you shouldn’t throw half of the problems of software development and personal opinions into the excessive search of code beauty.

    Marcelo Silveira

    28 Mar 11 at 8:38 am

  7. Well, this started off good, but you lost yourself there.

    Refactoring should be done when you got yourself backed up by tests, so if you are refactoring and it doesn’t work, its because your tests suite sucks in the first place.

    Beautiful, tested code, works.

    Tests are meant to describe objectives in your project, so how can we lose perspective of whats important?

    I think what is wrong is refactoring without purpose, refactoring is to be used to;

    write code using the same language your clients use to talk about it, domain language, you should always follow it, so its a valid point for variable/method name change.

    improve re-usability;
    improve testability;

    I don’t think ppl are overusing unit-testing, the last tendencies are to over use integration tests =)

    Rodrigo Dellacqua

    28 Mar 11 at 10:18 am

  8. @zaparka I actually agree with you, there are many ways where a bad programmer can become a better programmer, and pairing is a very good way to learn from more more senior people, I was just trying to say that if someone is bad NOW, even thought he maybe a genious in a couple of years, the code he can write NOW is going to be bad, no matter what process he follows.

    @gux. Yeah… I kind of thought the same when I was about to publish this, that this article was going to be very controversial, but I actually think is more productive this way than when we all actually agree.

    @jvanrhyn. At least it seems that there is someone else that agrees with me on this. Thanks =D

    @Bala Totally agree with your comment “Unit tests are great, but make sure to take care of integration and real end to end tests as well.” I do think they are great, I was just trying to say that they are not enough

    @Marcelo Silveira. I wasn’t looking into blaming all the software development issues because of the excessive search of beautiness, sorry if my article wasn’t clear in that sense, I was just trying to explain how from my point of view there is a refactor syndrome which is very specific, but is not the cause of all the software development evilness

    @Rodrigo Thanks for your comment. I completely agree with what you say… BUT, only on theory… let me explain, in my experience, things as: beautiful code, using the same language as the business domain… Are not so important, at the very end, IMHO everything boils down into having something that is correct, usable and robust. Acutally, I don’t think is so bad to have the programmers looking into the code to find out what the hell it is doing… In any case, and I am being completely honest here, this is all based in my personal experience, but maybe you guys have had different experiences?

    @All Thanks for all the feedback, really, I love to be challenged, I think from these conversations is from where you can actually learn more… Please guys feel free to keep commenting. Thanks!

    Alberto Gutierrez

    28 Mar 11 at 3:09 pm

  9. I wish I had written this. I have experienced this obsession first-hand and seen the paralysis it causes. It can be worse than creeping featurism, the other bane of producing working software. Thanks for a great summation of a real problem.

    Greg Jorgensen

    28 Mar 11 at 5:04 pm

  10. Hey Alberto,

    great article! I think I know exactly what you mean here. Instead of addressing real business needs, some people tend to loose themselves in overengineering and the search for “the perfect code”. But I think that’s also a matter of experience. I mean, haven’t we all been through this after we first read the “Design Patterns”-book and thought we had to apply these patterns as much as possible to “improve” our code? :)


    5 Apr 11 at 11:53 pm

  11. @Greg. Thanks for your support!

    @Achim. Very nice analogy about the first time we all read “Design patterns”, completely agree with you!

    Alberto Gutierrez

    12 Apr 11 at 11:03 am

  12. Beautiful code is meant to support Correctness, Robustness, Traceability, Supportability.

    I don’t understand how you can consider beautiful code that does not meet those criterias.

    I agree that developers should be educated not to over-engineer. The line is thin.

    But beautiful code means clean code, simple designs, correct and robust that “invite” to change.
    Any idiot can make a program nowadays. But only the bests can make larga applications that can be understood, changed and expanded by others (and himself obviously)


    18 May 11 at 2:24 am

  13. As an “old timer” (Programming 20+ years, having started in embedded systems) there is a lot to be said about this. Sometimes the “most” elegant solutions to a simple problem are more issues waiting to happen (using self modifying code, templates, etc.)

    If more emphasis were placed (in school) on solving the problem FIRST. Then doing code clean-up (if its code that’ll be around a long time).

    Not prettifying code THEN solving the issues. It’ll never get done that way.

    Sir Geek

    26 May 11 at 10:08 am

  14. Just what I needed to read, thanks :)


    1 Jun 11 at 9:44 pm

  15. […] 我要告诉你一个坏消息,兄弟,所有的程序都写的很烂,包括你的。无论你在上面花多少功夫,其他大多数程序员总是会认为你写的代码很烂、他们能写出比你好10倍的程序。我在前几篇文章里已经讨论过了这个问题,你可以读读这篇文章和这篇文章,从中你可以理解我所说的所有的程序都写的很烂究竟是什么意思。 […]

  16. […] I have bad news for you buddy, all code is crap. No matter how much effort you put on it, there is always a majority of programmers who are going to think that your code sucks and that they could have done it 10 times better. I have already covered this topic in previous posts, you can find more information of what exactly I mean when I say that all the code is crap here and here. […]

  17. I have very mixed feelings about this post. I believe that too much focus on one aspect of programming is not good for the end result. Balance is always necessary.

    But, I do have a set of priorities for what I do with my code as I write. For example I am a TDD addict. I am uncomfortable not starting with a test. And there are cases where I have to soldier though that discomfort, doing what needs to be done.

    Back to beautiful code, as I write my code I always strive to keep it readable. Readability is my number one effort on code, test or production. I follow the fast food mantra of “clean as I go.” If I can read the code I can make it work (compile), work correctly, and if necessary work better. When I cannot read the code I cannot do anything with it, but clean it up.

    Is readable code beautiful code? That is where my mixed feels come from. I do not want a swing where programs loose any concern about presentation of code. It is important. Especially for those of use will poor or limited vision. Given code presentation impacts understandability, readability.

    With all that said let me share my opinion of beautiful code: readable, tested (and passing), that has a reasonable design. The tested aspect assumes it is doing what it is intended to do.

    Thanks for the thought provoking post. Keep it up we need to keep challenging our views so our views evolve.


    3 Feb 12 at 4:49 pm

  18. “It is not important how beatiful is your code if it doesn’t work.” Yes, you’re right. Of course, correctness of code is more valuable than beauty. But! Too many programmers do just the opposite: they write code for computers, not for people. As result we have tons of code that very, VERY difficult to maintain. Such maintenance steals our time and our money. Moreover, it steals our nerves and even our motivation: nobody likes to delve in crap.

Leave a Reply