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.
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.
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. 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!
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.