Balancing Speed vs. Perfection in Software Development

Here’s the question of the day: Is it okay to sacrifice code quality to get the project done?

I’m no programmer, but it occurred to me that this question translates well across writing in any language. I write articles every week as a freelance side hustle in addition to my work as a recruiter at AWH. When writing business content, I still struggle with sentence structure. How can I create the most elegant sentence in the client’s voice, but still hit their deadline?

I imagine this is the same challenge developers feel when they’re trying to write code.

How can programmers write their best code when they have a deployment deadline looming? Is it really okay to sacrifice code quality to “get ‘er done?” What do developers have say about this and is it different from the perspective of project managers?

Let’s look at the opinions of some experienced developers and project managers on the AWH team to see what they have to say about the speed vs. perfection debate.

Striving for Programming Perfection in Software Development

There are different schools of thought on what makes the best line of code. Junior developers often struggle with how long to spend on solving a problem. Keith, an AWH Project Manager, states:

“We’ve tried to instruct developers to raise their hand for help if they’re struggling. We have options to either hand it off to another developer or work with the rest of the team to come up with a solution. We shouldn’t let the developer drown. If it’s just crappy code that needs cleaning, but the functionality works, it can go on the backlog where we tackle it later.”

Keith brings up a good point: If it’s a passion project you’re doing for fun, you can experiment, noodle your head off, or maybe be as anal as you like when building form or function. If it’s part of a software build, the project itself may dictate when you give up and move on.

Another AWH Project Manager, Andy, agrees, and suggests:

“Every feature can have a good, better, best approach. Sometimes ‘good’ code works, but causes other issues down the road. As a team, we may start off with good code, but identify it as a technical debt to be addressed later. That keeps it from blocking other code that may rely on that feature—but it is still workable code that just needs to get better later on.”

We can all agree that good code should:

• Be readable by others. Technical debt is a crappy burden to carry around. If other developers can’t make sense of what you wrote later on, they will curse you with bad karma forever.
• Be understandable so strangers can figure out the functionality. This usually means adding documentation and test cases to make it easier for the person that comes after you.
• Have longevity so that, in the true scientific method, other developers can build iterations on the base code functionality. If your base is weak, dude, you know what will happen later.

While these are great code standards, the reality of a software build is that you may not meet all your functionality, efficiency, and quality goals the first time around. Crafting the perfect digital product means finding balance between all of these things. But what happens with your desire for perfectionism butts’ heads with the client or stakeholder’s urgency around rolling out a product?

The Downsizes of Perfectionism in Software Engineering

If you’re a total coding perfectionist, you’ll never get anything done. I’m serious. As a writer, if I spend too much time reworking and second-guessing myself, I’m going to miss the deadline. It’s like this for developers, too.

An article in Jaxenter calls it, “The risk of ruining the project by overworking it.” It’s the idea that at some point, the developer, artist, writer, or whoever the creative craftsperson is, must know when to move on.

For every line of code you write, there will be internal dialogue tied to self-doubt. That voice in your head may get quieter, louder, or speed up with coding experience. But this is one albatross around your neck that can be both smelly and a weight you don’t need.

(**I’m second guessing that metaphor/cliché right now. Dang it.**)

Andy, who goes by Andyfosho in the AWH DevOps world, had this to say about getting mired in perfectionism:

“It’s like an internal dialogue that goes, ‘I’m stupid and will never figure this out.’ You can almost mentally kill yourself to figure things out and learn. I am not awesome at knowing when to walk away. You can throw the kitchen sink at problems sometimes and things can get real dark. But then you can turn to posting and searching forums for a friend in whatever technology that’s giving you an awful time. I’ve even learned to sleep on it if I feel like I’ve given it my best effort for that day.”

What’s cool about creating new things, whether it’s a blog or a line of code, is that the effort we make to improve is almost always worth it. As a writer, there are practical considerations that drive me to turn in an article without second-guessing myself into a heart attack. Deadlines drive a lot of my work, but also knowing that I’ve done my best to meet the client requirements, which means I’ll be less likely to get the article back in a rewrite that costs me time and money.

It’s the same for programmers. Mel, a Senior Developer at AWH shares some great insights on perfection vs. speed:

“You can move on as soon as it works, but you hope to have the luxury of time to clean up after yourself so that the next person isn’t confused by what you’ve done. My goal is to usually have whatever I make seem so obvious that anyone maintaining it can understand the logic. That usually means that it will take longer than it should as you work from complexity toward simplicity. If you stop just as soon as it ‘works,’ the whole code base could devolve over time into a big mess. So, once it works, make it presentable and move on to the next problem.”

The reality of software engineering is that you’ll need to strive for perfection but recognize, like any good piece of art, there’s a time to let it fly on its own. The project itself may force you to move on, or you simply may get stuck and cry “Uncle.” But the reality is, when writing in any language, there are all kinds of ways to get the job done. Striving for elegance in your craft is just as important as knowing when to let it go.