7 ms·

The tooling is simply not there, so every software project keeps pushing the boundary of what is possible in its own unique fragile way. People don't want solu

The tooling is simply not there, so every software project keeps pushing the boundary of what is possible in its own unique fragile way. People don't want solutions to yesterday's problems. These are considered trivial and already solved, such as invoking a shell command (which just hides a lot of complexity under the hood). Noone will pay you for invoking existing solutions. They pay you to push the boundary. By tooling I mean programming languages, frameworks, libraries and operating systems. All of whuch have been designed for a single machine operation with random access memory model. This no longer holds true. In order to scale software today you need multi machine operations and no such OS exists for it yet. Only immature attempts such as Kubernetes, whose ergonomics are far from the simolicity that you'd expect from a unix like system. And random access memory model breaks down completely, because it is just a leaky abstraction. For full performance memory is only accessed linearly. Any random access structured programming language completely breaks down for working with GBs of data, in parallel and on a cluster of machines. I don't think we'll push the boundary further if we keep piling crap on top of existing crap. The foundations have to change and for that we'd better go back to the 70s when these ideas were being explored.

cpursley 6y ago
Erlang/Elixir would like to have a word.
- rapsey 6y ago
  It is very unfortunate so few are willing to give it a try
  - Multicomp 6y ago
    I watch Erlang / Elixir. But I really like strong static typing and type safety. So for now, I'm not learning anything beyond basic beam theory, lest I will have to unlearn it later. Gleam lang at least is definitely something I watch closely and may (may) be the BEAMs breakout moment.
qznc 6y ago
Building up the tooling is how we advanced over the last decades. It is a very slow process though because one tool has to become stable before tools on top of it can progress instead of adapting to changes. Large software projects do not have decades. Only few years. Distributed operating systems are nothing new though. Plan9 for example.
the8472 6y ago
> Any random access structured programming language completely breaks down for working with GBs of data, in parallel and on a cluster of machines. Why would you need a cluster of machines to work on mere gigabytes? You can get single-processor machines with terabytes of ram. Even laptops come with 64GB now.
- oblio 6y ago
  Yeah, big data these days should be petabytes of data or at most high hundreds of terabytes coupled with very intensive access patterns.
- sebastialonso 6y ago
  It's almost like the parent comment is just putting keywords together instead of a coherent argument!
kungito 6y ago
I'd say the problem is way different and it's a people problem. A small percentage of people invest enougu resources to be able to have the big picture and write higher quality solutions. There is a huuge percentage of people with minimal education learning along the way and by learning along the way they reinvent things as a part of their learning process. This also incentovizes rising popularity of low quality but simpler tooling
- etothepii 6y ago
  The number of developers (and developer managers) who want to only complete tasks where someone (else) has defined the inputs and the outputs is extraordinary. It is my firm belief that the vast majority of value in Software Development is in understanding the problem and the ways that Software can help. Crucially this includes knowing when it can't. When asked what my job was once I said, "to think and write code, the hard part is doing it in that order."
  - shade 6y ago
    This is a pet peeve of mine - I've worked with folks who were/are good developers but wanted to constrain their role to only development tasks. No effort to get exposure to build automation/deployment pipelines or understand how Docker/Kubernetes work at a high level, no desire to understand the bigger business domain or how our customers use the product. Pretty much just "give me a fully groomed ticket and leave me alone until I tell you it's done." On the one hand, I get it - sometimes it actually is nice to have a ticket that you don't have to think too much about the bigger context for, and can just crank out code. On the other hand, I don't think it's particularly good for your career security if you're limiting your own role to "minimally communicative code monkey" - if that's all you want to do, there's an awful lot of competition out there. I've made an effort the past couple of years, across multiple jobs now, to get some real exposure to the ops aspects of my roles (most recently, prototyping and then helping implement CI/CD pipelines for Azure Durable Functions) as well as making an effort to understand the business domain, where the gaps in our product offerings are, and what the competitors in that sector look like. It's really helpful in terms of looking for a more efficient way to solve a business problem, not to mention being able to say things like "hey, the market we're in is moving pretty heavily to Kubernetes, so it's really important that we decide how we're going to support that." I'm not saying you need to be (or can be) an expert in all of those things, but I think having the high level exposure is really important, at least when you get to a senior IC level. A minor bonus is it helps you develop a Spidey sense for when the business is pursuing strategies that don't seem likely to work, giving you a chance to either try to offer feedback/seek clarification on why, or to pull the plug and find a new gig if it seems bad enough.
