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.
Top comments (42)
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.
That makes a lot of sense.
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.
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.
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.
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.
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.
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!
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.
Possibly, I treat MVP as a moving target, prototypes are one-offs. Isn't language great :)
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.
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.
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.
That makes a lot of sense. Maybe calling code quality "overrated" is a little dangerous.
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.
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.
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.
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.
I agree, which is why I have wrote that you need to keep it at a maintainable level :)
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.
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.
Wow, I wish I had a 'highlight' feature like on Medium for this one:
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!
Thanks Dean!
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.
That's a fair point. Maybe my title is a little click-baity 🙃.
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.
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.
@ben Re: design - thanks! Do you want to test out the beta product?
That's a good observation on developers vs. non-developers.
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.
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.
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.
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.