Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How bad should the code be in a startup?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 183 posts

Re: Ask HN: How bad should the code be in a startup?

#151

Post by nmfisher »

emmp wrote: post #98
redleggedfrog wrote: post #68

Earlier quoted context omitted.

"However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices." Yes, they do. The obvious one is one senior developer who writes a bunch of trash code to get stuff done in a hurry. Later is asked to maintain it and add features. But it's no fun cause it's a pile of poo. New shiny attracts his attention and he moves on (cause, you know, he delivered at his current job!). Ne…

Having worked on the support side of this dynamic, mostly in problem and incident management, I have honestly seen 12 months of product roadmap completely blown up by stability issue after stability issue that our support staff could not possibly workaround. It's really corrosive to the morale of the support staff to just be unable to do anything to help. In my case this was a relatively mature company on a version 2…

> In my case this was a relatively mature company on a version 2 reimplementation of an existing product, so it wasn't a complete death sentence.

OP specifically referred to startups, though, not mature companies. Most startups only have 12-24 months' runway to begin with, and lacking clean code/testing/best practices/etc won't (usually) kill them in that timeframe.

Lack of product-market fit, on the other hand, is the one thing guaranteed to kill a startup in that first year or two (lack of financing is the other, but this is usually fixable if you've addressed product-market fit). It's why startups spend every single developer hour on rapid prototyping/iteration/features, rather than refactoring, testing and stability.

It's not black-and-white, though. Some code is so bad that it costs time in the very short-term, because noone can figure out how it works. Some functionality is so central to the product that tests are needed to confirm it's actually functioning as intended.

There's a vast spectrum between "fully tested, clean, reusable code" and "held together with sticky tape and segfaults every other minute".

I'd say that the one key skill for a startup CTO is deciding where the team should be on that spectrum on any given day.

Re: Ask HN: How bad should the code be in a startup?

#152

Post by avilesj »

I am part of a startup for the first time and, coming from a project that was a bit messy on its own but had some structural integrity, I feel a bit torn apart with the current code quality.

For starters, the project _must_ be done in a completely serverless manner (AWS was the chosen provider) and _nobody_ in the team had experience making a complete product just using this kind of architecture.

Since performance is the main concern, at the beginning we did a very shallow research on our options for languages and relevant items to the lambda's performance. One of those was cold startup time, which the bundle size has influence in. This led us to split our custom dependencies as much as we could, making the development and testing more painful.

With both previous points presented, I can say our code quality is not good. As for velocity and delivering on time, we have had some issues because of planning mistakes and unforeseen inconveniences while using AWS SAM and AWS CF. Nonetheless, we're "on time".

We have identified some pains that we would like to fix post-launch but that moment seems to never going to happen. I got a feeling we won't have time to do maintenance on the product and we'll just be bombarded with either bugs or new features.

As others have said before, customers will only look at the app's functionality and UX. And in our case the application looks amazing. The backend, not so much.

Re: Ask HN: How bad should the code be in a startup?

#153

Post by timwaagh »

I think it should be pretty bad, tbh. a) Not part of yc. Never seen anything fail completely but I have seen projects get major delay over wanting to ensure quality. b) I'm currently leaning towards features = 100. quality = 0. This changes when you can't implement something or it takes too much time because of the state of the code base, at which point you refactor. this is a bit of a judgement call but features should have the clear priority. c) of the startups i have been at one had the cleanest code ever and the other some of the most incomprehensible code. the difference is due to who wrote it and made framework choices. some devs write clean code naturally. some platforms make that easier. unit testing wasnt a thing at either.

Re: Ask HN: How bad should the code be in a startup?

#154

Post by muzani »

> a) has Hacker News/YC ever seen a startup fail because the codebase is so bad.

Yes, but it's more that the programmers are bad instead of the code. Bad code can be patched fast by a good programmer, but becomes rapidly unmaintainable by a bad programmer. A lot of techniques and style guides out there are designed to manage bad programmers.

> b) what is the best calculation to make when trading off code quality vs features?

I have two modes: prototype and production. Prototypes are disposable, and value speed/results above all else. They should be thrown away after. Treat them as a demo to get budget for a feature or a hack to solve a problem right now. Design it to be completely destroyed and replaced, instead of replaced gradually, although you can probably reuse interfaces/contracts in between these modules.

Production code is kept clean and as maintainable as possible, but keep the engineering to a minimum. If you have to ask whether something is overengineering, it probably is.

> c) do most YC startups write tests and try to write cleanish code in V1 or does none of this matter?

I'm not sure about YC but I don't write automated tests. I have a text file with all the manual tests I need to run. Features are usually scrapped hard in a startup. IMO it's better to release a broken thing to 1000 people who complain it's broken than to release a well built thing to 100 people who think it's nice but won't pay for it.

> Should we just be chucking shit at the wall and seeing what sticks? Do most startups bin v1 and jump straight to v2 once they have traction?

