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 problem where leadership wants to build a culture of software excellence, and the developers want to build better software, yet it never happens.   Worse yet, on some teams the leadership thinks they’re building great software, but the people on the ground know that it’s mediocre at best.  How does this come to be, and what can you do about it?

There’s more than enough talent floating around; almost every team has the capacity to write awesome (or at least good) code.  Even young developers right out of college have a rough idea about code quality, good design, and best practices. You won’t solve code quality problems by hiring superhero developers. Experts might help you write good code faster, or take you from a 9/10 to a 10.  But if you’re like most companies out there, you’re hovering between a 3 and a 7.

What I hear most developers say is that 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.”

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”, don’t hold your breath.  It’s not their job.  Their job is to meet the needs of the business, and that means asking you to build software. Most managers, executives and business-people wouldn’t know good code from bad even if you put it into powerpoint for them (with charts).  I tried to explain a serious code quality issue recently, and the PM responded, “you mean the developers have little pet peeves.”

Code quality is a professional developer’s responsibility.  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 in while you work. Realize that this is an essential part of your work each and every day, and you’ve taken the first step. 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 duty 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 a hobby- as a professional, you need to do design, make a plan, and perform analysis before sitting down to work. Code quality takes a back seat when you tell your manager that a feature will be done in 10 days, and on day 10 you’ve cobbled something together, but don’t have any time left for tests, haven’t done any refactoring, and haven’t spent time improving re-use or simplifying design.  Similarly, if your manager 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. 

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 measurements, and he can 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.  Is he faster or slower?  Wouldn’t it have been worth his time to tidy his workspace, sweep the floor, and put his tools away between each of his jobs?

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 too 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 perform analysis 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 (or your manager) to cut corners.  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 a thing!  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.  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. 

If you want to influence your team, change how you write (or read) your stories.  A story shouldn’t just be 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, and analyze how you can improve the existing code quality as part of the story.  Bundle your 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 if yours doesn’t, remember that at the end of the day the professional developer is the one planning and estimating, and the professional developer is the one who keeps their promises and stands behind their work. 

If you’d like to chat about code quality, send me a note!