I'm a writer, programmer, web developer, and entrepreneur. Preona is my current startup that began its life as the team developing Twitulater. Our goal is to create a set of applications for the emerging Synaptic Web, which would rank real-time information streams in near real time, all along reading its user behaviour and understanding how to intelligently react to it. Swizec is a DZone MVB and is not an employee of DZone and has posted 65 posts at DZone. You can read more from them at their website. View Full User Profile

Are you a boy scout coder?

01.22.2012
| 6314 views |
  • submit to reddit

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!

Source:   http://swizec.com/blog/are-you-a-boy-scout-coder/swizec/3471

Published at DZone with permission of Swizec Teller, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Tommy Li replied on Mon, 2012/01/23 - 1:12am

On the assumption that you always work on mission critical systems, then I agree with your article whole-heartedly. However, before deciding to do major surgery on code, I feel it's much more important to ask what's "good enough" quality. I personally am always tempted to leave the "campground" a cleaner place but ultimately, that decision is more of a business decision (value, opportunity cost, etc.) than technical. Even if you've consulted with business on this, are you sure he or she really understood the value and risks associated with the change or were you just very good at persuading because you wanted cleaner code? Most of the time, I myself "just do it" and refactor till it's squeaky clean but sometimes, I either fall into the trap of over doing it, realize too late that I just opened a can of worms or the business simply don't care if that part of the campground is a mess.

Michal Steiner replied on Mon, 2012/01/30 - 9:43am

Good developer (freelancer or full time employee doesn't matter) should develop good code. One of the reasons why I love this rule is that, it doesn't say you have to make someone's code perfect, it will be enough if you make it just little better.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.