Rule of thumb is you need dozens, if not hundreds of prototypes, so optimize for speed and experimentation quality. You're like a prospector, looking for ore. You don't want to build an entire mine, where there is none, and you don't want to commit too hard until you know there's a sufficient number of it.

But things are different for "ramen profitable" startups, and you should start looking into how to maintain better and add features faster.

Re: Ask HN: How bad should the code be in a startup?

#155

Post by nojvek »

As others have echoed, customers don’t buy code. They buy a tool that is reliable and solves their problem.

You could have 100s of tests but server could easily fall over. So it’s always a trade off.

One thing I can say is if you sow the seeds early, it’s easier to add a test with a new feature than add a 100 tests to a 2 year old feature that no one understands and keeps on falling over.

Some companies take this to extreme on both ends. Either no tests at all or everything needs 100% coverage delaying time to get things in the hands of customers.

Most pragmatic places I have worked at invest in test infra once they have good product market fit. Make it easy to write tests and fast to run and debug them. If it’s easy to do the right thing, why not do it ?

Re: Ask HN: How bad should the code be in a startup?

#156

Post by xupybd »

I have seen businesses thrive with bad code. But it's painful to work on that code. Near soul destroying.

I've also seen a good lead come in and rescue the direction of the code. That requires expertise in the language, a good understanding of how to rescue legacy code and political power within the organisation.

If you have to work with bad code make sure you find ways to enjoy work. Also don't allow yourself to think you're a bad Dev because you can't work fast. It's the code not you. If no one will allow you to get tests in place and fix it, it's not your fault.

Re: Ask HN: How bad should the code be in a startup?

#157

Post by dpenguin »

zjs wrote: post #133

Disclaimer: I've never worked at a startup. However... Tech debt is like any other kind of debt: a way to increase leverage. Some tech debt is like a mortgage. You get significant value, immediately, and can keep the payments manageable. Some tech debt is like a payday loan. You get ahead by days, but behind by weeks. Some tech debt is like margin trading. You make an educated bet about the future and if you're right…

Great answer along the same lines I myself look at tech debt as well.

Another important thing to keep in mind is that while you can leverage tech debt to move the business forward all you want, be extremely aware of your tech debt and reduce it before you go bust. It’s very easy to develop a belief of “this has worked for 4 years so it’s solid and doesn’t need to be looked at anymore” when in fact, you could be teetering on a total collapse of the system within 3 months because some aspect of the system/business started gaining traction non-linearly.

PS: I have worked at very large, medium and small companies that grew big. Haven’t worked at a failed startup so far - so a bit of selection bias in my opinion.

Re: Ask HN: How bad should the code be in a startup?

#158

Post by osdiab »

tikhonj wrote: post #83

In my experience, "code quality" vs "features" is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time in the short term . It's pretty simple: 1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-g…

I think that you’re fast at what you practice - if you usually write clean code, you get better at writing clean code faster. And if you complain that writing clean code takes a long time and don’t usually do it, then yes - it will take time because you never practice doing it.

Re: Ask HN: How bad should the code be in a startup?

#159

Post by HeavenFox »

tikhonj wrote: post #83

In my experience, "code quality" vs "features" is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time in the short term . It's pretty simple: 1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-g…

While what you said is true, the problem usually don't manifest in the way you described. Most engineers I know understand all these principles and adhere to them. But the codebase still end up a huge mess.

Code evolves. The technical decision you made when you were serving 30 customers doesn't make sense anymore now that you're serving 30k. The corner case you never thought would happen turns out to be very common. Suddenly your boss decide you should sell on-prem solution whereas you've been building a cloud offering.

You can make the best decision every time these new requirements come along, yet still end up in a disaster, because hill-climbing algorithm can get you stuck in the local maxima.

Oh, you say, you should've refactored your code, or rewrite from the scratch! OK, now you need to choose between spending time refactoring your code or delivering features. That's the trade-off!

Hmm ok, you say, you should've refactored along the way, so you don't need one giant refactor! Great, now you've basically asked me to predict the future.

So, shipping new feature and code quality is definitely a trade off, and is the job of us, software engineers, to make that call appropriately :)

Re: Ask HN: How bad should the code be in a startup?

#160

Post by redis_mlc »

quantified wrote: post #140
throwsoundpop wrote: post #79

Earlier quoted context omitted.

> The obvious one is one senior developer who writes a bunch of trash code to get stuff done in a hurry. Later is asked to maintain it... There's some survivorship bias at play in this; it disregards all the startups that never reached the "later" point because they were too busy polishing the code.

Someone should publish a series on such startups. Intuitively it seems there might be some. But I haven’t seen any articles naming names, describing details.

1) One SF wifi mgmt. software startup had a 50,000 LOC product with 250,000 lines of test code.

They seemed content, but obviously a lot of resources went into tests.

2) Many late startups in SF spent a lot of time and effort on perfecting CI/CD software (multiple years), or struggling with k8s in the early days (1 year to finish one service.)

3) Often post-founder programmers these days have a lot of process to overcome before shipping. I know one startup that hired dozens of programmers, but the founder (alone) still writes most of the code.

Post reply on HN