Hey, it’s Alvin!
I often interview potential software developer hires as part of my job.
One time, I asked, “How would you improve a team’s software development process?”
The answer I got surprised me. The candidate answered he would write some scripts to automate as much of the process as possible. He added that since the script would be used internally (by software developers), we wouldn’t have to put more time into making sure it’s clean and organized.
My fellow interviewers and I shared the same sentiment:
It’s still code.
This isn’t the first time I’ve seen developers toss around the idea that it doesn’t matter how messy your code is. What matters most is user experience, they say. And since your users (and clients) can’t see your code, why does it matter if it’s messy?
To me, this is a huge oversight.
It’s naïve to assume that just because people can’t see it, it has no impact on them.
Let me start with an analogy.
The Electrical Panel
Here’s a home electrical panel, also known as a “distribution board.”
Its job is to distribute electrical power throughout the home. So, every electrical circuit connects to a fuse or circuit breaker in a box like this.
It’s generally rare that anyone who lives in a home would need to use the electrical panel. Unless you perform regular home repairs and improvements that require shutting off power to parts of your house, you probably won’t interact with it much, if at all. Electricians and other external maintenance workers are more likely to use the electrical panel than you, as a homeowner.
Electricians know this. And rather than taking the time to organize the wires and circuitry, they might just connect the wires to… whatever. As long as they can turn that ceiling light on, they call it a day.
Then, maybe there’s another electrical problem. An electrician is called in again. Maybe it’s the same one; maybe not. They look at the panel and go, “I don’t want to deal with this mess.” So, they, too, refuse to organize anything, do the bare minimum to fix the one problem the homeowner found, and then they leave.
This happens again and again until you end up with this monstrosity:
Even if we assume the residents can’t see this or that they don’t care, does it mean this mess has no impact on them?
Because there are wires all over the place, it would be much harder for an electrician to identify and understand electrical problems just by looking at the panel. Figuring out how to fix existing problems by rewiring without causing new ones is an even greater challenge. And the more time they need to fix the problem, the higher the cost of repair. That’s an impact to the homeowner.
And because it’s not obvious which wires are connected to which circuit breakers, it’s easy to connect more than one circuit to one breaker. Known as double-tapping, this increases the risk of an electrical fire.
It’s also hard to tell if there are any exposed wires. That’s an electrical risk if the homeowner does need to use the panel.
Besides, doesn’t the panel below just look way more professional (even if clients can’t see it)?
The Code
One of the biggest differences between software development and home electrical repairs is that software’s often made in teams. Keeping code neat and organized is a way to serve your teammates. Because when your code is “clean,” it’s easier for others to follow and understand. It lets everyone on the team develop features and fix bugs faster. And what customer or user doesn’t want faster delivery?
I once had to clean up code left by a former developer. I spent days just trying to understand how it worked. And every day I had to remind myself how it worked so I could reorganize and simplify it because it was that confusing. Along the way, I found data validation code repeated 4 times in different parts of the program when it didn’t need to be repeated at all. It was repeated because every developer who worked on it couldn’t tell if the data was properly validated. Think about it:
All this time spent understanding, reworking, and repeating code could have been spent delivering a valuable new feature instead.
Why shouldn’t this factor into user experience?
Cleaner code is less likely to harbour bugs because clean code follows patterns of organization. Code that doesn’t follow established standards and conventions are potential bugs. They’re easier to spot, like a dangling wire in an organized electrical panel.
Fewer bugs?
Why shouldn’t this factor into user experience?
Even when there are bugs, they’re easier and faster to fix when the code is more organized. Because you can see what code is connected to what other code more easily. There’s nothing much to untangle, if anything. It’s much easier to see how you can connect this dangling wire to get everything working the way everything should be.
Faster fixes?
Why shouldn’t this factor into user experience?
I realize there are those against clean code principles because of the added burden it has on beginners. And often there are esoteric rules that lead to more cost than benefit. I couldn’t care less what you want to do with your code. Nor am I saying my code is all perfectly clean and tidy.
All I’m saying is there are consequences to messy code that impact users even though the code isn’t visible to them, and even though the consequences are usually indirect. But just because the impact can’t be quantified with accuracy, it doesn’t mean there’s no impact.
It’s naïve to assume that just because sloppy work isn’t visible to someone that it has no impact on them.
I hope you enjoyed this dive Below the Surface of fancy façades hiding costly clutter. Reply to belowthesurfacetop@gmail.com if you have questions or comments. I’d love to hear from you.
Thank you for reading. Keep it clean. And I’ll see you in the next one.
There's so much value in being mindful of technical debt. I loved the analogy of the electrical panel, Alvin. Awesome edition!