8 ms·

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 en

• Zababa 5y ago
  That was an interesting insight that I haven't read before, thank you for sharing that.
• preseinger 5y ago
  This form of nihilistic cynicism is so dull because it's non-falsifiable.
  • yakak 5y ago
    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.
  • smegsicle 5y ago
    it's nihilistic if you find meaning in microservices, and cynical if you don't think there's a weird tech VC bubble..
    • throwaway894345 5y ago
      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.
  • javajosh 5y ago
    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.
    • Gigachad 5y ago
      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.
      • javajosh 5y ago
        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!
        • Gigachad 5y ago
          >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.
    • Nextgrid 5y ago
      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 https://news.ycombinator.com/item?id=30760146
  • philosopher1234 5y ago
    Falsifiability doesn't govern truth. If I claim you felt angry when typing this, can I falsify it?
    • msla 5y ago
      What do non-falsifiable statements like that lead to? Where does the discussion go from there?
      • philosopher1234 5y ago
        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.
        • preseinger 5y ago
          > 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.
• fdgsdfogijq 5y ago
  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.
  • Nextgrid 5y ago
    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.
  • yakshaving_jgt 5y ago
    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.
    • fdgsdfogijq 5y ago
      This is a good point. But actually, I would argue that people against these technologies still claim they are "new".
      • akoncius 5y ago
        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.
    • datavirtue 5y ago
• amackera 5y ago
  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.
  • vinyl7 5y ago
    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"
    • bcrosby95 5y ago
      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.
      • mst 5y ago
        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.
    • Spivak 5y ago
      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.
• phpnode 5y ago
  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.
  • metadat 5y ago
    What is V=f(s) ?
    • phpnode 5y ago
      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.
      • mekkkkkk 5y ago
        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.
        • 5y ago
• goodpoint 5y ago
  > 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.
  • datavirtue 5y ago
    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.
• munk-a 5y ago
  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.
  • no-s 5y ago
    >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.
• hsn915 5y ago
  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.
  • twohaibei 5y ago
    Very well put something that I have been observing for the past ~5 years.
• 015a 5y ago
  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.
  • windows2020 5y ago
    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.
• mbesto 5y ago
  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.
• ratww 5y ago
  > 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 https://news.ycombinator.com/item?id=30397934
  • deleted 5y ago
    [deleted]
• philwelch 5y ago
  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.