Hacker News Reader

> It's funny how different peoples' experiences can be

Yeah it is. I've never seen any startup or project fail due to code quality.

Mind sharing your experience? How many dev months had you guys been writing code before code quality became an issue? And why was it so hard to fix?

I've seen it a number of times. The company would rush to build a prototype, the product would be broken but looked like it's almost ready. Then the cost of engineering would grow and it would become harder to hire people. In some cases, the company had existing customers who were promised new features, so there was no time to fix the underlying issues, and they had to be built on top of. This cycle would repeat.

One might look at these companies and say that they are "successful" because they employ people, and some might even sell in the 7-figure range. But looking closely, each of the employees at the company could be more successful working for another company, where they don't spend their time firefighting, and instead focus on up-leveling their experience.

This is practically every software business, and is absolutely an illustration of success.

Having a surfeit of customers clamoring to pay more money for stuff--this doesn't sound like a terrible problem to have as a startup. Sure, spend time to build a reliable core, but gold-plating everything suggests there's been time to burn.

Not quite what I meant. A lot of startups are trying to find market fit and selling customers on a vision that is not yet realized. They will pitch new features and say that they can deliver if there is a contract. However, these features take longer to develop then anticipated, and are rushed on top of bad tech.

They didn’t fail though. All you’ve described is a standard software startup.

If devs are spending time “up-leveling their experience”, that just indicates that it’s a pretty slow-paced field where that time can be traded. It doesn’t mean anything about the business itself.

If you want an example of company that crumbles under its weight because of code quality, look at Frendster.

Maybe you never heard about it, but it was the leading social network before MySpace then Facebook.

It was unable to scale, and as a consequence suffered bad performances and downtime and eventually all the users moved to more recent SN.

MySpace also had similar problems, their main app was an crappy ColdFusion app that they struggled to update to add features or fix bugs.

Facebook on the other hand, was far better technically and it's probably why they won the social network war.

The version I heard was that Friendster failed to scale not because of low quality code but because the CEO refused to compromise on a feature that was inherently unscalable.

MySpace was sold to News Corporation for millions, it definitely didn't fail as a startup. There's a point where code quality becomes important, I don't think anyone's denying that, but it's after you've got traction and product-market fit.

Here’s a 2011 HN post describing that claim about an unscalable feature in more detail: https://news.ycombinator.com/item?id=2370291

