[dead]
Startup Anti-Patterns
51–60 of 102 posts
Re: Startup Anti-Patterns
#52Earlier quoted context omitted.
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.
I've seen a startup with 10 devs + 60+ microservices and growing.
The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.
Re: Startup Anti-Patterns
#53Some 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…
Microservices are a solution to business/team organizational issues. Never technical ones.
Re: Startup Anti-Patterns
#54Earlier quoted context omitted.
Any stack has its own warts.
The Python stack is a huge wart. First performance is shit. Second type checking is shit. The only benefit is familiarity and data science. That’s literally it. No one in this thread has stated any benefit Python brings to the table on top of other popular web application languages. I guess ruby is a worse choice.
having built two enterprise data platforms in python, I can't disagree more. for a startup, development velocity matters more than code performance especially for a CRUD app even at medium scale. Frameworks like Django simply enable you to do so much and so quickly. and you can reach world scale, that's what Instagram did!
Re: Startup Anti-Patterns
#55Earlier quoted context omitted.
No, caring too much about the language and not the problem is the anti pattern
Thinking that the stack/language is not intrinsically tied to the problem and smart ass quotations define reality is the bigger problem. Go use Python for your triple A next gen game rendering engine.
Go use Nodejs + typescript for it. Why pick on just Python?
Re: Startup Anti-Patterns
#56Earlier quoted context omitted.
FWIW I think it is miscategorized. "Build it and they will come" is a different type of problem: it commonly refers to building something thinking that its value and usefulness are self-evident that it will sell itself, and therefore one needs no sales or marketing.
Look, this quote originated in a 1989 movie about ghosts and baseball. https://en.wikipedia.org/wiki/Field_of_Dreams The quote is from a ghostly, disembodied voice which encourages the protagonist to rip out their farm's corn crops and build a useless, pointless baseball field, in the middle of nowhere, so that the ghosts of dead players can come back to entertain people. The farm and the family are in financial trou…
> This is not business advice, this is superstition.
Precisely why the term is popular.
Re: Startup Anti-Patterns
#57I have done the startup thing as a failed founder and I myself call these startup patterns or antipatten mostly useless. One who enjoyed them (myself included) are destined to fail and then would concluded the same.
The so-called pattern and antipatten are useless for startup, is just like parenting guides are useless for new parents. The complexity and novel problems are so large in volume that only basic instinct function. And if you are the successful one, you would guide by whatever success brings you, if you are the failed one, well, you can fail and learned that these patterns are useless and rant here like myself.
In the end, don't destroy your health.
Re: Startup Anti-Patterns
#58Some 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…
That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a module off to a different service is easy.
Re: Startup Anti-Patterns
#59Earlier 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 once played mario kart with the stranger sitting next to me on a plane with the switch.
Re: Startup Anti-Patterns
#60Earlier quoted context omitted.
"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.
I've seen a startup with 10 devs + 60+ microservices and growing. The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.
Been there before - I worked at a company where some geniuses thought that microservices would solve all of our scaling issues. We ended up with four microservices just to send an email (one to template, one to send, one to persist to database and one other which I can't remember now).