Hacker News Reader

Comment by Nextgrid | Hacker News Reader

The reason why "we" are doing this is because in a lot of cases, the tech is no longer used as a means to solve a business problem - instead, the tech is the end-game itself and complexity is a desired feature.

The market has been distorted by endless amounts of VC funding for very dubious ideas that would never be profitable to begin with, so now you have 2 solutions: you can spend a few hundred grand building a boring solution with a slim amount of engineers, realize it doesn't work and quit, or you can keep over-engineering indefinitely, keep raising more and more millions, enjoying the "startup founder" lifestyle while providing careers to unreasonable amounts of engineers with no end in sight because you're too busy over-engineering rather than "solving" the business problem, so the realization that the business isn’t viable never actually comes.

Which one do you pick? The market currently rewards the second option for all parties involved, so it's become the default choice. Worse, it’s been going on long enough that a lot of people in the industry consider this normal and don’t know any other way.

I've commented/ranted about this before, see https://news.ycombinator.com/item?id=30008257, https://news.ycombinator.com/item?id=24926060 and https://news.ycombinator.com/item?id=30272588.

View on HN

I think this is a bit naive. Startup founders do not care about providing careers for engineers, and usually want to stop being a "startup founder" as soon as they possibly can - they are chasing huge exits and being a founder is incredibly stressful.

The real reason that microservices are so prevalent is that they became fashionable, for exactly the same reason a particular item or brand of clothing becomes fashionable - influential people were seen using them and so regular people aspired to start using them too. At a certain point in the popularity curve, _not_ using microservices becomes a controversial viewpoint.

They also suffer from being what I call "conceptual crack". There is a certain kind of idea that really tickles some kinds of engineer's brains. Microservices seem like a such a clean solution, each service having its own single responsibility, so easy to draw on a whiteboard, so neat and tidy. Other ideas I place in this category are blockchain, redux, and V=f(s). Clean and tidy ideas that are compelling conceptually but result in nightmarish levels of hidden complexity when they're put into practice.

> Startup founders do not care about providing careers for engineers, and usually want to stop being a "startup founder" as soon as they possibly can - they are chasing huge exits and being a founder is incredibly stressful.

Imagine you were the founder of a business you've now realised... isn't going to be the next Google.

Your product hasn't failed! By some metrics it's very successful! You've got investors who value your company at $10 billion, and they're ready to loan you $1 billion.

But also, you've never made a profit, you've tried the most likely routes to profitability without success, similar businesses have suffered sudden implosions, and you'd have gone bankrupt years ago if it weren't for the fact there's chumps who'll work for you for free. You've got no plan for how to pay back that $1 billion.

But so long as you keep your mouth shut about that last paragraph, and accept the $1 billion? You get a high-status job, a thousand-person empire, and a fat compensation package. 1000 of your colleagues stay employed too.

Why would anyone climb off that gravy train?

For reasons the above commenter has already mentioned.

Most founder either want to run a profitable business or make their way to a big exit. Company valued at 10b? Great, sell or IPO. If the founder really realized that there was no profit ever to be made and genuinely didnt believe in the future of the company then the best move for their own self-interest would be to sell and gtfo.

Not only if your premise impractical, but it's inherently illogical for your antagonist to act as you imagine.

As someone who has been acquired prior to profitability a few times, there are subtler variations at play here. There may be avenues to profitability that the founders have no stomach for. Their sense of ego will let them do a lot but there are things they won't do. There is some honor among thieves and being willing to exploit people is very different from outright abuse. There are much worse people out there in the world to have as a boss. This sort is merely run of the mill.

The new owners have a different threshold, which you are about to learn. The exchange of money is fresh in their mind, they don't have a history with the employees, and they have a story in their head about how they can turn this money into a pile twice as high. They may well get the company to profitability, but if things were a little ridiculous before they may be a proper circus now.

There's some magic algorithm they use for figuring out options and vesting periods to retain staff, and there's some inflection point where if you stay this long then you get the most extra money per month. This is the trap they have set for you. It's practically an optical illusion, which you can only see once you've stepped past it. You will underestimate the relative value of month 3 versus month 13, and you will forget that 6 months may be worth $6N dollars but 5 months is worth $0. And so with one month to go you will be willing to put up with 4x as much bullshit, forgetting that most of that extra money was already buying the last 5 months. In effect, double spending your bonus. The moment you leave you will wonder why you didn't do it ages ago, even as you are spending the cash.

