The Boy Scouts have a rule: “Always leave the campground cleaner than you found it.” If you find a mess on the ground, you clean it up regardless of who might have made the mess. /../ the original form by Robert Stephenson Smyth Baden-Powell, was “Try and leave this world a little better than you found it.”

What if we followed a similar rule in our code: “Always check a module in cleaner than when you checked it out.” No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?

by Uncle Bob at O’Reilly commons

Lieut. Gen. Robert Stephenson Smyth Baden-Powe...

Image via Wikipedia

When I first saw this rule in Clean Code I loved it! It’s just such an awesome rule. You come into a file, you clean it up a little bit. Remove a stupid comment, indent something better … anything.

It makes the world a better place and everyone a happy camper right?

Well, this might be great in theory and work well when you are employed by a company where you will spend the next few years of your life. The software you’re working on will live and grow with you, with your team. You are the guy shouting “Fuck this! Who the fuck made this code! This is bloody impossible to maintain!” a year from now.

For a freelancer the situation is a bit different.

Here you are, plomped into the middle of an ongoing project. Decisions have been made, rabbit holes have been followed. The deadline is in a month and as a crack team of one specialist on a tight deadline, you’re making nice gold per hour.

Right there in front of you. A mess. Code so ugly, so horrible, it would make a grown man cry. You’re just supposed to add a feature. Figure out the mess, add two or three lines of code, cross your fingers and hope for the best.

Or should you rewrite the whole function?

Rewriting would be the Right Thing ™ to do. The code will be more maintainable, easier to test, it will save your client a bunch of money down the line. You won’t be maintaining this so you have a responsible towards everyone coming after you to fix something.

But, right now, right this very instance, you are strong-arming the poor client to pay more. Sure, you’re making the code better, but they care about that one feature. Should you really spend three hours rewriting the code instead of one hour adding something and hoping for the best?

On the other hand: When the messy code breaks, and it will break, it will be your fault. You’re the last guy who touched it. Not rewriting will come back to haunt you. The guy who maintains your code will curse you in their sleep and dream of delicious murder. And it’s not even your code!

So what do you do?

Personally I always try to rewrite crappy code. Add testing suites. Anything I can do to make the codebase better. But I always carefully explain the situation to my client. Why am I doing this, how is it benefiting the client. It’s important to make them understand I’m not just inventing work to rake in more gold.

Clients are surprisingly permissive most of the time and I can sleep better at night. win-win!

