11 ms·

Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... You could just as easily level

Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... You could just as easily level similar rants against the likes of React and it's wider ecosystem, Tensorflow, Typescript (many will disagree), Docker... I'm sure others have their own bugbears. Much of this is subjective, of course. But to me, it feels like software development is trending towards unecessarily complicated development processes and architectures. And the only beneficiaries appear to be the large technology companies. I suppose in exchange, you're getting a guarantee of maintenance. But is that really worth the additional complexity associated with the common use of these tools?

discordance 6y ago
I attribute this companies that can afford to keep way too many high skilled employees on the books while needing to keep them occupied
- Polylactic_acid 6y ago
  It seems to me the problem is all of our software is built by and for megacorps. In the context of what they need it for its the best tool for the job but it was never made for smaller orgs where 90% of the bells and whistles are not needed and end up as needless complexity.
Polylactic_acid 6y ago
I'm not sure how react fits in here. I have found it to be very simple to understand enough to be productive and upgrading to new versions has required next to no changes to our large codebase. Perhaps you mean SPA react apps which I agree are a bit more work than needed for a solo dev. Docker seems to be optimal for medium size teams. Configuring a server the old way is easier than docker for 1 server but less so for when you have 10 or CI/review apps.
- earthboundkid 6y ago
  React fits in because it's in the process of jumping the shark because FB needs it to. React is already hugely bloated for no discernible reason compared to Preact, but they're just going to keep bloating it with Suspense. Cf. https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
erikbye 6y ago
> I suppose in exchange, you're getting a guarantee of maintenance. Hah, with Google? Right.
theshadowknows 6y ago
I can’t even begin to clearly express how much I agree with you. I work for a very large company, not a software company but one that produces a lot of internal applications. The infrastructure that we leverage to do even trivial things is mind blowing. Want to send an email to customers? Roll a series of APIs and fuck it let’s do some machine learning bc yolo, integrate all the things and don’t forget to run everything through APIC. It’s insane.
areeh 6y ago
I work in TensorFlow with some regularity, and I've seen explicit examples of what the author of the article talks about where Googlers get used to their own stack (See eg: https://github.com/abseil/abseil-py/issues/99#issuecomment-478148597 https://github.com/abseil/abseil-py/issues/99#issuecomment-4... vs what is considered standard Python practice https://github.com/tensorflow/tensorflow/issues/26691#issuecomment-507600001 https://github.com/tensorflow/tensorflow/issues/26691#issuec... ) That said, I also see the opposite when this gets some traction with "normal users". The Abseil issue was fixed, and the TensorFlow 2.0 release did make TensorFlow more usable by smaller teams in many situations.
IggleSniggle 6y ago
TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it. I can't explain why there's not more cognitive dissonance there. JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you going to find teammates using those? And so I'm back at TypeScript. I think all of these "higher order" languages that do transpiling (including Scala, Closure, Kotlin, Groovy, etc) fit this same scenario. Increased toolchain complexity for a decrease in development/test/maintenance complexity. With any toolchain, though, it can be hard to know where to draw the line for "worth it for this project" until you're already an expert in using the toolchain, at which point, why wouldn't you use it?
- deleuze 6y ago
  All the JVM languages you list aren't transpiled. They target JVM bytecode just like Java. They're first class, even if Java obviously gets the overwhelming amount of VM level support. Engineers working on the JVM are definitely aware of and want to support non-Java langs.
  - IggleSniggle 6y ago
    Scala can target JavaScript. Kotlin is usually used with the JVM, but can target native machine code (and JavaScript too I think?). Transpile was the wrong word for me to use.
    - deleuze 6y ago
      Ah, I wasn't thinking of the JavaScript flavors. I think "hosted" is how Clojure describes itself.
  - kelnos 6y ago
    I think the parent meant that all of those have things (like scala.js) that allow you to write in the JVM language and compile to Javascript.
