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.
Latest comments (42)
I must admit to being a code quality maniac, often the expense my team's sanity...
Thanks for opening my eyes
Nice post. Totally agree
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.
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!
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.
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.
But when it does you do not have the time to fix it.
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.
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.