I remember how in the days way before the Web, it seemed that companies of various sizes that wanted to "computerize" their operations either built their own homebrew systems from scratch with in-house programmers or consultants, or they bought packaged software systems (MRP for manufacturers, or a distribution package for wholesalers, retail package for brick and mortar, etc.), usually with options to customize.
But none of those systems were ready to support users on the Web, and suddenly lots of new client-server technology (and security) had to be implemented, often by programmers who never created those kinds of systems before. I think the result is often the kind of low quality software and projects the reddit article describes.
I'm somewhat surprised that "turnkey" packages for manufacturers/distributors/retailers haven't become more prevalent and dominating, like they seemed to be in the old days.
> not the "we ran out of money" fan, the "our product literally cannot scale and we have no idea why" fan
There may be sampling bias at play here. For every start-up struggling to scale I’ve seen twenty who architected a solution for a billion users before shipping (or getting paid for) anything. They are the ones who hit the “we ran out of money” fan.
Waiting until your code is broken is bad. I’d argue it’s worse to waste two weeks architecting a feature for 10,000 users before you even have 100.
I don't know about his conclusion of "spend 2 weeks on architecture". If these people don't realize they need to index a database table, 2 weeks of talking about what they're going to do isn't going to help. This is 100% lack-of-experience, and it's why startups should hire more experienced people (and ideally, listen to them).
Meh. I’d like to see the codebase of the ones that survived. It may not be much different stats.
The perfect is the enemy of the good. There’s a balance between shipping code and cleaning house. As a startup that balance is weighted more towards slinging features.
Can I add also doing micro services or loads of small serverless functions way too early. It will make your project 1000x more difficult to maintain and extend in the short term for no significant gain.
Build a monolith.
Break it up later once you have a proper engineering team.
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.
OP lies about going to Harvard. He thinks he can put it on his linkedin just because he did an 8 hour online course from HarvardX on basics of leadership.
So assuming OP didn't lie about his experiences in start-ups (he 100% did lie), his diagnosis of the issues make no sense.
Unindexed db is just pure incompetence so if this is your problem then you have many more things to worry about, like learning the basics of programming.
Automatic testing is not required in start-ups and often comes at much later stages.
Auth vulnerabilities by themselves would never fail a start-up. Only data leakages caused by them would. So it's a very weird point.
There is rarely such a thing as bad code, all the code written by other people is bad while all the code written by me is either perfect or I have an excuse. It's always like that. Saying you should "improve" your code so that the devs spend less time wrestling with it is an insane statement, beyond basic quality controls. Bad code is almost always code that does something in a way that unexpected new reqs were not accounted for. And you can't expect the unexpected.
Autoscaling servers is hard. It's always better to just get what you need and then some. Within reason of course. And then leave the actual deployment optimization to dev ops engineers that you can hire later.
The post is really nonsensical. If there is one thing you should learn, it's to recognize obvious slop and outright lies.
EDIT: Also OP most likely bought upvotes. Weekend numbers like this make no sense. Especially on such a low quality post. And his linkedin is a trove of obvious lies and misrepresentations, even sneakily claiming he founded a company with 80k customers, while in reality he worked for an already established company with 80k customers as a low level employee, and then wording his claim in such a way where he has plausible deniability.
This is very glib. Hindsight is always 20/20 vision. No corpse appreciates the coroner explaining why they died. A patient prefers a doctor who prevents them moving from a patient to a corpse. A lot of startups have 3-6 months before they're dead. Stone dead! Architectural review sounds great, and it is, but the requirements change every day - they know what those requirements are right now; but later, even a day later, who knows? Can any company do a review before they know the "shape" of what they're trying to achieve? They have 3-6 months, and they need to ship. No startup has a reasonable chance of getting the architecture right unless the requirements for the product (a product that should generate income, and should pay the bills) are at least close. Testing? Test what? The product hasn't gelled. What are they testing? They're fumbling though. That reddit fella should cut them some slack at the funeral, and not dance on the grave. Ex post facto bs.
"91% had no automated tests at all". I call bullshit. The rest is all plausible, but startups love test coverage. It doesn't help them scale, it just helps with maintainability which is a different problem.
One of the top comments, which was echoed by others: "I'm guessing here, but it would not surprise me if you would find the same patterns in succesfull startups as well.. Only they had the money coming in to rebuild sooner and hire more experienced engineers.."
This shocked me when I worked in a corp. Large team of quite good Java programmers and the database was severely lacking indexes. When I (hired as a frontend dev) pestered them about it and they finally added indexes they were pretty much glowing because suddenly everything took no time at all.
Indexes are the reason why databases exist. If you don't use them you might just as well use files directly.
This really emphasises the Just Use Django (or Rails) advice.
Database indexing by default, check. Working, good, auth systems, check. Test framework, check.
> honestly just spend 2 weeks on architecture before writing code
This is true, or just import an existing architecture and stick to it. My previous company was all Django from day 1, and we mostly didn't have these issues. It's not a full replacement for thinking about architecture, but if you always think "where would Django put this" and do that (should it be in the form, the view, the model, etc), it'll get you a long way. Past the 24 months.
Does this work for all software? No obviously not. But even though most SaaS businesses will have a complicated non-web app sort of component, you can build that bit separately and keep it simple, while having the bulk of your accounts, billing, CRUD, etc, in a basic web app.
Importantly, there are very few frameworks that actually do this. Django, Rails, maybe Spring (I have no experience in that) do it, but composing a bunch of Node packages together is not a replacement, it never works that well. Flask, etc in the Python ecosystem are the same, every Flask app that gets big becomes a custom mess.
What strikes me as the actual root cause is a lack of proper oversight.
Did any of these companies have a CTO who actually knows something? Did the founder hire all of his friends to work ((or ask them to help for free) ) with him regardless of their skills? Did anyone even identify what skills would be appropriate for building what was being built (having some sort of idea about the architecture would help here)?
Nobody knows everything. Don't have people working on things they have no clue about, or make sure you watch closely if you do.
I do appreciate what’s being said here and I think there is a balance to strike. Is it a good idea to plan and design before jumping into code? Absolutely. Is it worth spending a month thinking of the perfect system when you don’t have customers actively using it or how they will use it? Probably not.
I also think it’s important to not get stuck in the sunk cost fallacy to avoid a rewrite. Take your lessons learned and bite the bullet.
I am in a position right now watching 3 years of tech debt get refactored into the same spaghetti garbage because leadership waited too long before calling a rewrite, and now they are under immense pressure to get it done but picked a warm body to rewrite it because everyone else is busy on other important things.
In another life, I was able to see the writing on the walls after initial implementation and spent two weeks rewriting the MVP to then be able to add new scalable features at a much higher velocity.
Needs analysis is crucial here, but I don’t disagree with OP.
Perhaps it’s the engineers that are the problem here. If you’re paying $120k for someone who doesn’t know how to choose a good index, you are getting ripped off.
20 comments
[ 0.21 ms ] story [ 47.3 ms ] threadBut none of those systems were ready to support users on the Web, and suddenly lots of new client-server technology (and security) had to be implemented, often by programmers who never created those kinds of systems before. I think the result is often the kind of low quality software and projects the reddit article describes.
I'm somewhat surprised that "turnkey" packages for manufacturers/distributors/retailers haven't become more prevalent and dominating, like they seemed to be in the old days.
There may be sampling bias at play here. For every start-up struggling to scale I’ve seen twenty who architected a solution for a billion users before shipping (or getting paid for) anything. They are the ones who hit the “we ran out of money” fan.
Waiting until your code is broken is bad. I’d argue it’s worse to waste two weeks architecting a feature for 10,000 users before you even have 100.
The perfect is the enemy of the good. There’s a balance between shipping code and cleaning house. As a startup that balance is weighted more towards slinging features.
But at least index your dbs.
Build a monolith.
Break it up later once you have a proper engineering team.
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.
"Step 1: Don't listen to anything OP said.
OP lies about going to Harvard. He thinks he can put it on his linkedin just because he did an 8 hour online course from HarvardX on basics of leadership.
So assuming OP didn't lie about his experiences in start-ups (he 100% did lie), his diagnosis of the issues make no sense.
Unindexed db is just pure incompetence so if this is your problem then you have many more things to worry about, like learning the basics of programming.
Automatic testing is not required in start-ups and often comes at much later stages.
Auth vulnerabilities by themselves would never fail a start-up. Only data leakages caused by them would. So it's a very weird point.
There is rarely such a thing as bad code, all the code written by other people is bad while all the code written by me is either perfect or I have an excuse. It's always like that. Saying you should "improve" your code so that the devs spend less time wrestling with it is an insane statement, beyond basic quality controls. Bad code is almost always code that does something in a way that unexpected new reqs were not accounted for. And you can't expect the unexpected.
Autoscaling servers is hard. It's always better to just get what you need and then some. Within reason of course. And then leave the actual deployment optimization to dev ops engineers that you can hire later.
The post is really nonsensical. If there is one thing you should learn, it's to recognize obvious slop and outright lies.
EDIT: Also OP most likely bought upvotes. Weekend numbers like this make no sense. Especially on such a low quality post. And his linkedin is a trove of obvious lies and misrepresentations, even sneakily claiming he founded a company with 80k customers, while in reality he worked for an already established company with 80k customers as a low level employee, and then wording his claim in such a way where he has plausible deniability.
"
Perhaps this post was a way to gain customers?
When you hire senior people, expect them to tell you what you need to do. Not the other way around. Hire people who are smarter than you.
This shocked me when I worked in a corp. Large team of quite good Java programmers and the database was severely lacking indexes. When I (hired as a frontend dev) pestered them about it and they finally added indexes they were pretty much glowing because suddenly everything took no time at all.
Indexes are the reason why databases exist. If you don't use them you might just as well use files directly.
Database indexing by default, check. Working, good, auth systems, check. Test framework, check.
> honestly just spend 2 weeks on architecture before writing code
This is true, or just import an existing architecture and stick to it. My previous company was all Django from day 1, and we mostly didn't have these issues. It's not a full replacement for thinking about architecture, but if you always think "where would Django put this" and do that (should it be in the form, the view, the model, etc), it'll get you a long way. Past the 24 months.
Does this work for all software? No obviously not. But even though most SaaS businesses will have a complicated non-web app sort of component, you can build that bit separately and keep it simple, while having the bulk of your accounts, billing, CRUD, etc, in a basic web app.
Importantly, there are very few frameworks that actually do this. Django, Rails, maybe Spring (I have no experience in that) do it, but composing a bunch of Node packages together is not a replacement, it never works that well. Flask, etc in the Python ecosystem are the same, every Flask app that gets big becomes a custom mess.
Did any of these companies have a CTO who actually knows something? Did the founder hire all of his friends to work ((or ask them to help for free) ) with him regardless of their skills? Did anyone even identify what skills would be appropriate for building what was being built (having some sort of idea about the architecture would help here)?
Nobody knows everything. Don't have people working on things they have no clue about, or make sure you watch closely if you do.
I also think it’s important to not get stuck in the sunk cost fallacy to avoid a rewrite. Take your lessons learned and bite the bullet.
I am in a position right now watching 3 years of tech debt get refactored into the same spaghetti garbage because leadership waited too long before calling a rewrite, and now they are under immense pressure to get it done but picked a warm body to rewrite it because everyone else is busy on other important things.
In another life, I was able to see the writing on the walls after initial implementation and spent two weeks rewriting the MVP to then be able to add new scalable features at a much higher velocity.
Needs analysis is crucial here, but I don’t disagree with OP.