Live data from Hacker News

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

news.ycombinator.com

141–150 of 183 posts

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

#141

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…

> The upshot is crap code makes a crap product. You took the sentence out of context. Obviously the product must work, must not have bugs, and must be straightforward enough to be maintainable. If your code is so bad that the product doesn't work, then obviously no one is going to say you're doing the right thing. I was speaking to walking the line between good-enough code and perfect-code, not advocating that people…

It seems similar to how people usually interpret MVP, which all to often is executed as MP and lacks Viability.

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

#142
post #93

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…

Can you name a company that failed because of a bad codebase as the number one reason? I feel like people walk through hypotheticals like that, but I've not heard people say "Company X failed because of that scenario."

+1

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

#143
In my experience it’s not about “bad” vs. “good” code, and not about a tradeoff between speed and quality.

It’s more about how much abstraction is built into the system. A mature codebase has a clear purpose and therefore can contain durable, high level, even beautiful abstractions. On the other hand, a founder doesn’t always (nor should they) know what their code will need to do in 6 months time, so they typically avoid writing abstractions.

You can still write good code as a founder—it’s just that good founder code looks different than good BigCo code.

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

#144
post #70

Does anyone have any best practices for onboarding new engineers to a situation like described?

Culturally, the engineers and management who created the mess should not be demonized. The situation is the enemy, not co-workers current and past. (Your private opinions can be unvarnished.)

Always steer towards how things should be looked at going forward: “we’re making this better for everyone as we add features/remove bugs”. “It probably looked like a good idea at the time” is a phrase I use a lot.

Newbies will see all the crap sooner or later. Knowing that they have more-senior allies in a shared battle, and having some ability to do stuff beyond fighting the crap, will help keep them on-board and engaged.

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

#145
post #108
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…

When I write an MVP I usually don't write unit test. What I do is write testable code with dependency injection and whatnots in mind, so when the product is mostly finalized, I can write unit tests with little or no modification to the original code.

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

#147
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 agree with nearly everything you said except modularity, I don’t find it’s a metric of code quality. At the early stage I fail to see how to properly modularize, most of the time features and customer requirements evolve so much between customers that I usually find it’s more pains than gains for the rare time the initial design hold. In my experience (B2B/high touch sales) I sometimes write a plain and simple hardcoded « if customer == "XYZ" » until the use case is refined and the market for the feature proven with at least a few paying customers.

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

#148
There's a big problem with even asking this: it's asked as if there are objective answers, but no single person can possibly have worked in enough startups to have statistically significant knowledge in this area. Unless someone has done a scientific study in this area it's just a bunch of anecdotes and disagreements.

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

#149

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've seen write-only Java where the design was fragmented over so many classes that nobody could really make a meaningful design change anymore. Classes with dozens of methods, gross violations of SOLID principles, etc. It seems entirely possible to do the same in C#.

That being said, languages in that space seem generally less prone to write-only code, so I'd agree that language choice has a big impact. Especially when an entirely novel language or framework enters the picture.

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

#150

Earlier quoted context omitted.

Jeff Bezos seems to disagree with you. Ask people about the first 10 years of Amazon. Mark Zuckerberg also disagrees.

Wouldn't this just be a classic case of survivorship bias? For every Amazon and Facebook there could be a number of companies that did similar things and fell apart.

Good code quality doesn’t guarantee success. However, those two data points indicate it may be necessary if not sufficient. There are only 4-5 tech companies operating at that scale with proven business models. Google and Microsoft being the primary others.
Post reply on HN