greyhair 6y ago
It makes me think of military contracting as a parallel example. (at least in the USA) The rules required to develop, build, and deliver military equipment to the US is exceedingly complex. And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. The barriers to entry in that industry are huge, purely based on the contracting requirements. So complexity (in tools and process) do not necessarily serve the individual developer the way they serve larger organizations.
- Gibbon1 6y ago
  My first boss (rip) had a internship with a defense contractor his junior year in college. They gave him one project. Design a cover for the air intake for an APC or some such. Easy!!! No not actually easy because of all the constraints. It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into the intake if someone tried starting the engine without removing the cover. He designed heavy canvas cover with metal stiffeners. And snaps. And then had to switch to a draw string because the snaps failed at -40F. And tended to get clogged with snow. Whole thing took him three months. Then there was the friend at college who worked on a VCR to record gun camera footage. Also a bunch of requirements. Higher video quality. And can't lose lock when the pilot does a hard pullout after firing his munitions. And the total production run? Well exactly how many fighters does the airforce have? Couple of thousand? I think military tech has a problem that it's trying to keep up with commercial driven tech which operates on a scale that's a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts.
  - giantrobot 6y ago
    > I think military tech has a problem that it's trying to keep out with commercial drive tech which operates on a scale that a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts. Not to excuse military contracting pork and cost padding, but this is a good point that a lot of people seem to miss. There's also the fact a military contract will be for a production run and follow on support. So they buy a thousand full units and parts/tools to fix and maintain them up front. You can't just go to Autozone and pick up a new tank tread or parts for a jet turbine.
adamsea 6y ago
React I have been thinking about, having worked with it a lot and also recently done a React / TS / GraphQL (GraphQL may have been the poorest choice I made; time will tell) project. I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects. At the same time the frontend ecosystem is a mess, as we all know, and as my CSS skills advance I see more just how much could be done with HTML / CSS / limited use of JS and your classic REST app, that's not a single-page app, and how much complexity might be able to be avoided and thus time saved. At the same time, I don't think it's just "trendiness" that has caused the growth of React and SPA's. I think they give us various wins that we probably take for granted because we're now used to them. So, the short answer to my long ramble is, I don't know. But I do think React itself, specifically, hit a sweet spot in terms of being a powerful yet understandable tool, and still remaining a tool, as opposed to a framework.
- davedx 6y ago
  Full agreement with you on those technologies. GraphQL is unfortunately still part of a low grade hype cycle where more and more companies are using it because "it's the next REST". But if you don't have a real need for the advantages it offers (for example a mobile app whose client side requests you can't easily change in sync with your API, or a data model that really is graph-like), it can be more cost than benefit. React on the other hand: I've lost count of the number of small prototypes I've started in vanilla JS, thinking "this time I can just roll it myself", then ended up pulling in React. Even the simplest things are easier and simpler with it, and hugely complex applications are also easier and simpler with it. It has a fantastic API surface.
  - adamsea 6y ago
    Exactly - that's my take on React.
- what-the-grump 6y ago
  I have that rant daily at this point. Dev A: I need an API to CRUD Me: But we've been doing CRUD for 30 years without an API this is a small project Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc. Me: Ok so you don't know how to do your job. Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... Me: But all I need is still CRUD, I dont need to scale it, I dont care if its isolated, it should have been 100 lines of code Dev B: its not best practice, my team lead agrees, here is a medium article, get with the times, Docker run everywhere, etc. Me: But what I need to connect it to internal resources and use DNS? Dev B: load balancer! If only you have an AKS cluster! Me: We work in a 25 person company that needs some very basic CRUD. It will never scale past one deployment, ever, if it does, dont worry we will pay someone to do it right because we will be swimming in money. The problem is that people are starting to not know how to do simple things. So you get grumpy admins losing their marbles over the complexity of this BS. Most of the time things could be fixed faster, easier, deployed and managed easier using simple technologies that have been around for 20+ years. But lets wack it with the Python, Docker, React, NoSQL, GraphDB, K8S hammer because...? Not only that, the juniors don't know multiple technologies anymore they just know X. So sysadmins complain that devops is pushing more roles on them, while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is... So basically, same shtick different decade.
je42 6y ago
> towards unecessarily complicated development processes and architectures please note that what's "unnecessary" for you is not necessarily unnecessary for others. this is an important point. i guess what these projects need is a way to communicate explicitly the costs of maintenance and developer mind-share when adding more complex features to their product. Because especially as small dev team it is difficult to figure out these costs during a short evaluation of the software, is not easy to pick the best tool for the job unless some members have got experience in some previous job with these tools.
- tanseydavid 6y ago
  I think your point is slightly off in its 'angle'. Consider that "unnecessarily-complicated" and "unnecessary" do NOT mean the same thing -- particularly in this case.
  - je42 6y ago
    that depends on the interpretation. most people don't mean there is a simpler implementation that has the same feature set and execution properties. Most people mean it has features i don't need, hence it is too complicated