viraptor 6y ago
> Noone will pay you for invoking existing solutions. They pay you to push the boundary. I wouldn't put it like that. 90% of DevOps jobs is to invoke the existing solutions quickly. Sure, there will be a little bit of pushing the boundaries here and there was needed. But largely I'd describe those jobs as putting the Lego blocks together every day - and there's lots of money in it.
- emptysongglass 6y ago
  DevOps Engineer here, former Lead (moved from startup to Big Corp). That's literally my job day in day out. Put the Lego bricks together. Everybody around me tells me I'm doing a good job and I'm sitting here thinking, "but all I did was Google these things and insert some variables in some Helm charts?" The other part of my job is more difficult, which is encouraging teams to de-silo and automate wherever possible but so many of the employees are threatened by this idea at Big Corp that I'm encountering a LOT of resistance.
  - mtberatwork 6y ago
    I think your first point answers your second point. It's only human nature for people to worry about their jobs.
  - quantumcd 6y ago
    Same here. It's easy to forget the difference between a master LEGO builder and the average person just piecing together bricks though. Knowing what to build and when/how is a lot of the job too. I try and remind myself that we're also often there to help other people build better things, perhaps analogous to automatically sorting LEGO bricks so other people building can move faster with fewer compromises.
    - pbronez 6y ago
      This applies to most high-value knowledge work. Figuring out which problem to solve and how to define success is much more difficult than actually turning the crank to implement whatever solution.
tluyben2 6y ago
> People don't want solutions to yesterday's problems. These are considered trivial and already solved, such as invoking a shell command (which just hides a lot of complexity under the hood). Noone will pay you for invoking existing solutions. I am not exactly sure what you mean by this, but taken literally; most companies pay well for this and it's also the most common work programmers do all over the world. But maybe I misunderstand your meaning.
- oblio 6y ago
  Heck, aren't Google devs complaining about "proto-to-proto" work ("protobuff to protobuff", not "prototype to prototype"), where they're basically just CRUDing together pre-existing services? Google pays a lot and has huge scale plus is considered quite innovative (I think they publish a lot of papers each year), yet most of their work is the typical enterprise middleware development job.
goto11 6y ago
> Noone will pay you for invoking existing solutions. They pay you to push the boundary. Most businesses pay developers to solve problems, not to push boundaries. They typically prefer developers using "boring" tried-and-true approaches. In my experience it is developers who push for "boundary pushing" solutions because it is more exciting. And of course the vendors selling those solutions.
- hnarn 6y ago
  If it was true that the only way to get "paid" is to push boundaries, 99% of everyone working in IT would be out of a job. Kurt Vonnegut once said that "the problem with the world is that everyone wants to build, and noone wants to do maintenance". I'm reminded of that quote daily working in the software industry -- the people "pushing boundaries" are a tiny minority and if they were the only ones working our modern world would come crashing down in an afternoon.
  - anonymoushn 6y ago
    You can hardly expect people to talk about all the maintenance they did in their performance review
    - dolmen 6y ago
      Why? Work should be balanced between creating new code and maintaining existing code. And managers should value both.
      - anonymoushn 6y ago
        Because the company's internal rubric for performance reviews awards 0 points for this kind of work.
      - jokethrowaway 6y ago
        You answered yourself. Maintenance is seen by business as a cost, innovation is seen as potentially bringing more money. The incentives are all wrong and that translate to engineers (and teams, and companies) chasing features and not fixing bugs. A rewrite is often the only way of getting enough resources to fix up things.
