4 ms·

I completely disagree that it's obvious to a skilled developer which parts are accidental/essential. Programmers (and everyone else) often don't realize they ha

by Peaker 14y ago

I completely disagree that it's obvious to a skilled developer which parts are accidental/essential. Programmers (and everyone else) often don't realize they have a problem or are missing something until someone solves it for them. Similarly, programmers implement the exact same concepts over and over, and many of them don't even realize all of the things they're implementing are specializations of general patterns. As for past silver bullets, the move from assembly language to C along with some extra tooling was easily an order of magnitude difference in development speed.

parasubvert 14y ago
So, what I think you're suggesting is that a developer wouldn't understand accidental/essential complexity differences until a more skilled developer figured out the essence of certain classes of problems and others learned to apply their experience. But, isn't that the case with any domain built on knowledge? My point was that a skilled developer had learned much the state of the art knowledge up to this point, and understands the pitfalls over over-complicating a solution that one can get into with certain solutions of the problem. Brooks' paper wasn't even getting deeply into what we are talking about, he was just suggesting that software development is inherently complicated, that it's always going to be hard, because unlike Newtonian physics, you can't wave away the complexities and distill the essence of a problem into simple equations. The complexities ARE the software. Abstractions, though helpful, are flawed and leaky, unless they're designed by a master. If software development is a fundamentally hard activity, like playing a musical instrument well, you're not likely going to make it a "breakthrough" with a piece of technology, you're going to improve it with better programmers. A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive. Back in the 80's, this was bitter medicine that management types had to hear, thinking that programming was rote activity with barely any need for higher pay or recognition of the 10:1 or more disparity in productivity among individuals.
- Peaker 14y ago
  > A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive. I'm not sure about that, especially if you replace COBOL with assembly language. Definitely if you replace COBOL with machine code encodings, or punch cards. Part of the disparity amongst individual programmers can be attributed to tooling, and we have no way of knowing how much that is. I think we can agree the paper is saying: "Programming is inherently complicated, and we predict that our current tools already reduce complexity almost as much as possible". I just disagree with that prediction, and think our tools currently encompass massive amounts of accidental complexity which easily dwarf the essential complexity.

by Peaker 14y ago

parasubvert 14y ago

So, what I think you're suggesting is that a developer wouldn't understand accidental/essential complexity differences until a more skilled developer figured out the essence of certain classes of problems and others learned to apply their experience. But, isn't that the case with any domain built on knowledge? My point was that a skilled developer had learned much the state of the art knowledge up to this point, and understands the pitfalls over over-complicating a solution that one can get into with certain solutions of the problem. Brooks' paper wasn't even getting deeply into what we are talking about, he was just suggesting that software development is inherently complicated, that it's always going to be hard, because unlike Newtonian physics, you can't wave away the complexities and distill the essence of a problem into simple equations. The complexities ARE the software. Abstractions, though helpful, are flawed and leaky, unless they're designed by a master. If software development is a fundamentally hard activity, like playing a musical instrument well, you're not likely going to make it a "breakthrough" with a piece of technology, you're going to improve it with better programmers. A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive. Back in the 80's, this was bitter medicine that management types had to hear, thinking that programming was rote activity with barely any need for higher pay or recognition of the 10:1 or more disparity in productivity among individuals.

Peaker 14y ago
> A highly talented programmer will be less productive using COBOL and older tools and technologies, but will not be an order of magnitude less productive. I'm not sure about that, especially if you replace COBOL with assembly language. Definitely if you replace COBOL with machine code encodings, or punch cards. Part of the disparity amongst individual programmers can be attributed to tooling, and we have no way of knowing how much that is. I think we can agree the paper is saying: "Programming is inherently complicated, and we predict that our current tools already reduce complexity almost as much as possible". I just disagree with that prediction, and think our tools currently encompass massive amounts of accidental complexity which easily dwarf the essential complexity.