If it seems like you should stay for 2 years, then you will probably be happier with 1. If 3 years, then 2 years, maybe 18 months if there are increments smaller than a year. Of course, nobody can really tell you this, because your brain will keep asking you 'what if I had stayed' until it's happened to you at least once. But I think maybe you can tell people not to repeat that mistake. Trust your instincts from last time. This one won't be different.

False dichotomy. “No profits ever” and “unicorn IPO” are not the only two options and if the latter isn’t on the cards, “fat executive compensation and cocktail lunches while pretending you’re on the way to the latter” looks pretty good.

If the first commenter is naive, then this is even more so.

Most people love to be looked up to, loved, payed nicely. They won’t quit.

> Why would anyone climb off that gravy train?

If I actually believe I can't deliver the stress alone of feeling like a fraud and waiting for the hammer to fall seems worse than the interim reward for me, but I can certainly see people built different who would tolerate that. I think more likely is that people let themselves be convinced it will work out during the process of convincing investors.

I'd say this may be an overly cynical view of founders even. I don't think they're usually that calculating; my suspicion is that most of them believe their own hype and really do think their business is going to be the next Google. I'd say Adam Nuemann epitomizes this to me. He could be a calculating cynical genius, but he just seems like someone who in another time would have been either a rockstar or religious guru, but managed to hook up with a different crowd and everyone got caught up thinking an office sub-leasing company was some profound invention.

> Why would anyone climb off that gravy train?

Decency?

The decent would have been selected against at the paragraph-about-which-one-keeps-one's-mouth-shut stage, if not before.

A University near me has a Master of Business Administration (MBA) course that includes "Corporate Ethics".

Can you believe it? The audacity! A business charging business people, for a course of knowledge both sides know they will never use...

Ha ha ha

> You've got investors who value your company at $10 billion, and they're ready to loan you $1 billion. […] You've got no plan for how to pay back that $1 billion.

This suggests either:

- the investors [think they] know something you don’t know

- the investors are profoundly careless with their investment

- the investors don’t exist, this is completely implausible

- you’re actively misleading the investors about that paragraph, not just keeping your mouth shut

> - the investors are profoundly careless with their investment

Sounds plausible to me.

For example, consider WeWork - the CEO was literally buying office buildings with his shares, and having the company rent them off him. These investment funds are astonishingly careless.

I’m having a hard time finding information about this in the sea of other WeWork drama, so I can only speculate. This sounds like it easily could overlap with one or more of the other categories I listed.

I'm sorry... what?

This scenario you've described is such a stretch that in all likelihood it has never happened.

Startup founders don't care about providing careers per-se, but they care about the clout and connections that comes from founding a company with 100+ engineers mentioned at every cloud provider's conference as opposed to a scrappy garage with 3 greybeards hacking away Perl code running on rusty bare-metal.

CTOs and engineering managers care about their own visibility at said cloud provider's conference so it gives them bonus points for their next gig.

Individual contributors want to take the place of the aforementioned engineering manager/CTO so they'll double-down and learn the current stack and "best practices". They may not even be aware that there's any other way or how unefficient it is, as they've started their career during this madness.

If any of those people have stock options, keeping low and going with the flow is a sensible strategy if they don't want to lose them by getting pushed out for speaking against the groupthink.

There's rarely explicit malice involved at any specific stage - it's a market-level problem. The music will stop at some point though and we'll see a readjustment.

>they are chasing huge exits and being a founder is incredibly stressful.

Are they really? I think they're workaholics chasing an escape. True success is the worst outcome they could imagine, because then they'd have to tend to the rest of their life. Why be a serial founder, if its so horrible and stressful? Why keep working yourself to death after your first $10M, $100M, or $1B? Why is it never enough?

People have self-destructive instincts that are disguised in socially acceptable (or worse, praised!) forms. We shouldn't ignore the actions of founders when trying to make sense of their words.

What is V=f(s) ?

View = Function(State), the original idea behind React. I use React every day, and I enjoy it, but it hides nightmarish complexity to preserve a semblance of this original, neat and tidy idea.

How do you mean that this causes 'nightmarish complexity'? I guess it's true if you measure the amount of complexity that powers the framework, but the visible API's, the resulting project structure and the implementation itself is incredibly simple and versatile.

