DEV Community

loading...

Code quality is overrated

ross profile image Ross Creighton Updated on ・1 min read

If you're like me, you worry a lot about whether the code you write is "good enough".

For the past year I've been building Gush, a personalized guide for things to do in NYC, which is currently in private beta. I'm constantly asking questions like "is this properly abstracted?", "does this have enough documentation?", "is this easy to reuse?", "is this maintainable in the long term?", or "is there a smarter way to write this?". Answering these questions is a valuable exercise, no doubt.

But Gush's future is uncertain. Code quality doesn't matter if we fail to gain user traction. I've had to learn to stop improving my code a bit earlier than I might like, because user's don't care how good the code is. For situations like mine, I think "code quality" needs a slightly different definition.

The first measure of code quality should be "does it work?". The next most important measure of quality is "does it provide an excellent experience for our users?". Until you prove that your product has traction, all other measures of quality are nice-to-have's.

Spending time on code quality is a privilege - one that must be earned by building a product that people love.

I'm not advocating sloppy code. I care about code quality and I do everything in my power to avoid accumulating tech debt. But for early stage projects, you have to find a balance, and that balance isn't always pretty.

Discussion (43)

pic
Editor guide
Collapse
samuraiseoul profile image
Scott Lavigne

The method I like when I'm doing things quickly, or lazily, or I've looked at it for too long and MUST eat or sleep, is to make an issue to re-visit the thing and label the issue as tech debt. That way you're not ignoring it, you know some things that need to happen, and you have a metric of tech debt, and how old it is, plus you know where and how to start tackling it.

Collapse
ross profile image
Ross Creighton Author

That makes a lot of sense.

Collapse
edmar profile image
Edmar S. Gonçalves

I think that the problem with "does it work?" and/or "does it provide great UX?" is that they don't answer whether the code is actually shippable.
In my experience, I've seen many cases where UX is great, but once it's time to roll out releases (be it new features or bug fixes) it's like a "brace for impact" type of situation. And as we all know, this makes things very stressful and makes devs unhappy. And when devs are unhappy, they leave. And obviously without devs there is no code 😿

This is pretty much why today I truly believe that if we don't ensure great DevX, UX will be at risk in the long run.

Collapse
ross profile image
Ross Creighton Author

I guess I would argue that shipable code goes hand in hand with good UX. Code that has a chance of breaking in production isn’t good UX.

Collapse
edmar profile image
Edmar S. Gonçalves

Fair enough. I was for the most part trying to include the experience of shipping in the measure of quality, but I see what you're saying.

Collapse
fpuffer profile image
Frank Puffer

I agree that it makes no sense to overdo code quality. As you wrote: The future is uncertain.

But in my experience, most code needs to be maintained. By yourself and by other people. Often years after it has been initially written.

Code does not have to be perfect but you need some minimal amount of quality to be able to maintain and refactor it. And I have to say that most code I have seen so far is below this minimum. Therefore it causes a lot of trouble to many people.

Collapse
ross profile image
Ross Creighton Author

Overall, I agree - I'm a perfectionist by nature and if I had my way my codebase would always be immaculate in every way. Aside from the bare essentials that beginners learn like DRYness, SRP, and variable naming, I think "minimal amount of quality" is a moving target; it depends on the needs of the product and the organization at any given time.

Collapse
phlash909 profile image
Phil Ashby

Perhaps the old adage of 'build one to throw away' helps here? Assume the experimenting / PoCs and bodges required to get that MVP in front of customers will be disposable: once you have established the value, you have bought some time to do it better, and you understand the UX better as well.

Then there is the Minimum Viable Product (MVP) concept itself, create only enough to show someone, get feedback and iterate. This minimises the code that needs writing, so it's less painful to dispose or refactor heavily.

As Scott notes here - you can defer the quality attributes for a while, as long as you know how to find them again (tagged as tech debt). You also have to consider all the stakeholders, UX applies to operations just as much as customers - especially when you are ops!

Collapse
szymach profile image
Piotr Szymaszek

I think you may be confusing an MVP with a prototype, at least the way I understand MVP, which is the product that satisfies the core need of the consumer. Then, once it proves it has a market, it can be expanded with additional features to make it more attractive. Although this supports the notion of easy disposal and rewrites, you may still have an MVP that has a pretty hefty codebase, which will not be trivial to refactor.

Collapse
phlash909 profile image
Phil Ashby

Possibly, I treat MVP as a moving target, prototypes are one-offs. Isn't language great :)

Collapse
gsto profile image
Glenn Stovall

Amen brother.