de_keyboard 6y ago
I think the problem is we keep using the same crappy tools because people are scared to be an early adopter. Meanwhile, there are things sitting on the shelf that solve these problems in a principled way and make things simpler: - ML languages - Nix - Bazel - Erlang - Rust Some tools that are great and have large adoption: - Git - Terraform
- b3kart 6y ago
  > ML languages What are those?
  - nmca 6y ago
    I suspect he means Ocaml, sml and bucklescript.
    - Multicomp 6y ago
      agreed. ML [1] is short for meta langauge. Because it is not very C-like syntax by default, it can feel exotic and alien to most of today's unix graybeards, 90s enterprise, aughts startup folks, and even the JS crowd. see also its 'newer incarnations' Scala, F#, Nemerle...(don't slay me)Rust(ish) [1] https://en.m.wikipedia.org/wiki/ML_(programming_language) https://en.m.wikipedia.org/wiki/ML_(programming_language)
    - b3kart 6y ago
      Oh, I see. Thanks!
- shipp02 6y ago
  I would add E[1] language to that list. [1]http://erights.org/elang/index.html http://erights.org/elang/index.html
- iFreilicht 6y ago
  I think Nix will take a long while to increase adoption, because it is hard to learn. The language is new, the concept is new, the mental model is new. But you need to master all of those to use the tool effectively. Same goes for the other items in your list. Git had enough time and force behind it, and I believe the other tools will succeed as well. But it will take time.