I'd say it's one of my favorite properties of component frameworks as opposed to raw element modification, templating solutions or classical MVC.

I'm not criticising the idea or the framework, but the react team have had to go to enormous lengths to make that one simple idea work. And the community have had to embrace (and then sometimes, forget) some pretty controversial techniques and concepts in that time, with more big changes coming soon (hello concurrent mode!). It has cost FB tens of millions of dollars to develop. I'm not saying that investment hasn't been worth it, but peek under the hood and the complexity is huge.

Alright, I agree completely. But I still don't see how it causes the same issues as microservices does. It is definitely conceptual crack (which is a genius term btw), but it isn't an ominous foot gun the same way the allure of microservices is.

EDIT: Oh I get it, you aren't talking at all about the consequences for the implementers. Only the massive effort required to turn the alluring V=f(S) into the React we have today. Got it.

They didn't say it causes the complexity, just that React hides a lot of complexity away. React is very simple and easy to use on it's surface, but it an incredibly complex collection of software under the hood.

It's funny, before I knew about React (this was ~2014), I wrote a ~7ksloc webapp with jquery and underscore that also just used memory for state and triggered a re-render of things when inputs changed. I haven't dug into how React works at a deep level lately, but at the time, for my relatively simple thing (basically did a few pivot tables worth of calculations for some financial stuff), it wasn't really that complex. I'm sure that enough engineers working on a framework for a decade can make it very complex, just wondering, as I do with many mature pieces of software, if a ground-up rewrite based on the same concept but knowing what they all know now would look drastically different from the latest dev build.

"Startup founders do not care about providing careers for engineers, and usually want to stop being a "startup founder" as soon as they possibly can - they are chasing huge exits and being a founder is incredibly stressful."

If that's true, I'd like someone to explain Craigslist.

Not a Startup, didn't follow Startup trajectory. They were building a tidy little business - except they moved past the little part.

When you start, you choose between investors+growth=exit or profitable+steady=tidy

Greatly simplified of course but Craigslist chose the second path.

"Not a Startup, didn't follow Startup trajectory."

Every company was once a startup.

Disagree. A Startup is a company designed to grow and scale fast (according to my investor friends)

A small business is one designed to be tidy.

All business start but not every one that starts is a Startup.

Include tangent here about Lean Startup vs Startup.

Also, I'm using Startup which is different than startup - the Proper Casing I think implies the Venture-to-Exit part.

https://en.m.wikipedia.org/wiki/Startup_company

An outlier that predates the modern SV scene

meh, I think its propaganda from major cloud providers. its hard to do microservices well without all their tools which is $$$

I believe this to be reasonable, though I believe there's an even stronger force at play: engineering retention. In other words, let engineers build whatever they want to build, within reason of course, because if they don't they may just go to another company that will let them. Solving for boredom. Complex systems are interesting.

I'm going to flip the narrative a little bit: whether its "tech is the end-game" or "engineers are bored and just want to have fun", I'm not sure I see the problem. I've grown out of the "maximally efficient business is the endgame" propaganda. My endgame at work is to have fun and produce enough value so I can come back tomorrow and continue having fun. Business as the endgame is a great motive for the CEOs who make millions a year. I'm not that.

Put another way, many people say that coding is as much art as science or engineering. Artists may do commissions, but ultimately their work comes from within; its not by-and-large prescriptive. The endgame is the art; the endgame is the tech; and, hopefully, that endgame is marketable. Sometimes it is, sometimes it isn't; that's not especially relevant to the process.

Or, you can take the stance that the endgame is the business, and spend your life unfulfilled, making your rich boss richer. I'd rather seek fulfillment from the tech; not the money.

Technology, viewed in the traditional sense, is a means to an end. In the context of farming, for example, the plough and its later improvements weren't the endgame--the increased yields were.

I often equate a business to a ship. It's dynamic, navigates obstacles, and is captained by leadership.

Perhaps the two examples are extremes on a spectrum. And inside is the option to learn more about the ship, so that the right problems can be resolved and solutions found, to help it reach its destination. And perhaps fulfillment can be found there.

In fact, in doing so, sometimes, new courses become realized. Personally, I find getting one charted very fulfilling.