The benefits code quality gets you is better maintainability, and you don't have to maintain something that won't exist in 12 months. But having said that, you can definitely swing too far in the other direction. There are lots of measures that improve both code quality and reduce time to production. Writing lots of smaller things vs. fewer bigger things, and testing the most crucial parts of the codebase for example.

You can favor speed without favoring haste.

Collapse
ross profile image
Ross Creighton Author

Good point on smaller vs. bigger. And +1 on testing - I think "it has decent test coverage" is my #3 after 1. "it works" and 2. " it offers good UX." My code is almost always broken in subtle ways if I don't write a test.

Collapse
6temes profile image
Daniel

Writting good code is a matter of good manners with the next developer and creating a culture of quality in your company.

Writing fast and without caring about quality may work for a solo developer but, when you start to onboard new developers, there is the risk that they assume that it is ok neglect the quality of the product. At the end, if the CTO does not care that much, why should I care?

Besides, writing good code is not harder than writing bad code. What is hard is to learn how to write good code.

Still, I agree that it is better to have a not perfect product, rather than no product at all. But my opinion is that not caring about good software quality and good practices is a bigger risk than people tend to think.

Collapse
ross profile image
Ross Creighton Author

I hear what you're saying, but there is no culture, no company, no next developer if you don't have users. I'm just saying you have to find a balance. Requirements are fluid.

I care immensely about doing things the right way, to the point that it is counter productive. I wrote this post because I realized that my level of focus on quality wasn't appropriate for the constraints I was facing in the real world.

Collapse
6temes profile image
Daniel

Yeah. And, actually, "overdoing" software quality can become a form of procrastination as well.

But this is one extreme of the spectrum. The problem is that a lot of developers are on the other extreme. I feel that sometimes people don't understand that, for a startup, the risk of failing from technical bankruptcy is as real as the risk of failing from financial bankruptcy.

Thread Thread
ross profile image
Ross Creighton Author

That makes a lot of sense. Maybe calling code quality "overrated" is a little dangerous.

Collapse
hpj1992 profile image
Harshit

100% Agree.

It looks like this is applicable in some cases and there are still some situations where we should/must ask us "Is it Good/Extendable/Readable/ code" type of questions.

Instead of "Code quality is overrated", something like "Code quality is overrated often" will make a lot of sense. It will give correct gist of the article to someone scrolling through the feed.

Collapse
ross profile image
Ross Creighton Author

That's a fair point. Maybe my title is a little click-baity 🙃.

Collapse
deanius profile image
Dean Radcliffe

Wow, I wish I had a 'highlight' feature like on Medium for this one:

Spending time on code quality is a privilege - one that must be earned by building a product that people love.

I have a lot of privilege (in many ways haha), and have invested greatly in building that privilege into tools and practices that I can share so that even under pressure the code we write is efficient to write and execute as possible. That's the long game, IMO. But you're absolutely right, and I expected to want to disagree with you, but instead tip my hat, sir!

Collapse
ross profile image
Collapse
szymach profile image
Piotr Szymaszek

I see this notion a lot and I would advise not to actually think this way. It is true - writing overly polished code when you can barely meet deadlines is a recipe for a disaster.

But as a programmer you are obliged to practice your coding in a way where you can write good quality code relatively fast. Setting up a proper plan of work, TDD, custom code generators, good knowledge of tools you are using and overall experience about what constitutes good design can drastically reduce the cost of writing good code.

Nothing sucks more that having to retroactively write tests for features created in a hurry half a year go. Or actually trying to make sense of a crucial piece of application that was deemed "good enough" and now will require a month of work to refactor, because so many other parts depend on it.

As mentioned by others - technical debt is and always will be there, but you need to keep it at a low maintainable level.

Collapse
harry_wood profile image
harry_wood

Although I think there's a rather under-appreciated part of the "technical debt" metaphor, which I think is neat. "technical debt" is not just a thing you should avoid. You can choose to take on debt, and sometimes that is a very sensible choice. You might make a plan in advance for how you're going to pay it back. But if you go too heavily in debt, you may be swamped by it.

Collapse
szymach profile image
Piotr Szymaszek

I agree, which is why I have wrote that you need to keep it at a maintainable level :)

Collapse
ross profile image
Ross Creighton Author

That's a good point. The experienced programmer should have habits built up (TDD, patterns, etc) that allow her to write higher quality code without spending a ton of time.

Collapse
arjunrajkumar profile image
Arjun Rajkumar

Agree with this, and going thru a similar process for my project too. I know I CAN refactor it much more but for now, more focus on users and sales.

