Is there an N=1 anti-pattern on the list? I built an enterprise platform on a low 6 figure annual contract for my first customer. It’s looking like there are no other customers who desire the same type of platform.
[flagged]
Startup Anti-Patterns
41–50 of 102 posts
Re: Startup Anti-Patterns
#42Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.
That's AI.
That's the most flattering thing I can think of to say about statements that are so confidently wrong.
Re: Startup Anti-Patterns
#43Earlier quoted context omitted.
Python is a perfectly fine choice for a tech stack. Just because you don't like something doesn't make it an anti-pattern. NodeJs + TypeScript have tons of warts of their own that you have to deal with as well. Every language does.
Nah but the warts are minor compared with other languages. Python is guaranteed to hold you back. First it’s the worst performing language for the application stack (only among the most languages for that area). Second type checking on Python is raw garbage. Third you’re going to have to use TS for the frontend anyway. You can’t escape ts. Choosing Python(or any other language) forces you to have redundant code in tw…
> Third you’re going to have to use TS for the frontend anyway. You can’t escape ts.
This is obviously wrong. Sure you have to use Javascript for the web frontend that has interactivity without round-tripping to the server. Typescript compiles to Javascript, but its hardly the only language that does.
If you're frontend is a mobile app only then you don't even have to use Javascript for it all.
Re: Startup Anti-Patterns
#44Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one
I have been building a SaaS for a business. One of the decisions I took is "as monolithic as possible" (though you cannot just use that).
One reason is that microservice architecture requires much more operational overhead. So any server we have (except for the database) should be self-contained as a rule, so that it can be autonomous and horizontally scalable.
So far, it is working quite well. You do not need suddenly a Redis for one thing, a ZooKeeper for the next one, and 3 or 4 things to just run the damn binaries. The binaries will start, do whatever migrations need to be done if it applies, and start running. They only need the database. They land health checks, api calls and all the logic needed, in one binary with zero dependencies that is containerized.
This has saved me a lot of pain compared to other architectures where I worked, but those were massive and it was justified (and there was budget for it). But you just need a bunch of teams to be able to do that.
I think going the microservices way for a small team not only does not pay off. I think it can be a suicide.
At the same time, I keep the servers internally modular (enable/disable feature).
Re: Startup Anti-Patterns
#45Wow, this is a very good site. I hope the see the other articles filled in at some point.
Re: Startup Anti-Patterns
#46Earlier quoted context omitted.
> This feels like the explanation for the Wii U, despite Nintendo obviously not being a startup of any kind. This is a particularly interesting example, because they followed up with the Switch, which is, in some ways, the diametric opposite of the Wii U. Arguably, what happened was that they had the right idea that the hybrid TV/handheld format was the right blue ocean play, but the Wii U failed by being TV first an…
That's very true, the Switch feels like an improvement on the Wii U concept in many ways. Though I feel the other big difference is that the Wii U Gamepad was highly limited in its capabilities. You could play games on it while other people watched TV or used that TV for something else, but you couldn't go beyond that. You still had to be close to the TV for it to function, and that usually meant being in the same ro…
I have a Switch 2, Nintendo user since I was very young, with the 8 bits NES, SNES, Game Boy, Nintendo 64... I would not change my Switch 2 for any PS5 or XBox, even if they are interesting :)
It is indeed a hybrid, but a very well-thought one I'd say.
Re: Startup Anti-Patterns
#47Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one
Big companies mostly seem to use the microservice(s) per team model. If your whole company is two founders, one account manager, and an engineer, you only have one team. It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit t…
"Big companies mostly seem to use the microservice(s) per team model. "
I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.
Re: Startup Anti-Patterns
#48Yep, seen too many startups jump straight to Kubernetes and microservices before they even have a validated product. Ouch.
Kubernetes is pretty ok if you keep things simple. The project I worked on had kubernetes set up years ago and from there on it just worked.
Re: Startup Anti-Patterns
#49Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.
Python is ok. People get used to it.
The biggest antipattern in my view is using different stacks for different services.
Re: Startup Anti-Patterns
#50Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one
well... no, splitting a monolith once it has grown past the point where services make sense is incredibly difficult. My last employer spent a couple of years doing it and ultimately gave up. There is just way too much interdependency to split it up cleanly.
So the key here is good engineering leadership to recognize when that point arrives, and push the company to start the transition.
And indeed, microservices solve a organization problem not an engineering problem. When I taught the architecture to new hires, I always say: a service is the largest piece of system that stays together in a reorg :)