dstroot 6y ago
>Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... Redis also comes to mind.

discordance 6y ago

I attribute this companies that can afford to keep way too many high skilled employees on the books while needing to keep them occupied

Polylactic_acid 6y ago
It seems to me the problem is all of our software is built by and for megacorps. In the context of what they need it for its the best tool for the job but it was never made for smaller orgs where 90% of the bells and whistles are not needed and end up as needless complexity.

Polylactic_acid 6y ago

I'm not sure how react fits in here. I have found it to be very simple to understand enough to be productive and upgrading to new versions has required next to no changes to our large codebase. Perhaps you mean SPA react apps which I agree are a bit more work than needed for a solo dev. Docker seems to be optimal for medium size teams. Configuring a server the old way is easier than docker for 1 server but less so for when you have 10 or CI/review apps.

earthboundkid 6y ago
React fits in because it's in the process of jumping the shark because FB needs it to. React is already hugely bloated for no discernible reason compared to Preact, but they're just going to keep bloating it with Suspense. Cf. https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank

erikbye 6y ago

> I suppose in exchange, you're getting a guarantee of maintenance. Hah, with Google? Right.

theshadowknows 6y ago

I can’t even begin to clearly express how much I agree with you. I work for a very large company, not a software company but one that produces a lot of internal applications. The infrastructure that we leverage to do even trivial things is mind blowing. Want to send an email to customers? Roll a series of APIs and fuck it let’s do some machine learning bc yolo, integrate all the things and don’t forget to run everything through APIC. It’s insane.

areeh 6y ago

I work in TensorFlow with some regularity, and I've seen explicit examples of what the author of the article talks about where Googlers get used to their own stack (See eg: https://github.com/abseil/abseil-py/issues/99#issuecomment-478148597 https://github.com/abseil/abseil-py/issues/99#issuecomment-4... vs what is considered standard Python practice https://github.com/tensorflow/tensorflow/issues/26691#issuecomment-507600001 https://github.com/tensorflow/tensorflow/issues/26691#issuec... ) That said, I also see the opposite when this gets some traction with "normal users". The Abseil issue was fixed, and the TensorFlow 2.0 release did make TensorFlow more usable by smaller teams in many situations.

IggleSniggle 6y ago

TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it. I can't explain why there's not more cognitive dissonance there. JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you going to find teammates using those? And so I'm back at TypeScript. I think all of these "higher order" languages that do transpiling (including Scala, Closure, Kotlin, Groovy, etc) fit this same scenario. Increased toolchain complexity for a decrease in development/test/maintenance complexity. With any toolchain, though, it can be hard to know where to draw the line for "worth it for this project" until you're already an expert in using the toolchain, at which point, why wouldn't you use it?

deleuze 6y ago
All the JVM languages you list aren't transpiled. They target JVM bytecode just like Java. They're first class, even if Java obviously gets the overwhelming amount of VM level support. Engineers working on the JVM are definitely aware of and want to support non-Java langs.
- IggleSniggle 6y ago
  Scala can target JavaScript. Kotlin is usually used with the JVM, but can target native machine code (and JavaScript too I think?). Transpile was the wrong word for me to use.
  - deleuze 6y ago
    Ah, I wasn't thinking of the JavaScript flavors. I think "hosted" is how Clojure describes itself.
- kelnos 6y ago
  I think the parent meant that all of those have things (like scala.js) that allow you to write in the JVM language and compile to Javascript.

greyhair 6y ago

It makes me think of military contracting as a parallel example. (at least in the USA) The rules required to develop, build, and deliver military equipment to the US is exceedingly complex. And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. The barriers to entry in that industry are huge, purely based on the contracting requirements. So complexity (in tools and process) do not necessarily serve the individual developer the way they serve larger organizations.

