« Back to home

Keep Your Workbench Clean

Posted on

Let’s face it, a lot of developers are writing code that they wouldn’t brag about.

I’ve worked in more than my share of development shops, and I see the same behaviors over and over. Leadership wants to build a culture of software excellence, and the developers want to build better software... but it just doesn't happen. Worse yet, sometimes leadership thinks they’re building great software, but the people on the ground know that it’s not. How does this happen, and what can you do about it?

There’s more than enough talent floating around; almost every team has the capacity to write good code. Even fresh developers right out of college have a rough idea about code quality, good design, and best practices. But if you’re like most companies out there, your code quality is hovering between about a 3 and a 7 out of 10.

There’s Not Enough Time

I hear developers say they don’t feel empowered to write good code; there’s too much pressure from the deadline, schedule, sprint, business priorities, or from their manager. ”I know I could fix this code up, but there’s just not enough time.”

I also hear developers say "lets call this technical debt" or "I'll make a new ticket to come back and clean this up later".

If you’re a software developer and you’re waiting for your manager to say “take the next week and improve the code quality”, you’ll be waiting a long time. If you’re hoping your CEO is going to say “this quarter we’re investing in refactoring code”, you're in for a disappointment. That's not their job! Their job is to think about the next thing the business needs. YOUR job is to write quality software.

Take Responsibility

Code quality is a professional developer’s responsibility. It's an expectation. It's the default setting. It can’t be inspected into the code through QA or code reviews, and it can’t be sprinkled onto the code like sugar at the end of the month or year. Companies with clean code are out there, and they’re not putting aside 20% of their time for refactoring. Code quality is built while you work.

If you're not a developer, you won't necessarily even understand what code quality means to do your job. As a young developer, I tried to explain a serious code quality issue once, and a PM responded, “you mean the developers have a few pet peeves?” Instead of blaming the PM, I realized that I was asking someone else to clean up my mess.

You don’t need to wait for permission or a special project; chances are the people around you are already expecting your highest quality work. When’s the last time you were explicitly told to write a new feature, but make it difficult to maintain, read, or improve?

What about all the time, deadline, business and management pressure? It’s your job to deliver good code regardless, and if you’re involved in estimating the time it takes to do your day to day work, then you can only blame yourself. Developers are coders at heart, but this isn’t your hobby- as a professional, you need to do design, make a plan, and perform analysis before sitting down to work.

Of course code quality will take a back seat when you tell your manager that a feature can be done in 10 days, and on day 10 you don’t have any time left for tests, haven’t done any refactoring, and haven’t spent time improving re-use or simplifying design. This problem is now your fault. If someone asks if you can finish the feature in 10 days, and you agree (but you really can’t), you’re guilty of setting yourself and the team up for failure.

Craftsmanship And Coding

Think about a journeyman carpenter. The first chair he makes quite quickly - all of his tools are organized in this tool-box, his work-bench is clean of sawdust and shavings, someone has supplied him with neatly written drawings and measurements - he can just focus on making the chair. After his fourth or fifth, the work bench is covered in sawdust and his tools are buried in the shavings: he has to dig to find them. Some of the tools ended up on the floor and his measurements are missing. One of the tools is broken. Is he faster or slower?

Wouldn’t it have been worth his time to tidy his workspace, sweep the floor, repair or put his tools away between each of his jobs? Should someone have to tell him to do this each and every day?

This is something a master carpenter just does; a journeyman eventually learns the value of keeping his workbench clean, and doesn’t have to be told. Time isn’t put aside to keep the bench clean; you just clean it when it gets messy. And you can bet that when the master carpenter promises six chairs in a day, he factors that in.

A professional, responsible developer will think hard before contributing an estimate. When you’re asked how long it will take, tell yourself that you’re not creating an estimate, but building a plan. Ask yourself questions such as “how much time will I need for testing?” or “can I adapt this code into a re-usable component?”. Do you need to address any existing technical debt before you start? Are there any known bugs in that area of the code? Keep your workbench clean! If you need more information, take a minute to have a conversation with whomever you need.

If your estimate gets too big, break the task down - into vertical slices, not horizontal layers. Horizontal layers like “write code”, “do refactoring”, “create unit tests” just encourage you to cut corners or blow through deadlines. Think like the carpenter. Don’t cut all the wood, then carve all the wood, then glue all the wood, then sand all the wood and then assemble all the chairs. A pile of carved and sanded wood isn’t worth anything!

Build one chair at a time: break a story like “add user management” into smaller slices like “add a user to the system”, “remove a user from the system”, “edit an existing user” and so on. Each slice should be estimated with professionalism and forethought, so that the final product has quality built in.

Track how accurate your estimates are from task to task, and if you’re under-estimating, start applying an adjustment to your thinking. Take pride in your ability to deliver on your promises and meet your commitments - and commit to more than just a working feature. Don’t worry if someone else can do it faster! Over time, you’ll build up a reputation for keeping your word, setting a good example, and doing good work, which is much more important than being fast, obedient or agreeable. You’ll be surprised at the opportunities that come your way. Nobody hires a fast but sloppy carpenter!

Spreading The Word

If you want to influence your team, change how you write (or read) your stories. A story shouldn’t just be about adding a working feature. Each story should be one-part innovation, one-part quality, and one-part feature. For example, if you’re building or estimating a story that adds to your login screen, brainstorm how you can make the feature innovative; analyze how you can improve the existing code quality as part of the story. Bundle any outstanding bugs and technical debt with each story before you start. Even existing, boring, legacy code can slowly be cleaned up and made exciting if every story going forward is treated as an opportunity rather than merely an addition.

It’d be great if every CEO, project manager, product manager or business analyst could help you think this way about your work. But it's not their job. Remember that at the end of the day the professional developer, the "master carpenter" is the one doing the planning and estimating. A master is someone who keeps their promises and stands behind their work.