coldtea 6y ago
>People don't want solutions to yesterday's problems. These are considered trivial and already solved, such as invoking a shell command (which just hides a lot of complexity under the hood). Noone will pay you for invoking existing solutions. They pay you to push the boundary. You'd be surprised. Most software production re-builds and re-invokes existing solutions that just aren't systematized yet. It certainly doesn't push any boundaries...
AlchemistCamp 6y ago
> By tooling I mean programming languages, frameworks, libraries and operating systems. All of whuch have been designed for a single machine operation with random access memory model. You should learn about Elixir (or anything on Erlang VM).
eandre 6y ago
Agreed completely. Today there's such a large disconnect between how you think about software (APIs, services, systems, data flows, replication, data storage, access patterns, and so on) and how you actually develop software, with plain text files on disk that don't at all resemble our mental model. I've been working on a new type of framework that is about making how we develop software match this mental model. Where the higher-level primitives we think in terms of are first-class citizens at the language level. I think only then is it possible to reason about, and scale, software in a much more productive and effective way.
- zmmmmm 6y ago
  > Today there's such a large disconnect between how you think about software (APIs, services, systems, data flows, replication, data storage, access patterns, and so on) and how you actually develop software, with plain text files on disk I view this a little differently. People have tried again and again to move the abstraction layer for coding above text files. This was happening back in the 90's (in the guise of so-called "4GLs" [0]) and still today (now rebranded as "no-code" [1]). I myself spent a good deal of effort trying to code "diagramatically" through top down UML (with an amazing product for it's time, Together). So the ambition to shift programming up the abstraction food chain has been tried continuously for 30 years and continued to fail every time. Eventually I changed my view and decided that there were fundamental reasons why higher level abstractions don't work - software is just too complex, the abstractions are too leaky. The details matter, they are critically important. We are in a long arc of figuring out the right abstractions that may take a century or more and in the meantime, we simply have to have the flexibility of text based formats to let us express the complexity we need to manage in the meantime. [0] https://en.wikipedia.org/wiki/Fourth-generation_programming_language https://en.wikipedia.org/wiki/Fourth-generation_programming_... [1] https://techcrunch.com/2020/10/26/the-no-code-generation-is-arriving/ https://techcrunch.com/2020/10/26/the-no-code-generation-is-...
  - eandre 6y ago
    I don't disagree,but I think there's space for several levels of abstraction between where we are today and no-code tools.
IncRnd 6y ago
> People don't want solutions to yesterday's problems. These are considered trivial and already solved, such as invoking a shell command (which just hides a lot of complexity under the hood). Noone will pay you for invoking existing solutions. They pay you to push the boundary. People are paid to work on products which provide value to the business. There is always a Minimum Viable Product, MVP. Meet that. Exceeding that is the boundary that needs to be pushed, not grabbing the latest, possibly untested, tools off the shelf. > And random access memory model breaks down completely, because it is just a leaky abstraction. For full performance memory is only accessed linearly. Any random access structured programming language completely breaks down for working with GBs of data, in parallel and on a cluster of machines. This is why constantly re-engineering (for the purpose of engineering) is not the most useful method. I used to work in FoxPro with databases that were GBs of data. If today those GBs are difficult to handle, which they aren't, then there is a problem with how the stack was put together. GBs are trivial.
joe_the_user 6y ago
To put is cynically, everyone knows that yesterday's tools don't work. So it's better to try today's tools, which you don't yet know don't work. This allows one poorly thought out idea to replace another - especially when selling new stuff is profitable. That said, it's implausible that the main problem is scaling since mainframes scaled considerable data quite a while back.

cpursley 6y ago

Erlang/Elixir would like to have a word.

rapsey 6y ago
It is very unfortunate so few are willing to give it a try
- Multicomp 6y ago
  I watch Erlang / Elixir. But I really like strong static typing and type safety. So for now, I'm not learning anything beyond basic beam theory, lest I will have to unlearn it later. Gleam lang at least is definitely something I watch closely and may (may) be the BEAMs breakout moment.

qznc 6y ago

Building up the tooling is how we advanced over the last decades. It is a very slow process though because one tool has to become stable before tools on top of it can progress instead of adapting to changes. Large software projects do not have decades. Only few years. Distributed operating systems are nothing new though. Plan9 for example.

the8472 6y ago

> Any random access structured programming language completely breaks down for working with GBs of data, in parallel and on a cluster of machines. Why would you need a cluster of machines to work on mere gigabytes? You can get single-processor machines with terabytes of ram. Even laptops come with 64GB now.

oblio 6y ago
Yeah, big data these days should be petabytes of data or at most high hundreds of terabytes coupled with very intensive access patterns.
sebastialonso 6y ago
It's almost like the parent comment is just putting keywords together instead of a coherent argument!

kungito 6y ago

I'd say the problem is way different and it's a people problem. A small percentage of people invest enougu resources to be able to have the big picture and write higher quality solutions. There is a huuge percentage of people with minimal education learning along the way and by learning along the way they reinvent things as a part of their learning process. This also incentovizes rising popularity of low quality but simpler tooling

etothepii 6y ago
The number of developers (and developer managers) who want to only complete tasks where someone (else) has defined the inputs and the outputs is extraordinary. It is my firm belief that the vast majority of value in Software Development is in understanding the problem and the ways that Software can help. Crucially this includes knowing when it can't. When asked what my job was once I said, "to think and write code, the hard part is doing it in that order."
- shade 6y ago
  This is a pet peeve of mine - I've worked with folks who were/are good developers but wanted to constrain their role to only development tasks. No effort to get exposure to build automation/deployment pipelines or understand how Docker/Kubernetes work at a high level, no desire to understand the bigger business domain or how our customers use the product. Pretty much just "give me a fully groomed ticket and leave me alone until I tell you it's done." On the one hand, I get it - sometimes it actually is nice to have a ticket that you don't have to think too much about the bigger context for, and can just crank out code. On the other hand, I don't think it's particularly good for your career security if you're limiting your own role to "minimally communicative code monkey" - if that's all you want to do, there's an awful lot of competition out there. I've made an effort the past couple of years, across multiple jobs now, to get some real exposure to the ops aspects of my roles (most recently, prototyping and then helping implement CI/CD pipelines for Azure Durable Functions) as well as making an effort to understand the business domain, where the gaps in our product offerings are, and what the competitors in that sector look like. It's really helpful in terms of looking for a more efficient way to solve a business problem, not to mention being able to say things like "hey, the market we're in is moving pretty heavily to Kubernetes, so it's really important that we decide how we're going to support that." I'm not saying you need to be (or can be) an expert in all of those things, but I think having the high level exposure is really important, at least when you get to a senior IC level. A minor bonus is it helps you develop a Spidey sense for when the business is pursuing strategies that don't seem likely to work, giving you a chance to either try to offer feedback/seek clarification on why, or to pull the plug and find a new gig if it seems bad enough.

viraptor 6y ago

> Noone will pay you for invoking existing solutions. They pay you to push the boundary. I wouldn't put it like that. 90% of DevOps jobs is to invoke the existing solutions quickly. Sure, there will be a little bit of pushing the boundaries here and there was needed. But largely I'd describe those jobs as putting the Lego blocks together every day - and there's lots of money in it.

emptysongglass 6y ago
DevOps Engineer here, former Lead (moved from startup to Big Corp). That's literally my job day in day out. Put the Lego bricks together. Everybody around me tells me I'm doing a good job and I'm sitting here thinking, "but all I did was Google these things and insert some variables in some Helm charts?" The other part of my job is more difficult, which is encouraging teams to de-silo and automate wherever possible but so many of the employees are threatened by this idea at Big Corp that I'm encountering a LOT of resistance.
- mtberatwork 6y ago
  I think your first point answers your second point. It's only human nature for people to worry about their jobs.
- quantumcd 6y ago
  Same here. It's easy to forget the difference between a master LEGO builder and the average person just piecing together bricks though. Knowing what to build and when/how is a lot of the job too. I try and remind myself that we're also often there to help other people build better things, perhaps analogous to automatically sorting LEGO bricks so other people building can move faster with fewer compromises.
  - pbronez 6y ago
    This applies to most high-value knowledge work. Figuring out which problem to solve and how to define success is much more difficult than actually turning the crank to implement whatever solution.

tluyben2 6y ago

> People don't want solutions to yesterday's problems. These are considered trivial and already solved, such as invoking a shell command (which just hides a lot of complexity under the hood). Noone will pay you for invoking existing solutions. I am not exactly sure what you mean by this, but taken literally; most companies pay well for this and it's also the most common work programmers do all over the world. But maybe I misunderstand your meaning.

oblio 6y ago
Heck, aren't Google devs complaining about "proto-to-proto" work ("protobuff to protobuff", not "prototype to prototype"), where they're basically just CRUDing together pre-existing services? Google pays a lot and has huge scale plus is considered quite innovative (I think they publish a lot of papers each year), yet most of their work is the typical enterprise middleware development job.

goto11 6y ago

> Noone will pay you for invoking existing solutions. They pay you to push the boundary. Most businesses pay developers to solve problems, not to push boundaries. They typically prefer developers using "boring" tried-and-true approaches. In my experience it is developers who push for "boundary pushing" solutions because it is more exciting. And of course the vendors selling those solutions.

hnarn 6y ago
If it was true that the only way to get "paid" is to push boundaries, 99% of everyone working in IT would be out of a job. Kurt Vonnegut once said that "the problem with the world is that everyone wants to build, and noone wants to do maintenance". I'm reminded of that quote daily working in the software industry -- the people "pushing boundaries" are a tiny minority and if they were the only ones working our modern world would come crashing down in an afternoon.
- anonymoushn 6y ago
  You can hardly expect people to talk about all the maintenance they did in their performance review
  - dolmen 6y ago
    Why? Work should be balanced between creating new code and maintaining existing code. And managers should value both.
    - anonymoushn 6y ago
      Because the company's internal rubric for performance reviews awards 0 points for this kind of work.
    - jokethrowaway 6y ago
      You answered yourself. Maintenance is seen by business as a cost, innovation is seen as potentially bringing more money. The incentives are all wrong and that translate to engineers (and teams, and companies) chasing features and not fixing bugs. A rewrite is often the only way of getting enough resources to fix up things.

de_keyboard 6y ago

I think the problem is we keep using the same crappy tools because people are scared to be an early adopter. Meanwhile, there are things sitting on the shelf that solve these problems in a principled way and make things simpler: - ML languages - Nix - Bazel - Erlang - Rust Some tools that are great and have large adoption: - Git - Terraform

b3kart 6y ago
> ML languages What are those?
- nmca 6y ago
  I suspect he means Ocaml, sml and bucklescript.
  - Multicomp 6y ago
    agreed. ML [1] is short for meta langauge. Because it is not very C-like syntax by default, it can feel exotic and alien to most of today's unix graybeards, 90s enterprise, aughts startup folks, and even the JS crowd. see also its 'newer incarnations' Scala, F#, Nemerle...(don't slay me)Rust(ish) [1] https://en.m.wikipedia.org/wiki/ML_(programming_language) https://en.m.wikipedia.org/wiki/ML_(programming_language)
  - b3kart 6y ago
    Oh, I see. Thanks!