Enhanced by Zemanta
  • Marichyasana

    I once had a part time job where I was the only programmer for a small
    division of a nationwide company.  When a new feature was needed he and
    I would sit down and write the requirements, one sentence each, on one
    side of a sheet of paper. One day he says to me that he doesn’t want
    even the tiniest deviation from the requirements, no new features, no
    modification of existing features to make anything better. Here is the
    cool part: “Even if costs a dime, I don’t want it.

  • http://twitter.com/_toch ChristophePhilemotte

    I totally agree.

    From my experience, each time you avoid the rewriting/refactoring and promise to make it better later, you don’t until you bump into issues from that crappy part. At the end, it costs you more. From another hand, you can do more than necessary and over-refactoring your code. It costs also. A refactoring needs a purpose: is it for a better quality? or just for the beauty? makes it the code clearer, more readable? does it imply an optimization by design? Without purpose, a refactoring doesn’t mean anything and just waste you time. It is important to find the good threshold.

    The threshold depends on the customer’s requirements and needs, your time, the type of contract (fixed or variable price), the stage of development… But in any case, being transparent with your customer and explain him the reasons of your choice is a winning case.

  • http://profiles.google.com/rob.kinyon Robert Kinyon

    The question has to be balanced by the testing burden of your changes. Sure, rewriting something may be the “Right Thing”™ when viewed from the lens of maintainability, but how do you ensure that your change didn’t break other stuff? When code gets really bad, the entire application needs to be tested if the structure of a deep function changes.

  • http://swizec.com Swizec

    This kind of code is filled with landmines. Every time you poke something, something else breaks and it’s just impossible to do a good job. I would probably suggest to the client to invest a week or two of my time into making the code maintainable at all.

    Sometimes they don’t want that and I do the best I can to ensure anything I add works at all … but you can never be sure. If it’s too bad I’d probably just thank the client for their time and move on :)

  • http://swizec.com Swizec

    There’s certainly times when it isn’t desirable to deviate from requirements – especially when working on critical code. Best thing to do in such a case is to suck it up and do what’s asked, there’s usually a good reason.

  • Anonymous

    So, when you are being a good boy scout and make the build engineer crazy because you have reformatted and rejiggered code that you somehow didn’t like, how do you explain that?  Beauty is in the eye of the beholder.  One person’s elegantly-formatted code is another person’s screen full of jibberish.  I think it’s nonsense to clean code up and/or re-factor it just for the sake of doing so. You introduce a huge and unnecessary testing burden on the QA staff just to satisfy your out-sized hubris.

  • http://swizec.com Swizec

    There are certain things where everyone can agree the code is crappy and should be changed. In these cases improving it a little bit usually pays off because it’s now easier to work with the code and you can make changes faster.

    On the other hand are things, which are just personal preferences – indentation, line-width, stuff like that. It pays to have a good standard for these that everyone follows. In lieu of such a standard it sometimes pays off to change the file you’ll be working on for a while simply because it makes working with it more comfortable.

    Most of all, I feel more productive in an environment where I can feel at home and comfortable enough to think.

  • Anonymous

    Change the file to suit your personal preferences? That’s extremely unprofessional and shows poor software development skills.

    I’m wondering how many github projects would tolerate a contributor who changes code around just to suit his/her personal formatting tastes and preferences.

  • Richard Bucker

    What do you call a reformed boy scout coder?

  • Fake

    Not only that, if you really examine what he said, he makes the assumption that the “crappy” code *will* break, even though it hasn’t broken before the freelancer in question was asked to change it.

    He’s basing the entirety of his reasoning for rewriting the code on the *assumption* that the working code will break for no other reason than it was “crappy”.   In other words, he didn’t like the code, decided to rewrite it, but instead of simply saying “I rewrote it because I didn’t like it”, he chose to couch it in something he felt others could agree with.

  • Fake

    Bingo.  The know their business better than you do, you’re there to do a job, not tell them how they need to run things.

  • http://swizec.com Swizec

    Of course it will eventually break. People will come and go, they will add features of their own in a haphazard manner, it’s only a matter of time before something breaks. And if there are no automated tests, it might already be broken, just nobody has yet stepped on the landmine (and noticed).

    Crappy code is like having a month old pizza under your bed. Sure you can’t see any bugs/rats/whatever now, but you can be certain they’ll be there eventually.

  • http://swizec.com Swizec

    Depends on the extent of changes of course. If you’re going to change one or two lines, there’s no sense in editing the style of the whole file.
    If you’re going to rewrite 90% of the file anyway, might as well change the other 10% to a consistent style.

  • http://www.daftcoder.com/ Karl Paragua

    Refactoring a messy code is a dilemma for me. It will eat a big slice of my time. But then, I always feel this tiny guilt inside me every time I ignore a crappy code. I was thinking something like “I don’t want the other programmers to experience this crap”.

    My rule is I always refactor small chunk of codes written my mad programmers. BUT, when I realized that the whole code base is just a big pile of crap, I just don’t give a fuck about it and just do what I need to do (add a feature).

    I think a better approach is to hunt those programmers that made our life hard (if they are still alive), and give them a small piece of lecture about the shit that they’ve done. So they won’t repeat those bad practices again. :)  

  • Anonymous

    Wow … what an amateur.

  • Anonymous

    What I cannot stand are arrogant developers who think everyone else’s code is shit – except theirs, of course.  Then when they later leave after having “refactored” the code to their liking, the next person comes in and states how that previous developer’s code is shit and needs to be refactored, and so forth and so on.

    My advice is the simple tried-and-true adage: if it ain’t broke, don’t fix it. If you really feel you need to change it, you had better have a damn good technical reason other than “I think it’s shit.”

  • http://swizec.com Swizec

    Let me refer you to: http://en.wikipedia.org/wiki/Code_rot

  • http://www.daftcoder.com/ Karl Paragua

    Sorry about that, if I sounded very  arrogant.

    I agree on what you’ve said: ‘If you really feel you need to change it, you had better have a damn good technical reason other than “I think it’s shit.”‘

    Don’t worry. I’m following your principle. I’m not just throwing “I don’t like this line of code” every time I saw someone else’s code. I only feel the need to refactor when the code is obviously wrong or bad based on the current standard/convention of the language or our team.

    BTW, thank you for slapping me on the face. Seriously. I think I need to be more careful on what I’m saying.

    Cheers! :)

  • Anonymous

    An unreferenced, no cites WikiPedia entry? That hardly strengthens your point of view.

  • http://swizec.com Swizec

    Yes, exactly. I wrote that wikipedia article in 2005 just so I could write this post!

    Obviously.

  • Anonymous

    The article has no reference, not cites – it’s essentially someone’s opinion, which is worthless in this case.

    Look, go play your “refactoring” games with an open source project as a committer, and then let me know how much everyone on the project enjoys your “refactoring.” Chances are you won’t be a committer for very long.

  • vivacioushy

    Sounds as though you sneaked into our office