Ask HN: How bad should the code be in a startup? • Hacker News Board

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

#101

Post by anonu » Sun, Jun 07, 2020, 4:54 PM UTC

My experience as a technical founder:

a) The codebase will always be "bad". There will always be things that need improving, testing, fixing, enhancing, revisiting.

b) The optimization function to determine code quality vs features has "user adoption" as one of the main inputs. If you are going to spend time and money working on code quality, but with no users, then whats the point? Are users interested but leaving your product because of bad quality - then patch the code to bring it right above the threshold of usability and maintenance - but not more. That may seem controversial - but you need to optimize your resources (time+money) in a startup

c) I dont know anything about YC startups. But I can tell you writing tests and bad code are not mutually exclusive. Having said that, you should think about testing - always.

Having been at this startup for 3+ years now - I can tell you we've gone through 3-4 iterations of the same thing already - each time designing for more scale, more developers and more users. So I think that may be just par for the course.

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

#102

Post by steve-s » Sun, Jun 07, 2020, 4:55 PM UTC

It depends on the definitions of the terms used.

Strictly following MISRA like guidelines while developing web SaaS? Spending day on orchestrating mocks of this and that service so you can test some trivial class and tick the 100% code coverage box?

I think that code quality of individual methods does not matter as much as quality of overall architecture and that requires some design planning and regular refactoring and that I would imagine can hold you back from delivering something in a tight time frame. It does pay in longer term, I am not debating that, but before it pays off it may be too late.

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

#103

Post by underdeserver » Sun, Jun 07, 2020, 4:58 PM UTC

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…

> But would you have found product-market fit if you had been able to iterate faster, try more ideas out and didn't spend 50% of your time fighting fires? Almost definitely.

I wouldn't say definitely, but your chances would be way better.

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

#104

Post by sanketskasar » Sun, Jun 07, 2020, 5:10 PM UTC

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…

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.

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

#105

Post by umut » Sun, Jun 07, 2020, 5:10 PM UTC

JamesBarney wrote: post #96

humanrebar wrote: post #28

Earlier quoted context omitted.

> However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices. Startups do fail due to a failure to execute. Best practices aren't always about aesthetics. Ignore them too much and you end up with write-only code. You can compensate in various ways, such as designing the code so that it's possible to throw away the ugly parts later. You are correct that good senior engine…

Curious when you've worked with write only code what was the language? I've been on like 30 different projects over the last 10 years and never encountered write only c#. But I have come pretty close to encountering write only javascript. It seemed like static typing, "find all references" and the limited use of reflection style coding made the difference between bad code being annoying and completely unworkable.

I second this rather strongly.. The harder it gets to "stop" and clean-up shit, the quicker it gets to just lose it.. Especially relevant in environments where the authors of the write-only codebase are not around anymore. Somehow it is hard to blame/hate someone you go out with for lunch or beers.

What really worked great for my teams in the past is to game the transition so that the team as a whole sees it as an internalized mission, usually much stronger than that of the company. Then killing X lines of code from the old mess and beautifying the codebase becomes a shared and extremely satisfying exercise

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

#106

Post by gpsx » Sun, Jun 07, 2020, 5:12 PM UTC

The difference between a startup and a big company is not just dollars. Making a product in a startup is sort of a process of discovery. In a big company they will generally have a pretty well defined picture of what they want. When a startup says they want to do "X", I don't think that is where the big tradeof in code quality versus timeline. The problem comes when you decide you want to do "Y", but your codebase does, or is working towards doing "X". In my experience that is where there are a lot of decisions to make about how soon you get something finished. And in a startup there are a lot of these changes in direction.

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

#107

Post by chris_va » Sun, Jun 07, 2020, 5:19 PM UTC

sanketskasar wrote: post #104

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…

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 experiences, to see if that generalizes.

(with the caveat that not all senior devs had good habits)

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

#108

Post by adenta » Sun, Jun 07, 2020, 5:19 PM UTC

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 change. Your application is going to be tested, either by you, or by your users.

Does having a well defined layout of UI, service, & integration tests, a-la Martin Fowler add business value? I would argue it does not. I write mostly integration tests, because you get more, 'bang for your buck', or 'tested code per minutes spent writing tests'.

Does this testing strategy create tech debt? Absolutely. I view this as a good thing. I am causing problems for myself in the future, in exchange for expediency in the present. Either my company grows to be successful enough to care about these problems, or we go out of business. If we become successful enough to care about rampant tech debt, hooray! we are successful. If we fail, it does not matter that we leveraged tech debt, we still failed.

Writing good code is an art. There are people out there who are incredibly talented at writing good code that will be battle-tested, and infinitely scalable. These are often not skills that an early staged startup needs, when trying to find product-market fit.

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

#109

Post by tikhonj » Sun, Jun 07, 2020, 5:19 PM UTC

underdeserver wrote: post #103

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…

> But would you have found product-market fit if you had been able to iterate faster, try more ideas out and didn't spend 50% of your time fighting fires? Almost definitely. I wouldn't say definitely , but your chances would be way better.

Haha, yes, that's exactly what I meant to say, but messed up the wording. There are no guarantees, but you can improve your chances by making it easier to iterate.

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

#110

Post by Retric » Sun, Jun 07, 2020, 5:22 PM UTC

snovv_crash wrote: post #95

Retric wrote: post #46

Earlier quoted context omitted.

In the beginning architecture tends to be a form of procrastination for many people. IMO, when you have clear goals for improvement you should aim for somewhat worse than acceptable quality. Not because that’s the most efficient option, but because it for forces you to be solving customer problems. That itch to improve things is more focused when revising whatever is the worst parts of the entire project rather than…

If you only use good practices at the end it is too late - you have the anchor of the old, unmaintained and untested code around your neck. Additionally, engineers who know they are doing crap work are generally less motivated. I'd argue that the difference in time of writing tests is balanced by less time debugging, and the moment you want to re-use the code you know it already works in all the contexts the tests us…

It’s never too late, in the absolute worst case you bin some or all existing code and start over with very clear goals, and an understanding of any needed external API’s etc. Even better you can almost always extract plenty of useful bits here and there. On the other hand if you start every project thinking I need test cases, separation of concerns, continuous integration, scaling etc you’re working without a clear understanding of the end goal or how you’re getting there. Find out some tool your depending on is insufficient and you may need to toss most of what you’ve been working on down the drain with nothing to show for it.

Jumping right into whatever is the most difficult problem also means your model of the best architecture is likely to evolve as your working on the problem.

Granted this should all be on a sliding scale depending on how novel the project is.