shipp02 6y ago
I would add E[1] language to that list. [1]http://erights.org/elang/index.html http://erights.org/elang/index.html
iFreilicht 6y ago
I think Nix will take a long while to increase adoption, because it is hard to learn. The language is new, the concept is new, the mental model is new. But you need to master all of those to use the tool effectively. Same goes for the other items in your list. Git had enough time and force behind it, and I believe the other tools will succeed as well. But it will take time.

coldtea 6y ago

AlchemistCamp 6y ago

> By tooling I mean programming languages, frameworks, libraries and operating systems. All of whuch have been designed for a single machine operation with random access memory model. You should learn about Elixir (or anything on Erlang VM).

eandre 6y ago

Agreed completely. Today there's such a large disconnect between how you think about software (APIs, services, systems, data flows, replication, data storage, access patterns, and so on) and how you actually develop software, with plain text files on disk that don't at all resemble our mental model. I've been working on a new type of framework that is about making how we develop software match this mental model. Where the higher-level primitives we think in terms of are first-class citizens at the language level. I think only then is it possible to reason about, and scale, software in a much more productive and effective way.

zmmmmm 6y ago
> Today there's such a large disconnect between how you think about software (APIs, services, systems, data flows, replication, data storage, access patterns, and so on) and how you actually develop software, with plain text files on disk I view this a little differently. People have tried again and again to move the abstraction layer for coding above text files. This was happening back in the 90's (in the guise of so-called "4GLs" [0]) and still today (now rebranded as "no-code" [1]). I myself spent a good deal of effort trying to code "diagramatically" through top down UML (with an amazing product for it's time, Together). So the ambition to shift programming up the abstraction food chain has been tried continuously for 30 years and continued to fail every time. Eventually I changed my view and decided that there were fundamental reasons why higher level abstractions don't work - software is just too complex, the abstractions are too leaky. The details matter, they are critically important. We are in a long arc of figuring out the right abstractions that may take a century or more and in the meantime, we simply have to have the flexibility of text based formats to let us express the complexity we need to manage in the meantime. [0] https://en.wikipedia.org/wiki/Fourth-generation_programming_language https://en.wikipedia.org/wiki/Fourth-generation_programming_... [1] https://techcrunch.com/2020/10/26/the-no-code-generation-is-arriving/ https://techcrunch.com/2020/10/26/the-no-code-generation-is-...
- eandre 6y ago
  I don't disagree,but I think there's space for several levels of abstraction between where we are today and no-code tools.

IncRnd 6y ago

> People don't want solutions to yesterday's problems. These are considered trivial and already solved, such as invoking a shell command (which just hides a lot of complexity under the hood). Noone will pay you for invoking existing solutions. They pay you to push the boundary. People are paid to work on products which provide value to the business. There is always a Minimum Viable Product, MVP. Meet that. Exceeding that is the boundary that needs to be pushed, not grabbing the latest, possibly untested, tools off the shelf. > And random access memory model breaks down completely, because it is just a leaky abstraction. For full performance memory is only accessed linearly. Any random access structured programming language completely breaks down for working with GBs of data, in parallel and on a cluster of machines. This is why constantly re-engineering (for the purpose of engineering) is not the most useful method. I used to work in FoxPro with databases that were GBs of data. If today those GBs are difficult to handle, which they aren't, then there is a problem with how the stack was put together. GBs are trivial.

joe_the_user 6y ago

To put is cynically, everyone knows that yesterday's tools don't work. So it's better to try today's tools, which you don't yet know don't work. This allows one poorly thought out idea to replace another - especially when selling new stuff is profitable. That said, it's implausible that the main problem is scaling since mainframes scaled considerable data quite a while back.