Hacker News Reader

Comment by londons_explore | Hacker News Reader

I disagree with this approach.

In the first few months your product will change direction so fast any semblance of a sensible design you had will be long gone by the end of the first year.

Instead, whilst the team is small (ie. 3 devs or fewer), just kludge together everything. No good coding standards, no tests, just demo-day quality.

Then, when you get above 4 developers and the product direction is clear, rebuild everything from scratch.

Sounds like a waste, but rebuilding is far faster than doing it the first time, and you'll be able to have a sensible design rather than something that has already changed direction countless times. Now is also a good time to change programming languages away from something good for prototypes into something production ready and easy to hire developers for.

View on HN

I feel like there's a decent middle-ground there, though. You don't have to sit down for two weeks and architect everything, but I feel like you should have indexes on your database columns.

Yeah, I personally like to think code quality doesn’t matter too much because you can refactor / rewrite fairly easily later. The same is not true for your data model: bad data will live with you forever and it’s much, much harder to refactor.

Eh, you can migrate bad data to a better model, too - and you can write code in such a way that you paint yourself into a corner that makes rewrites, especially incremental rewrites, very difficult.

I just mostly think that all these issues are just people being bad at writing software, and that if you're bad enough at it, you can crater your business. If it's only a little bad, the business can limp along until you can rewrite it.

In practice when people do this, 99.9% of the time it leads to data continuity issues which makes the old data essentially unusable for most important things.

Indexing your DB is a pretty basic thing to do, and one of the biggest offenders listed.

100% agreed. Database indexing is no where near premature optimization. Failing to do it is more like going for a run without tying your shoes.

It's pretty easy to run an alter table ... add index ...

If a team running a database can't or doesn't do that, when it's relevant, they don't know how to operate a database, or how to learn how to operate things. And they probably have no friends who know either.

That doesn't sound like a team where 'be sure to have an index on your DB' is going to be helpful.

Otoh, maybe they never bothered to add an index because they had no users, and unindexed queries were good enough while they developed their product that nobody wanted anyway. Table scans on 100,000 row tables aren't that slow when the whole table is in memory.

Adding indexes late isn't a huge deal. You add the index and things get faster and you go on with life. Worst case, you have to rebuild your table(s) so that indexes can apply... That could be a little rough, but probably not that rough until you have a lot of users; and if you have a lot of users, great!

I once worked at a startup where I was employee #1 doing full-stack. The CTO who hired me and 5 other developers wanted 100% test coverage from the start, and none of the details about his demands were discussed ahead of time. The rest of the tech workflow was so mired in bureaucracy and process that it was like swimming through mud. It was a disaster, we couldn't ship anything fast enough or at all, then the company pivoted, and then finally failed after about 8 months.

Seconding this. I would have a plan by month 6 for how to get past month 24 though and be iteratively laying the groundwork for it. You don’t need a scalable architecture from day 1, you just need to avoid painting yourself into corners.

I disagree with this hot take.

Add the basic invocations for formatting, linting, testing, etc. can be boilerplate copied into a repo - maybe with a Makefile or similar that is somewhat language agnostic and can wrap anything.

Run these locally before commit, and have CI do it too. You'll get a baseline level of "not total garbage" in terms of automated checks, and even if there are no real tests, at least there's an obvious place to add them later.

What languages would you start with, and what languages would you change to?

Whatever language you’re most comfortable with to ship the fastest with. Never ever learn a new language to start a startup. Learn a new language for the sake of learning it, but they’re two independent things.

I’d agree before AI but it’s so easy to add tests with AI, you might as well. Same with types. You can have AI fix your type checker errors

Did you read the article? The customers hired an outsider because they were unable to conceive of what to do. Not having indexes? Are you kidding me? Thats not a flex of "we're strategic long term thinks keeping our eye on the real problems." It's stupid. The article is right: bad engineers defer what they think is noise too long until it becomes a major problem, and an outsider had to set them straight.

Reply on news.ycombinator.com