(That was linked from http://highscalability.com/blog/2007/11/13/friendster-lost-l... but I had to fix the link, since it went to apps.ycombinator.com which must have been the HN URL at the time. Maybe dang can update DNS to make those old links redirect? Everything after the host was still correct.)

Sounds like a Big ball of Mud. If it solves a real problem then it can be re-invented; by the same people or by someone else. Otherwise it will slowly come to a crawl and eventually be forgotten.

What you seen to be ignoring is that the startups you worked for had the chance to fail due to bad code quality at all. And that was likely due to the fact they they shipped features without worrying about code quality so much.

It's counter intuitive that high code quality is appropriate once a startup has found some kind of product market fit, but is wholly inappropriate until then. It's a very jarring thing to tech people but to people who really understand business it's very obvious or natural.

Is the suggestion that high quality code is slower to write / iterate on? Because that hasn't been my experience.

I think one can make the argument that it’s cheaper (in the short term), but I agree that it’s not inherently faster to develop. But experienced devs who can build high quality well modeled software fast aren’t cheap, haha

That depends on the developer, some need to slow down, go back and rewrite, etc. Others write naturally good code without much extra effort. Maybe partly experience?

Back in the day a lot of OO startups burned precious time on taxonomy debates and UML diagrams. There are productive code quality discussions, and ones that don't ultimately matter.

I think there are some code quality trade offs you get for free. You should always make those, like don't write shitty variable names.

But there are a lot code quality decisions where increasing quality costs more time. (at least in the short run)

Code consistency - When you write one module one way and a another dev writes it another. Do you rewrite one of the modules for consistency?

Doing the "Right" thing - When there is a better solution and a faster solution that is maybe less maintainable. Which solution do you pick?

Corrections - You wrote some code while learning a new library/technology/api and find that you used it poorly. Do you go back and clean this up?

Code Reviews - How nit picky are you? How good is good enough? If a dev writes out a large feature and you don't like the way he did it do you ask him to fix it?

Database Mistakes - as you learn about and build out your app you realize you made the wrong choice with some database modeling, do you fix it or write unnecessarily complex SQL to fix paper over it?

Analyze or fix CSS - A button looks weird, you're not sure why the css is causing it to render funny. Do you do a deep dive finding the root cause or do you just jam some inline css in there?

As you say, some tradeoffs are free, others aren't.

One mistake I made is introducing a complex state management solution early on (NGRX); it had many benefits for code quality and overall FE architecture, but it also introduced additional layers, which required more code here and there for all details.

Entities that we get back are stored separately, then put together through selectors when they're needed on a screen. And all that jazz does take time & energy.

The net result is data consistency across components/screens (which is great), separation of concerns and clean code (cool), but at the code of slower development.

Even though, as I'm writing this, I also think about the alternative. Not having it means having less structure, maybe more issues to fix everywhere due to the lack of consistency, etc. It's not a choice that I can weigh easily, even now. I knew the tech already, used it in production before, and it still wasn't easy after all. Details details ^^

First, great blog post.

> The net result is data consistency across components/screens (which is great)

You probably don't need to be told this, but... how badly was the data really going to drift during a session? If a user notices that part of the UI is stale, they just hit reload, not a big deal. This could be improved later.

Yep, good point. I do see it now. I absolutely didn't back when I started working on that.

I had just delivered & supported an enterprise front-end framework (https://stark.nbb.be/) for which we HAD to help fix issues with state management.

But of course, I just looked at it from the wrong point of view... The point of view of a technical guy, and not the one of a founder.

I'm learning.. ;-)

Switching those cultures is a challenge. The sort of personality that got you your first ten sales doesn’t want to stop coding that way, and if someone doesn’t step in, then that precedent becomes your culture. They never grow up.

One place dealt with Rube Goldberg code forever because most of the people who thought it needed to be fixed left. People conflate “if the code didn’t start that way then we wouldn’t have a product and thus we wouldn’t be having this conversation” with “there’s a good reason for the code to continue being that way”

Well put. I do feel the counter intuitiveness at this point ;p But what you say sounds correct to me.

Code quality and performance/correctness are not at all correlated. One could argue an obsession towards code quality can even be detrimental towards true system optimizations.

To split this hair a bit, I think “code quality” has two definitions:

1. the degree to which the code can be trusted to operate correctly and in a fault-tolerant way (i.e. “yeah that API endpoint will give you a 5xx about 2% of the time, sorry about that, just retry!”)

2. the degree to which the code optimally models the problem it’s solving, as well as how flexible it is as priors/needs change in the future and whether optimal languages/frameworks/patterns are used to solve the problem expressively.

The former has obvious customer implications — if your webapp craps out every ~20min of usage, or your API silently drops data when it can’t persist something to a data store, that’s bad, you will lose customers (and you deserve to!). Conversely, lacking in the latter could slow you down as you iterate, but you’re just as likely to not need to touch that code for a while if you’re off building new views/features/what-have-you.

I think the “don’t worry about code quality” folks are generally trying to beat it into technical founders/builders’ heads that the thing they’re building is ultimately being judged as a product, not as an engineering project... but that doesn’t mean that reliability and performance aren’t part of what may make your product valuable.

Of course the latter can lead into the former, and now you have two problems!

To expand on something you hinted at. I think it's a very important insight to realize that your code base doesn't have to be homogenous, and you can make different trade offs in different parts of the app.

If you have an accounting app for instance, if it crashes every once in a while users will accept that. If it calculates your taxes incorrectly leading to an IRS audit, that is unacceptable and an existential threat to your company.

In that scenario UI could be messy but your tax crunching code has to be the cleanest and best tested code you can write.

This is a tough balance. I agree that code quality has much less importance when it comes to MVP and startups. The key point differentiator for a good engineer/lead is to be acutely aware of all the compromises and techdebt that being piled upon the product. Understand the effects of each and add them to the backlog so that as soon as an issue crops up from them these tasks from backlog are prioritized. Another important aspect is to continually architect a solution that involves components that can be broken off once we want to improve them or no longer use them.

System guarantees should be a part of your mvp. Code quality may or may not help you get there.

Fwiw - I can relate to the authors mindset after having spent a lifetime working in "enterprise software". As a team lead / lead engineer you're often judged on code quality metrics (did you clear code scans, security scans, code coverage scans, etc.). I'd have gone down the exact same rabbit hole as him.

The constraints just weren't the same. I had a team of 10, could organize the projects however I wanted, and had huge budgets.

It does indeed create a very different way of approaching things. The pressure is simply not the same at all.

I guess that's one of the big lessons for me so far; experience in large enterprises is not comparable to working on a small startup project without funding.

May sound stupid, but it took me time to integrate the idea :)

So, you had customers. Which you eventually lost, but you had them. These guys don’t even have a first customer yet. For them, code quality can wait. For you, you just waited too long to address it.

Yes and no. That we waited 'too long' is only easy to see in hindsight. When growing a company quickly, you generally don't know where the system is going to get stressed until it is already stressed. Then whether or not it is too late has a lot less to do with time (things need to be fixed yesterday) and a lot more to do with the code (how long will it take to fix). You may get lucky and have your weak link be a portion of your system with few dependencies that's easily changed. Then again you might get boned and have the problem be some core system that has dependencies snaking through half your code base (which was the case in my aforementioned startup).

Code quality has little to do with performance.

Code quality here is more messy code, code that work now but doesn't abstract, ugly variables names like x..

Things that may even make your performance better now but harder/impossible to scale later.

In my experience code quality has a LOT to do with performance. Code changes over time, and bad code generally requires a lot more compromises when those changes happen.

I suppose that like many things, it's a question of balance. Mine was probably erred to far on the quality side.

Thank you for saying this.

So many people here are chiming in with this idea that any time not spent shitting out sales is time wasted for a startup company.

What?

Please don’t take advice like this as dogma and throw the baby out with the bath water. Yes, don’t waste time like OP did, but you’re allowed to use your judgement to at least lay down some of the train tracks before you slam the throttle on the fully loaded train to 100%.

And no, I don’t advocate bike shedding on “code quality” for months before touching anything that matters. I still very much value prototyping ideas to inform MVPs, it’s an amazing workflow when you cut out the friction to get to the meat of an idea! And then by all means, get to the path of least resistance where you can sell it ASAP. But along the way you’re going to encounter friction, and you’re going to see where process is actually needed. LISTEN to these “impulses”, just do it carefully and only when the need is VERY clear.

Do not consciously sabotage all engineering efforts because a large number of people on HN told you to otherwise your startup would fail. Turns out, like everything else in life, that there isn’t some magic formula to success here— that the day is only won by the ones who build high rises on landfill.