Also, had a similar approach to tests and TDD. At the early stage, the layout, what is displayed on each page, and product features are changing so quickly based on user feedback - that TDD seems like an overkill. Also, most times I didn’t know what the end looked like for me to even do TDD first. It was more a process of discovery as it got built, and then writing out quick tests.

There are no rules. Especially when you are building something quick and getting users are the main priority.

Collapse
ben profile image
Ben Halpern

I love the design of Gush!

I would say that... code quality is overrated among developers and underrated among everyone else. So this is a good message for this crowd.

Non-developers should value code quality but be able to call gently remind developers of other concerns. Really the best person for this job is a lead with a healthy understanding of where quality matters and where it doesn't.

For my 2 cents, I think it's a matter of being aware of where you can be fast and sloppy while containing the slop—and then knowing which failure cases are okay in a given scenario. If this goes horribly wrong, do we have a soft landing to try something else or are we going to stuck in a really terrible situation? You can't really explicitly have this conversation all the time, but having a sense of it helps.

Collapse
ross profile image
Ross Creighton Author

@ben Re: design - thanks! Do you want to test out the beta product?

That's a good observation on developers vs. non-developers.

Collapse
scottw profile image
Scott Watermasysk

The same can be said for design, copy, etc. The key is to make it good enough that you have a chance to survive another day.

I have seen founders spend hours playing with color choices and minor copy changes...then they finally hit publish, and no one is reading the page.

For code, it comes down to being good enough that you can move forward with it if you need to. Is it readable enough that if you have to hop back to it 6 months from now, will you understand the whats and whys.

Collapse
spenser profile image
Spenser

Great post - This, of course, touches on the art & science of building a company where software is your primary asset.

Step 1 - Is what you're making sustainable (profitable)?
Step 2 - Ok we're sustainable, how painful is it to keep going?

Step 2 has a ton of implications for future velocity, hiring, retention, etc. (I've seen companies in really bad spots here because of tech debt) but you're absolutely right that you can't start having step 2 problems until you're a "real company" and engineers (more than others) tend to forget this part of the evaluation.

Collapse
tomavelev profile image
Toma

Agree. The (code)software is just a tool (like the money). If it doesn't do any good to nobody, it doesn't make sense to waste time (and your life) on it. This is found the hard way by the more technical people (like me), that in the end - matters more the real world impact then the abstractions.

Collapse
josegonz321 profile image
Jose Gonzalez

I focus on code that I or anyone can trust (includes adhering to shop's standards, etc.)

Collapse
ross profile image
Ross Creighton Author

That seems like a good rule of thumb.

Collapse
josegonz321 profile image
Jose Gonzalez

I finally understood:

Code is communication with other humans not with the machine.

Thread Thread
ross profile image
Ross Creighton Author

Oh yeah that's great.

Collapse
mindplay profile image
Rasmus Schultz

You're a startup. Presumably small?

Small startups have different priorities.

If you're already medium-size team, I would completely disagree - code quality (at least maintainable code and documentation) matters, no matter where in the process you are.

For small teams, the math is pretty simple. But for teams of maybe as little as a 3-5 people (or some remote workers) and depending on the size and complexity of the project, the math isn't as simple as you laid out - it isn't just a matter of how you invest your time, there's also a matter of efficiency and stability.

That is, if the code is messy, improperly type-hinted or poorly documented, the chance of errors goes up - too much instability can cost you your early adopters.

Likewise, if the code is unmaintainable and you constantly need to refactor, you may not be able to respond to change quickly enough, and your users might walk.

So it isn't just a problem of technical debt that can be paid back later.

Again, if you're a small, tight-knit team - a few people who are completely on the same page day-to-day, getting to market fast may outweigh all those concerns.

I don't think it generalizes to every project or team though.

Collapse
ross profile image
Ross Creighton Author

Yeah, that was sort of the thesis of the post. It all depends on the situation. Definitely doesn't generalize to every project or team.

Collapse
6temes profile image
Daniel

That works for really small apps. Once the app has been in production during enough time, the risk of the "2nd system syndrome" is real.

Collapse
teochirileanu profile image
Teodor Chirileanu

I must admit to being a code quality maniac, often the expense my team's sanity...
Thanks for opening my eyes

Collapse
fannyvieira profile image
Fanny

Yes, i'm living this now.

Collapse
nahuelhds profile image
Nahue

Nice post. Totally agree

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

Clean code let's you code faster. If you're allowing your code base to wither, even during startup phases, then you're just slowing yourself down.

Collapse
elmuerte profile image
Michiel Hendriks

Code quality doesn't matter if we fail to gain user traction.

But when it does you do not have the time to fix it.