Gibbon1 6y ago
My first boss (rip) had a internship with a defense contractor his junior year in college. They gave him one project. Design a cover for the air intake for an APC or some such. Easy!!! No not actually easy because of all the constraints. It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into the intake if someone tried starting the engine without removing the cover. He designed heavy canvas cover with metal stiffeners. And snaps. And then had to switch to a draw string because the snaps failed at -40F. And tended to get clogged with snow. Whole thing took him three months. Then there was the friend at college who worked on a VCR to record gun camera footage. Also a bunch of requirements. Higher video quality. And can't lose lock when the pilot does a hard pullout after firing his munitions. And the total production run? Well exactly how many fighters does the airforce have? Couple of thousand? I think military tech has a problem that it's trying to keep up with commercial driven tech which operates on a scale that's a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts.
- giantrobot 6y ago
  > I think military tech has a problem that it's trying to keep out with commercial drive tech which operates on a scale that a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts. Not to excuse military contracting pork and cost padding, but this is a good point that a lot of people seem to miss. There's also the fact a military contract will be for a production run and follow on support. So they buy a thousand full units and parts/tools to fix and maintain them up front. You can't just go to Autozone and pick up a new tank tread or parts for a jet turbine.

adamsea 6y ago

React I have been thinking about, having worked with it a lot and also recently done a React / TS / GraphQL (GraphQL may have been the poorest choice I made; time will tell) project. I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects. At the same time the frontend ecosystem is a mess, as we all know, and as my CSS skills advance I see more just how much could be done with HTML / CSS / limited use of JS and your classic REST app, that's not a single-page app, and how much complexity might be able to be avoided and thus time saved. At the same time, I don't think it's just "trendiness" that has caused the growth of React and SPA's. I think they give us various wins that we probably take for granted because we're now used to them. So, the short answer to my long ramble is, I don't know. But I do think React itself, specifically, hit a sweet spot in terms of being a powerful yet understandable tool, and still remaining a tool, as opposed to a framework.

davedx 6y ago
Full agreement with you on those technologies. GraphQL is unfortunately still part of a low grade hype cycle where more and more companies are using it because "it's the next REST". But if you don't have a real need for the advantages it offers (for example a mobile app whose client side requests you can't easily change in sync with your API, or a data model that really is graph-like), it can be more cost than benefit. React on the other hand: I've lost count of the number of small prototypes I've started in vanilla JS, thinking "this time I can just roll it myself", then ended up pulling in React. Even the simplest things are easier and simpler with it, and hugely complex applications are also easier and simpler with it. It has a fantastic API surface.
- adamsea 6y ago
  Exactly - that's my take on React.
what-the-grump 6y ago
I have that rant daily at this point. Dev A: I need an API to CRUD Me: But we've been doing CRUD for 30 years without an API this is a small project Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc. Me: Ok so you don't know how to do your job. Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... Me: But all I need is still CRUD, I dont need to scale it, I dont care if its isolated, it should have been 100 lines of code Dev B: its not best practice, my team lead agrees, here is a medium article, get with the times, Docker run everywhere, etc. Me: But what I need to connect it to internal resources and use DNS? Dev B: load balancer! If only you have an AKS cluster! Me: We work in a 25 person company that needs some very basic CRUD. It will never scale past one deployment, ever, if it does, dont worry we will pay someone to do it right because we will be swimming in money. The problem is that people are starting to not know how to do simple things. So you get grumpy admins losing their marbles over the complexity of this BS. Most of the time things could be fixed faster, easier, deployed and managed easier using simple technologies that have been around for 20+ years. But lets wack it with the Python, Docker, React, NoSQL, GraphDB, K8S hammer because...? Not only that, the juniors don't know multiple technologies anymore they just know X. So sysadmins complain that devops is pushing more roles on them, while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is... So basically, same shtick different decade.

je42 6y ago

> towards unecessarily complicated development processes and architectures please note that what's "unnecessary" for you is not necessarily unnecessary for others. this is an important point. i guess what these projects need is a way to communicate explicitly the costs of maintenance and developer mind-share when adding more complex features to their product. Because especially as small dev team it is difficult to figure out these costs during a short evaluation of the software, is not easy to pick the best tool for the job unless some members have got experience in some previous job with these tools.

tanseydavid 6y ago
I think your point is slightly off in its 'angle'. Consider that "unnecessarily-complicated" and "unnecessary" do NOT mean the same thing -- particularly in this case.
- je42 6y ago
  that depends on the interpretation. most people don't mean there is a simpler implementation that has the same feature set and execution properties. Most people mean it has features i don't need, hence it is too complicated

dstroot 6y ago

>Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... Redis also comes to mind.