This form of nihilistic cynicism is so dull because it's non-falsifiable.

Generally agree, but it's not cynicism, it's pessimism. Specifically about human nature - e.g. that people will encourage complexity simply to protect their jobs. I think, at worst, people will NOT make an extra effort to reduce complexity. A sin, but a small one in the scheme of things.

I don’t think any programmers are worried about job security right now. But I would say that having advanced and shiny tech is a very compelling feature to a job. I’m seeing generic Wordpress/php agencies really struggle to retain developers because no one wants to work on wordpress or php because it’s not a long term career. So places which do the exact same websites in Rails and React are doing better because even though wordpress might be faster and easier, you have to pay people more than you would if you have cool tech.

I feel like we're on the brink of nuclear war, and I'm thinking about asymptotic behavior of webapp stacks...and I'm okay with that!

I would guess that both PHP and Rails/React (and Java, C#, Python) folk will have all the work they can stomach, if they can stomach it. Consider how in-demand COBOL programmers are these days!

>Consider how in-demand COBOL programmers are these days!

I keep hearing this but I have only ever heard bad things from the people who work there. Considering how in demand all developers are right now I wouldn't even think of getting in to some obsolete tech. You'd have to pay me enough to retire quickly.

I don't believe it's malice per-se. The market sets the tone and everyone has to follow or be left behind. I've mentioned this in another comment: https://news.ycombinator.com/item?id=30760146

it's nihilistic if you find meaning in microservices, and cynical if you don't think there's a weird tech VC bubble..

I think it's pretty absurd that you could in/validate many startup hypotheses with only a few hundred grand. You can maybe pay for two engineers (plus overhead) working for a year for that price, but you'll also need someone to do your accounting, legal, product, etc work.

Falsifiability doesn't govern truth.

If I claim you felt angry when typing this, can I falsify it?

What do non-falsifiable statements like that lead to? Where does the discussion go from there?

You can make persuasive arguments about non-falsifiable points. Just because you can't form a proof or completely demolish an argument doesn't mean its uninteresting. Much of the social sciences, politics, or the real world in general relies on useful but non-falsifiable argument.

If you confine yourself to falsifiability, you will never be able to understand people.

> You can make persuasive arguments about non-falsifiable points.

You actually can't.

Like, you can make _arguments_ based on non-falsifiable points. But if the points aren't falsifiable, then there's nowhere for the discussion to go. How can I respond to them? What can I do to counter your arguments? Nothing. It's dull.

It is time intensive but not particularly hard to collect data from job postings and types of exits start-ups eventually make. I find it hard to get a good quick estimation since it is hard not to think of key examples that fit my personal expectations.

I think there's another hidden element: the majority of people in tech love wrangling with complexity on computers.

Why else would people spend hours trying to configure and customize linux distros?

To them it's a puzzle game and they very much enjoy the challenge of solving these puzzles. Having a dynamic system with many moving parts that all need to be configured just the right way so they finally fit together and come to produce the desired outcome.

This is an "epiphany" I got from playing "The Witness". I spent more than 50 hours playing the game, and I'm not even 10% finished. The puzzles in the game are original and require high level complex thinking to solve. But at some point it just got frustrating to me. I wanted to play games to sort of relax or perform low key mental activities. But this game wants you to spend a lot of mental energy to solve puzzles that seem arbitrary and pointless. The feeling I had when I was playing this game was very similar to the feelings I had when I was trying to wrangle with confusing Docker configurations.

That's when it hit me: people who love to play with Docker configurations treat it like puzzle games and they enjoy every bit of the mental effort it takes to get things just right for the system to work. It doesn't bother them that the system is fragile or over complicated, or that the mess they're building is hard to maintain.

Of course, I kind of empathize with that because that's also what got me into computers and programming in the first place. But to me, the complexity I want to deal with is in the code. Once I write code that solves a problem, I don't want to then struggle to get the code running. I want to just compile and run with one command. I want all the complexity to be contained in the code and to keep the environment simple.

But if your jobs is DevOps, you don't get to solve hard problems in the product's code base. So instead you solve hard problems in the environment that the code executes in. So you thrive in the complexity of microservices and dockers and all that buzz.

In other words, people in tech love solving hard problems, and if you don't give them hard problems, they will invent them.

Very well put something that I have been observing for the past ~5 years.

> The reason why "we" are doing this is because in a lot of cases, the tech is no longer used as a means to solve a business problem - instead, the tech is the end-game itself and complexity is a desired feature.

I have also talked about something similar before [1].

A company I worked for, after receiving way more money than they needed from Softbank, suddenly had to hire as many people as they could as a condition imposed by the investor. This got to the point we had large teams working solely on portions of a page of the application, even though the content (not only the look) of the website didn't really change for a few years. The constant rewrites and programming language changes (three full rewrites of the whole app) meant that there was an endless stream of work even for teams that only controlled half of a settings page.

Like a friend put it, "your 8-person team is a 3-day job in a normal company".

Even with the pandemic bringing customer numbers to almost zero, the website was still too frail to stay up. And the solution to that wasn't introspection about how the architecture was shit due to Conway's Law. It actually ended up in another rewrite using even more complexity and more division.

[1] https://news.ycombinator.com/item?id=30397934

Is this what it's like down in SV? You folks have enough money flying around willy-nilly to just build out untested architectures at a whim for unestablished businesses?

In the companies I've worked for architectural discussions are taken extremely seriously, we research and discuss how different approaches to solving problems has turned out for other folks and we might even run a pilot or two where we do a small scale demo to feel out the pluses and minuses.

Complexity without sufficient justification can't survive in most established businesses - a research budget certainly can, and you can use that research budget to explore options - but if you want to rewrite the codebase into a different paradigm you need to clearly demonstrate what we'll be getting out of it. That might be performance, maintainability, hireability (i.e. most local new grads are trained up in this paradigm), feature support or something else, but you need to show the benefit - I think it's a good idea to be skeptical of historical decisions, a lot of decisions early on in a company's history are made arbitrarily and sort of assumed because the momentum is on their side - you definitely should fight against that momentum and reject bad conventions but... switching to a hip new tech just for complexities sake - I have no idea how I'd ever sell that to higher ups as a project initiative and I've sold executed two framework switches (no framework to a now defunct framework to a now healthy framework) and several major data model changes (one that took about ten man years of labour).

When you've got a green field you're making decisions left and right, and some of those will be made arbitrarily - but the big commitments should be well contemplated in advance.

Yes, most recently, any barnacle that can be stapled onto the monstrosity that is the Modern Data Stack. Before then, for Kubernetes. Before then, for the Hadoop ecosystem. (These all have value -- even we work here -- but the ecosystems can't possibly support all the co's in each.)

For whatever the things of the year, a VC team will fund say 20 startups with the hope that 1-2 do well.. and are ok for the rest to flop. It's expected that 18-19 we're bad ideas, but they all still get giant sales/marketing/engineering staffs that 99% co's won't in order for the VC to have it get a go and then find out which is the winner. That is why you especially shouldn't trust speakers, marketers, and sales staff from a VC co: the financials show it's 95% chance to not be as advertised and then disappear on you in some financial shell game.

>but if you want to rewrite the codebase into a different paradigm you need to clearly demonstrate what we'll be getting out of it.

Well, that all seems reasonable until that upstart competitor comes along and upends the market with simpler stuff that doesn’t require so much bondage and discipline and tithe to process religion suppliers, and the customers start to question the value you’re supplying and wham, all that orderly process and framing is like out the window, man, like man the lifeboats. It’s a pain to stay in the game when it seems like change for changes’ sake and there’s no time to sit down and reason through a business case before the next new shiny hits. Stupid but true.

I still remember Digital trying to sell me maintenance contracts for 20 year old PDP-11s still in service out in the field. We rebuilt our entire infrastructure from scratch on new software and hardware in less than a year for 2/3rds the cost of the annual maintenance contract...the next year those pretty wood paneled Digital offices with executive dining rooms had "for lease" signs out front. Digital had failed the paradigm shift.

This take seems to be predicated on the idea that VCs are out there funding teams just because of the technical complexity of their codebase? This just doesn't seem like the reality to me.

If it can be done better for cheaper, VCs will tend to fund that team.

I guess the question is then, would VCs give money to startups who say "We're using JQuery and PHP" or to startups who say something like "We're leveraging AI and machine learning to deliver product via MERN stack ontop of AWS to give us web scale architecture"

VCs care that an early stage team will be able to execute, and to a lesser extent be able to innovate. Telling them that you use a 20 year old tech stack that few junior (aka cheap) engineer's know or want to know doesn't inspire this confidence.

You would get a similar read from VCs if you said that you use Haskell, Erlang, or up until quite recently - Rust.

There is something pretty comforting to an early stage investor of "We use Java microservices on mainstream cloud provider". Says that the team isn't ancient, isn't avant guard, and that they will be able to hire people. Worst case, an acquirer won't mind buying the leftovers or acquisition hiring the team.

I think this is a really warped view of VC funding who sorta kinda in a passing sense care about the tech stack but where the focus is almost entirely on the business side. I was at a company that bought a tiny little (originally) VC funded shop that actually was maybe 1K lines of PHP total. The secret sauce was they found a desperately underserved market that just needed something to collect and organize data between unconnected parties that took hours to do manually. Damn thing sold itself because it cost nothing to run, had essentially no maintenance costs, and made their users about 10k/user/mo from the hours it bought them back.

Businesses like the ones you speak of are gems in a sea of crap. They exist, and in that case tech stack definitely isn't important.

But for the rest of the "crap", AI- & blockchain-powered crap is more shiny than other, more boring crap, at which point the tech stack might be more important.

>"We're using JQuery and PHP"

If their MRR/ARR/MAU/DAU or whatever are strong then absolute-f'n-lutely.

Do VCs care or even know about tech stack a startup uses/intends to use?

AI and ML is one thing - it can mean a product that couldn't exist without it. There's nothing about MERN vs PHP that indicates that though.

I remember quite some years (somewhere between a decade and a decade and a half) ago having to do some truly horrific things to make things work on AWS that would've been trivial and far cheaper at the time if we'd just bought a decent server and stuck it in a colo somewhere - specifically because my customer's investors were all-in on AWS as the only possible way to do things.

I'd note that today putting that workload on AWS would probably be a pretty pleasant experience - but yeah, sometimes investors absolutely -do- care in ways that you'd really rather they didn't and you just have to suck it up.

> If it can be done better for cheaper, VCs will tend to fund that team.

That might be true if there was a shortage of VC money so they had to choose their investments very carefully. The reality is there's a huge amount of money sloshing around with few good investment opportunities.

Before we invented terms like "microservices" and "service meshes" and even SaaS and PaaS, the phenomenon was just called, "Dazzling them with bullshit."

Tony Hoare used his Turing Award speech to state the following:

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Microservices were meant to be simple encapsulation but if you create enough crosslinks in a network of very simple services then rather than removing the weight you've just pushed it out of the nodes and into the edges. And since those edges don't exist when the system is at rest, they are dead awful to analyze and reason about. There are no obvious deficiencies.

If it sounds easy VCs will not fund it, even if it's actually hard.

If it seems hard and has buzzwords then VCs will fund it; they use difficulty and buzzwordiness as proxies for being on the bleeding edge of technology because they think that's how companies succeed.

The only reason blockchain and ML for example are trending is because VCs will pump money into companies that use these buzzwords.

One of my previous employers really wanted to use AI for a mundane problem that the engineering side provided simple solutions for, but the "founder" kept trying to push for AI from any angle he could imagine. He didn't tell us this directly, but to me it was obvious that for him AI was a gimmick to get VCs to pump money into his company.

"He didn't tell us this directly, but to me it was obvious that for him AI was a gimmick to get VCs to pump money into his company."

This is exactly the kind of thing you should tell the engineers. Get them on board, straight up.

Do you suppose it's a sort of impostor syndrome? They're afraid they aren't smart enough to understand what they're paying for and so they just keep pushing the doubts down and writing the checks? Or is it full Dunning Kruger?

It's what Peter Thiel calls indefinite optimism. They have no idea what's going on but they believe there's money to be made in tech. They follow tech news to try and figure out what type of tech companies make for good invesetments.

It's a mimetic society.

https://www.luca-dellanna.com/mimetic-societies/

Do they pick up cheaper solutions, or the faster and bigger aiming with more marketable pitch?

More marketability definitely helps with passing it on to the next sucker, so it's a valuable feature that shouldn't be overlooked. The next VC is likely to be more interested in the first AI- & blockchain-powered application running on AWS InfiniDash than boring Rails on Heroku & Postgres.

Cheaper solutions would be a good pick for something that has a very good chance of success and thus doesn't need a "next sucker" nor media attention, but those are very rare as typically it would be bootstrapped and not involve VC to begin with.

My mental model: The VC model is about making a spread of bets where at least one of them will produce a huge return, so the average investment will be in a company that's irrationally overambitious.

It's not that VCs want complexity per se.

VCs and CEOs, a lot of times, want more developers working at companies, because they believe that's how they're get velocity to experiment, ability to grow and ability to change course quick enough. Up to some point that's true! The issue arises when having lots of developers requires having too many isolated teams. That's when Conway's Law kicks in: a company with lots of isolated teams will probably have complex architectures to make the teams work, most probably using (micro-)services. Hence, complexity.

To this day I can't quite fathom how 300 developers work on the same thing. Just about the time I accept that I am alone in this opinion, someone like Discord shows up proving the sorts of crazy force multipliers you can get from The Right Tool for the Right Job.

> To this day I can't quite fathom how 300 developers work on the same thing.

Yep... As someone who's been in this situation a few times: after a certain number, very badly. Things get done, but in slower and messier pace than at a smaller company.

The diminishing returns law kicks in together with sunken cost fallacy. With 10 people you're slow, with 50 you're fast, but then there and you're forever "chasing that high" of velocity increasing with headcount.

There's no way to escape what Brooks wrote in Mythical Man Month.

Unless there is a very clear-cut division of labour, like 20 teams working in 20 different libraries that don't talk to each other, there is no free lunch when it comes to team communication.

Even with four teams, I've found a lot of instances of people building the same thing. That wouldn't necessarily be bad, except often those 'things' fall into a space of errors that almost everyone makes until they learn/are taught to stop doing it.

So you notice that there are 2.5 implementations of a bit of logic because there are bugs, maybe security bugs, that cross 2 of them or are different on each.

I have found that once the code exceeds the size of one brain, it accelerates because if I don't know code exists, I will write it again. Like driving down a mountain side with the brakes on the whole way, eventually the sanity leaves the system and you go careening down the mountain.

> providing careers to unreasonable amounts of engineers with no end in sight because you're too busy over-engineering

This is so spot on. The amount of unnecessary complexity is becoming ridiculous.

I'm building out two step function flows with numerous lambda functions each to process a NACHA file (direct deposit). Something that has been done for decades in a single console app. The CTO had already made up their mind that this was how it was going to be before we even started.

It's kind of embarrassing but whatever, we are going to bill a few million to get it done. And that's just my small business logic team. It doesn't count the two or three user interfaces.

I don’t actually think this is where it comes from, necessarily. In my experience, most of this comes from the engineers themselves. Usually business just wants a CRUD app but the engineers want a distributed cloud microservice extravaganza, partly to keep themselves entertained and partly to pad their resumes.

But you don’t get upvotes for saying this on HN.

After having reviewed 300+ tech stacks, I can say with certainty there are use for AND against microservices. The benefits are numerous, they just tend to be overused and not implemented consistently the appropriate way.

That was an interesting insight that I haven't read before, thank you for sharing that.

I hate to tell you, but new technologies like react and microservices are very useful. Top tech companies regularly design whole systems using microservices. Its the legacy companies with legacy tech stacks that fail at it.

I’ve never said that those technologies or processes have no use at all.

However, in a lot of cases they could be considered premature optimisation.

A bulldozer is also a useful tool, but in the real world nobody uses one for small jobs better suited to a shovel because of how expensive it is.

In the tech industry however, VCs will be happy to bankroll the bulldozer for you so that it becomes cheaper than using the shovel. All else being equal, I too will pick the bulldozer at least as long as I’m not the one doing the maintenance it will inevitably require.

Worse, give it enough time and the skill to use shovels will disappear, and now everyone will be using bulldozers for even the smallest jobs, with all the negative externalities attached to them. The only winners are the bulldozer manufacturers.

New? Are you sure?

React is about a decade old.

Microservices is between two and seven decades old, depending on your definition.

None of this stuff is new.

This is a good point. But actually, I would argue that people against these technologies still claim they are "new".

is it even relevant? usually people who are against microservices or react are against those not because they are “new” but because usually those are incorrectly chosen tools for the job.

React is a screeching infant that has jaundice and a few other yet undiagnosed terminal illnesses.

Reply on news.ycombinator.com