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
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 (tm) 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!
Continue reading about Are you a boy scout coder?
Semantically similar articles hand-picked by GPT-4
- Small change in big scary codebase?
- Better is good
- You can't stop the business, or why rewrites fail
- Clean Code and speed coding
- What to do when bugs are whack-a-mole
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️