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

51–60 of 183 posts

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

#51

Post by rdgthree »

Startups tend either to do many things right, or many things wrong. If doing x right were a coin flip, there would be a bell curve with the peak at doing half right. But it is not a coin flip.[0]

Code can be decently sloppy, but there's likely a strong correlation between good code and good startups. Not because the code made them a good startup, but because the good startups are good at most things.

Many startups will do fine with a rough codebase, and obviously you should value the code accordingly (if it's an API as a service, highly, if it's a physical product with no software component, not so much). But be wary of any startup that's close to so bad you worry it might fail. Good founders will rarely let it tip so far to that side of the scale.

Obviously there are loads of exceptions to this rule. But I think if you want to be a founder of a software driven startup or you want to find a great place to work as a software engineer, aim your expectations higher than feels reasonable and you'll probably land at a decent medium.

[0]https://twitter.com/paulg/status/1240308316808626176

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

#52

Post by JanisL »

Aeolun wrote: post #34
JanisL wrote: post #32

I define good code in terms of economics, the whole point of writing code is to generate some sort of benefit. The nature of the utility that is created by code is therefore heavily context dependent. So from this perspective I'd argue that code should never aim to be "bad", if such a situation is coming up it strongly hints that a discussion about the goals of the code and why it exists is badly needed. Also organiz…

> b) If you are thinking of trading features vs code quality you've already lost because this isn't something that can be traded. My enterprise would like to have a word with you. This is a trade they make daily.

What I'm trying to say is that it's not just some simple linear trade you can make where "less quality" implies "more features" or "more quality" implies "less features". Usually when I encounter this line of thinking, especially when it simplistic, it does a lot of damage. The biggest damage tends to be when people who are less familiar with the fundamentals of software construction use this line of thinking when allocating resources or making planning decisions.

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

#53

Post by princevegeta89 »

My 2c is that it's not only your customers that you need to keep happy, but also your own employees.

Engineers look for projects that don't give them headaches while working on them, and those that help them learn the right things. At the same time, they do look for maintainable and extensible codebases that they can enjoy working on.

The problem with bad code that is a clustermess is that things leak everywhere, and fixing one bug will lead to another. You won't have a product that is stable for your users either. At one point your engineers will make a point of rewriting things from scratch, but management may stop them. This will force them to quit ultimately so you'll have to deal with loss of resources.

On the other hand, using your users for QA is terrible. They do not report bugs at all, they get frustrated and spread the bad word. If they're paying users they will start looking for alternatives at one point.

This is all a part of your business.

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

#54

Post by hn_throwaway_99 »

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…

I often feel like I should write a "things you can skimp on, and things you can't" for a startup. There are are some things that if you do it right will immediately start paying dividends. For example, I worked at a startup that didn't take the small time to invest in automated deployment. There was one guy that knew how to manually deploy things, with the only copy of the correct prod configs on his machine. And since there were no standards for deployment, the 5 different sub-apps/services were each deployed differently. They could have literally spent less than 1 day building a proper CI/CD system which would have immediately made all their deployments painless and immediate. Instead when I got there it took many months to finally get CI/CD in place because (a) everything was always on fire so it was difficult to carve out the time to do it, and (b) retrofitting all the different systems to use one way of deployment meant I needed to retrofit 5 systems.

More importantly, my time at that startup was some some of the most stressful in my life, and for what, someone else's shitty code? I refuse to be a "code janitor" anymore. Of course all systems build tech debt over time, but it's not that hard to see which systems were built with a modicum of forethought, and which were just slapped together. Imagine if people building a house got a group together, gave everyone some tools and some lumber and said "go!" instead of actually creating a design, laying a foundation, etc. That's what a lot (not all!) of startup code is like, and I for one refuse to touch that from now on.

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

#55

Post by rdgthree »

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…

I think it's worth noting that Uber has rarely gone down (I can't even remember one example, though I'm sure it's happened). While I'm absolutely sure some parts were downright horrifying at times (we've all been there), someone clearly had a good idea of how to make tradeoffs for development speed without compromising the core bits so much that they couldn't keep up with the rapidly increasing usage.

Huge difference between something like "The Ping" and deciding not to rewrite that original contractor code.

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

#56

Post by ealexhudson »

PragmaticPulp wrote: post #36
ealexhudson wrote: post #27

Earlier quoted context omitted.

"The code should be bad enough that it allows you to ship as fast as possible" - I agree with the sentiment here, but not the expression. Speed and "validation" is obviously the outcome, and the ends should justify the means. But to say that fast must necessarily equal "bad" I'm not really sold on. Coupling is an obvious example. If you want to retain agility in your product, the various components inside should be p…

> But to say that fast must necessarily equal "bad" I'm not really sold on. In a perfect world, you'd make all of your decisions along the Pareto frontier of speed-vs-quality tradeoffs. In the real world, you don't have perfect engineers, and the Pareto frontier isn't immediately obvious. Generally speaking, the more experienced engineers are better at getting closer to that Pareto frontier of speed-quality tradeoffs…

I'm not sure about that either, tbh. Once you're in the process of managing a successful product and have a well-defined value prop; sure - pareto efficiency is interesting. Before that point, I don't think it is - at least, not in any meaningful way.

When you're building out product and figuring out where it fits and what it should do, you want to retain a lot of optionality. If you don't have the ability to change the product quickly in an agile fashion, your development process way well end up being more pareto-efficient overall but your potential customer base would be much smaller. Better to be less efficient and grow a much bigger base.

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

#57

Post by axegon_ »

Never worked in a proper start up, but I've given a hand several times. Usually it starts with textbook code. And that lasts around a month, month and a half. After that deadlines start knocking on the door, as well as patches over patches to cover up things that were either not required in the beginning or extreme edge cases and it's a race to the bottom from that point on, as far as code quality is concerned.

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

#58

Post by CraigJPerry »

There’s 2 ways to approach writing greenfield code in my mind.

The decision between them is simply “once this is shipped, would you accept having to completely re-write it from scratch to add even the smallest feature?”

If the answer is no, decent tests will make you go faster. Your commit volume by SLOC will be roughly:

1. Refactoring (~50%) 2. Tests (~35%) 3. Actual impl code for features (~15%)

That is, you’ll transact more than three times as many lines of code with your VCS repo just re-writing impl code smaller and cleaner and better organised than you will actually writing code to build the functionality.

You’ll spend more than double the adds/deletes/changes to lines of test code than adding features to the product.

You’ll implement new features at roughly the same speed today as tomorrow as next year. You can drip feed more devs into the team every 4 months or so to build out velocity further.

If you’re willing to throw it away after the first release, you’d be silly not to ditch the tests, forget the architecture and just crank out something that works - best done by a solo dev, deploy each dev in a solo fiefdom from the beginning if you want to throw more devs at the problem.

In practice, almost all code is written as a mix between these two views and is slower and more expensive than either approach above because of it.

Post reply on HN