4 ms·

One thing he got very, very wrong: technological advances -- faster computers, better languages, better compilers, better editors -- have blown programmer produ

by ncmncm 4y ago

One thing he got very, very wrong: technological advances -- faster computers, better languages, better compilers, better editors -- have blown programmer productivity through the roof. Another is that "object-oriented" programming turned out not to be very important, and rather a distraction.

the_af 4y ago
I think you're being unfair. Brooks did mention those kinds of advances, he just didn't consider them magical. For example, from Wikipedia's summary (which aligns with what I remember from my own reading): > "While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant improvements. One technology that had made significant improvement in the area of accidental complexity was the invention of high-level programming languages, such as Ada." The core of "essential" vs "accidental" complexity remains very insightful. If, like Brooks argues, we are mostly hitting essential complexity now, no single programming language or IDE is going to provide a radically large improvement anymore. "Productivity" is a tricky beast. What does it even mean? Programmers typing fast and getting code into production quickly? But what about the success and correctness of the systems they write? What about bugs and performance problems? What about incorrect or misunderstood requirements? Have we solved those?
- taffer 4y ago
  > like Brooks argues, we are mostly hitting essential complexity now I'm a bit skeptical about this. If you look at random backend code, you'll find lots of boilerplate, control structures, error handling, dealing with different data structures, performance optimizations. All of that I would consider random complexity. All of that is there only because computers can't figure these things out on their own.
  - beckingz 4y ago
    control structures and error handling sound like essential complexity to me, as that's effectively business logic / system requirements.
    - taffer 4y ago
      I might agree that error handling is business logic in the broadest sense, but control structures certainly are not. Unless there is an explicit business requirement like "use a nested for loop to iterate through an employee array", control structures are just implementation details.
      - the_af 4y ago
        The logic being expressed by the control structure is essential complexity though. There are better and worse ways to go about it, i.e. "accidental" complexity, but the core logic is irreducible.
  - the_af 4y ago
    Control structures as in "business logic" is essential complexity to me. Random spaghetti code and boilerplate isn't, but Brooks' argument is that improving this, while definitely a good thing to strive for, won't result in a huge improvement in productivity, because the major roadblocks lie elsewhere. I don't think he is arguing against minor wins, either. He just says we must focus on the major ones.
    - marcosdumay 4y ago
      If you go into backend code from the typical place where "backend code" is a thing, it can be derived completely mechanically from the frontend. So all the work that goes into it is accidental, for a start. Often that relation goes both ways, and the frontend code (that is even more complex) can be derived from the backend too. That doesn't look very minor to me.
      - the_af 4y ago
        That's boilerplate code and I agree it can be completely automated. I would argue it's a very convenient but minor thing, and that it doesn't truly change the complexity of writing code. It just makes it less dreary. I would also argue it's a win that it can be automated, and I think Brooks would agree! I don't think he was arguing small wins don't matter.
        Too 4y ago
        Boilerplate in itself is not complexity (eg import statements), it’s just tedious and unergonomic. In fact it can reduce complexity, again with example of imports being a better alternative than global symbols. Coupled boilerplate on the other hand is complexity, where if you change x in front end you also must change corresponding x in backend.
        the_af 4y ago
        You're using a very specific notion of boilerplate and complexity. I mean, I've never heard of imports being described as boilerplate...
- ncmncm 4y ago
  It is, exactly, the distinction between accidental and essential complexity that has not panned out. Productivity is about getting solutions successfully deployed to production. Things that interfere with that may be "essential" or "accidental", but the distinction turns out not to matter much. One of Dan Luu's better essays covered this.
  - the_af 4y ago
    > Things that interfere with that may be "essential" or "accidental", but the distinction turns out not to matter much. I obviously disagree. I think it matters a lot, especially because it allows us to detect that trap programmers and hackers often fall prey to: hyperfocusing on minor technical details because they are cool to think about without regards to the actual gains. That's not to deny a lot of improvements in the past decades actually made programmers' quality of life tremendously better. Dan Luu is a very interesting essayist and I find myself nodding in agreement with a lot of what he writes. He's made it his business to go against the grain of most "universally held truths" (a great chunk of his essays are about debunking commonly held beliefs about tech and science), but in doing so I think he tends to overstate his case. In this case, I think he is right but also overstating his case, and Brooks remains as relevant as ever. Luu's 2022 addendum is interesting, because it certainly cuts both ways -- not just in the way Luu would want!

