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

171–180 of 183 posts

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

#171

Post by quickthrower2 »

adenta wrote: post #108
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…

As a technical cofounder who just finished the YC W20 batch ( https://terusama.com ), I can agree with some of what you are saying. At its core, an early stage startup's only goal is to create business value as ruthlessly as possible. Let's talk about how I apply this principle to my testing strategy. Do automated test suites help create business value? Absolutely, I no longer have to test everything after making a c…

Unit tests are a lot easier to write though and run faster. I think the trick is to assess risk and don’t try to get 100% coverage for the sake of it

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

#172

Post by quickthrower2 »

PragmaticPulp wrote: post #16

Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…

It’s interesting work for mature companies and seeing something resembling the Big Bang, where you can peer into deep distant code that is of a very different nature to recent code. That distant code being hacked together in startup mode does what the heck it wants and is ugly as f. It might even be in VB!

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

#173

Post by Doxin »

quickthrower2 wrote: post #171
adenta wrote: post #108

Earlier quoted context omitted.

As a technical cofounder who just finished the YC W20 batch ( https://terusama.com ), I can agree with some of what you are saying. At its core, an early stage startup's only goal is to create business value as ruthlessly as possible. Let's talk about how I apply this principle to my testing strategy. Do automated test suites help create business value? Absolutely, I no longer have to test everything after making a c…

Unit tests are a lot easier to write though and run faster. I think the trick is to assess risk and don’t try to get 100% coverage for the sake of it

I think that depends heavily on what sort of tooling you're using. E.g. writing unit tests for django is near impossible while integration tests are much easier. The ORM invariably has its tendrils throughout the entire codebase, and mocking it out is a project unto its own.

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

#174

Post by wst_ »

chris_va wrote: post #107
sanketskasar wrote: post #104

Earlier quoted context omitted.

Can you suggest a way to understand and develop the right habits? Or Any good method to improve code quality at personal and team level? Would be really useful for my case.

I imagine you'll get comments here like "have good code hygiene" and "aim for good test coverage", which are not wrong. However, for me, what really stuck was learning directly from senior developers. Anecdotally, having at least one senior developer on a team dramatically changes the long-term prospects of a project, even if they are not the ones actually leading the project. I would be curious to hear other's exper…

Unfortunately being senior is not a good indicator of someone's ability to design and write good code. Yes, it should be. No, it not always is, as my experience shows.

Now, if you are senior yourself, probably, you can see that. But when you're junior developer it's very easily to misguide yourself by looking at the senior staff without questioning anything.

So, I'd add to your advice this. Yes, learn from senior developers by observing what they do and then read more about the topic to see if they are doing right thing. Also, try to find out what are the other approaches and opinions. Even if you don't agree with them it's good to diversify your knowledge.

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

#175

Post by quickthrower2 »

Doxin wrote: post #173
quickthrower2 wrote: post #171

Earlier quoted context omitted.

Unit tests are a lot easier to write though and run faster. I think the trick is to assess risk and don’t try to get 100% coverage for the sake of it

I think that depends heavily on what sort of tooling you're using. E.g. writing unit tests for django is near impossible while integration tests are much easier. The ORM invariably has its tendrils throughout the entire codebase, and mocking it out is a project unto its own.

ORMs are excepted in my book. Good point. But DB integration tests are possible; slower than unit but still faster than end to end. I created some recently for a side project to make assertions about full text search behaviour, so I could swap out psql for elastc search (for my sins) and have coverage still.

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

#176

Post by tcgv »

gregdoesit wrote: post #45

Let me chime in my (personal) opinions, working at one of the fastest-growing startups at one point: Uber, and the details I gathered from the early times. While today, Uber is big on code quality, engineering best practices, reliability, and many others, as much as us engineers want to take credit for the success of the business via code quality: they are pretty unrelated. Few people know that when Uber started and…

> When a startup becomes wildly successful, you'll have the funds to pay off tech debt.

I'm against holding this view. Sure, if (and that's a big "if") your startup becomes wildly successful then you'll be able to fix everything or re-build your app from scratch with an army of senior developers backed by millions of dollars of venture capital funding. However, the path that Uber and other tech giants took is the exception, 99% of startups won't experience that.

With that said, I believe a lot of medium/large sized economically viable startup business can benefit from adopting a more balanced approach reagarding code quality, instead of cargo culting tech giants like Uber and friends.

Nice story though, thanks for sharing.

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

#177

Post by nailer »

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

Yes. Velocity slows, features don't get out, new versions don't get released, investors don't see product progress, funding runs out.

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

Wrong question. Avoid code. Avoid implementing things at all, use other people's APIs, fake features with manual scripts that you eventually automate.

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

Yes. expect(result).toEqual("hello world"). You don't have to do TDD if you don't want to, but it's not fucking hard to record the output once, save it, make a test and then know what you broke later. Don't be lazy.

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

#178

Post by parentheses »

to answer this question, simply look at tech debt - the analogy. you take debt to enable faster access to something.

in keeping with the analogy, every business has a different appetite for debt. the debt to equity ratio of your current position should keep you able to take on debt when you need to. the debt should never get so great that it cannot be paid down. being without debt is holding a position that doesn’t leverage your ability to take debt.

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

#179

Post by oftenwrong »

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 strongly agree, and have been involved in companies where "move fast and break things" was taken too far, and developer-years of effort was burned due to poor engineering investment. There is a time and a place for quickly hacking stuff together, but it has to be done with consideration. It is a short term gain, with a long term cost. If you are constantly breaking things, then you never get to MOVE ON. Good code is an investment. Invest in it, and let it create value - and build on that value - while you move onto the next thing.

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

#180

Post by joshhogg »

rdgthree wrote: post #169
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…

This is extremely well said. When I started coding I didn't have these habits and I was convinced it simply wasn't possible to write clean code as fast as I was writing sloppy code. Then, I met the person who is now my Head of Engineering, and he was able to code significantly faster than I was while also writing immaculate, readable, and largely bug-free code. After spending some time working with him, I was convinc…

Any particular approaches / design philosophies you found useful, either to discard or embrace? ie: Testing, "SOLID" principles, etc.
Post reply on HN