by ncmncm 4y ago

the_af 4y ago

I think you're being unfair. Brooks did mention those kinds of advances, he just didn't consider them magical. For example, from Wikipedia's summary (which aligns with what I remember from my own reading): > "While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant improvements. One technology that had made significant improvement in the area of accidental complexity was the invention of high-level programming languages, such as Ada." The core of "essential" vs "accidental" complexity remains very insightful. If, like Brooks argues, we are mostly hitting essential complexity now, no single programming language or IDE is going to provide a radically large improvement anymore. "Productivity" is a tricky beast. What does it even mean? Programmers typing fast and getting code into production quickly? But what about the success and correctness of the systems they write? What about bugs and performance problems? What about incorrect or misunderstood requirements? Have we solved those?

taffer 4y ago
> like Brooks argues, we are mostly hitting essential complexity now I'm a bit skeptical about this. If you look at random backend code, you'll find lots of boilerplate, control structures, error handling, dealing with different data structures, performance optimizations. All of that I would consider random complexity. All of that is there only because computers can't figure these things out on their own.
- beckingz 4y ago
  control structures and error handling sound like essential complexity to me, as that's effectively business logic / system requirements.
  - taffer 4y ago
    I might agree that error handling is business logic in the broadest sense, but control structures certainly are not. Unless there is an explicit business requirement like "use a nested for loop to iterate through an employee array", control structures are just implementation details.
    - the_af 4y ago
      The logic being expressed by the control structure is essential complexity though. There are better and worse ways to go about it, i.e. "accidental" complexity, but the core logic is irreducible.
- the_af 4y ago
  Control structures as in "business logic" is essential complexity to me. Random spaghetti code and boilerplate isn't, but Brooks' argument is that improving this, while definitely a good thing to strive for, won't result in a huge improvement in productivity, because the major roadblocks lie elsewhere. I don't think he is arguing against minor wins, either. He just says we must focus on the major ones.
  - marcosdumay 4y ago
    If you go into backend code from the typical place where "backend code" is a thing, it can be derived completely mechanically from the frontend. So all the work that goes into it is accidental, for a start. Often that relation goes both ways, and the frontend code (that is even more complex) can be derived from the backend too. That doesn't look very minor to me.
    - the_af 4y ago
      That's boilerplate code and I agree it can be completely automated. I would argue it's a very convenient but minor thing, and that it doesn't truly change the complexity of writing code. It just makes it less dreary. I would also argue it's a win that it can be automated, and I think Brooks would agree! I don't think he was arguing small wins don't matter.
      - Too 4y ago
        Boilerplate in itself is not complexity (eg import statements), it’s just tedious and unergonomic. In fact it can reduce complexity, again with example of imports being a better alternative than global symbols. Coupled boilerplate on the other hand is complexity, where if you change x in front end you also must change corresponding x in backend.
        the_af 4y ago
        You're using a very specific notion of boilerplate and complexity. I mean, I've never heard of imports being described as boilerplate...
ncmncm 4y ago
It is, exactly, the distinction between accidental and essential complexity that has not panned out. Productivity is about getting solutions successfully deployed to production. Things that interfere with that may be "essential" or "accidental", but the distinction turns out not to matter much. One of Dan Luu's better essays covered this.
- the_af 4y ago
  > Things that interfere with that may be "essential" or "accidental", but the distinction turns out not to matter much. I obviously disagree. I think it matters a lot, especially because it allows us to detect that trap programmers and hackers often fall prey to: hyperfocusing on minor technical details because they are cool to think about without regards to the actual gains. That's not to deny a lot of improvements in the past decades actually made programmers' quality of life tremendously better. Dan Luu is a very interesting essayist and I find myself nodding in agreement with a lot of what he writes. He's made it his business to go against the grain of most "universally held truths" (a great chunk of his essays are about debunking commonly held beliefs about tech and science), but in doing so I think he tends to overstate his case. In this case, I think he is right but also overstating his case, and Brooks remains as relevant as ever. Luu's 2022 addendum is interesting, because it certainly cuts both ways -- not just in the way Luu would want!