He basically splits the complexity of programming into two categories: accidental complexity and essential complexity. The accidental complexity you can fix, it’s the difficulty caused by tooling, programming languages, etc. The essential complexity, that is: the complexity caused by the problem your program is trying to solve, cannot be fixed. To quote the man:
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.
I don’t think it is - and I’m not saying that because I think I’m good, it’s because programming is just a different way of thinking
This different way of thinking is something that some people simply will never get, or not at the right level. I’m certainly not a great programmer but I know from experience I’m above average. I know a lot of programmers that simply cannot grasp things above a certain level of abstraction. These are college-educated programmers with years of experience. The easiest way to tell is that bad programmers turn simple problems into complicated code, and good programmers turn complicated problems into simple code.
Nice quote - but I don’t think it does hold up as truly as it did in the 80s. There is an unimaginable wealth of systems and design tools available now that were not around then. Even something take for granted like a gui schema designer - hell, even SQL itself wouldn’t be around until almost a decade later, and that was partly designed to simplify database queries. Every step like that has simplified what we do today. Debugging tools are light years ahead of when I was writing C in the early 90s. Debugging then was pretty much “try and compile it and then fix the errors”. Now there’s linters, memory profilers, automatic pipelines and all the rest of that. Much of that is offset by the fact we do far more complicated things than we did, and that those very tools mean there’s a lot more to learn and master beyond the mere language.
I do concede and agree with your last paragraph. Design is more important than implementation, and elegance of code and concept is a timeless beauty. One of the hardest things I’ve had to learn is that thinking about coding is often far more productive than actually coding, and too many times I’ve been a busy fool, re-writing and starting over many times because I later found out a better way.
All those tools you mention would fall under the accidental complexity header. There have been many advances in that field. But none of those tools reduce the essential complexity. SQL doesn’t mean you don’t have to think about how you organize your data. You still need to think about things like normalization. Even ORM doesn’t free you from this.
Same goes for debuggers, sure it’s easier to inspect code at runtime but that doesn’t help you design good code.
You can reduce this accidental complexity but in the end there is always the core of the essential complexity. The difference with past decades is that for a simple program the accidental complexity would be a huge part of the total complexity, so in that regard you’re right. It has become a lot easier to write trivial programs where the essential complexity is very low.
This may apply to a lot of hobby-level / beginner projects, but in the end it doesn’t have as much an impact on what we do as professionals. As you said, I spend a lot more time thinking about coding than actually writing code. Especially as I got older and more experienced. As a senior developer I write a fraction of the code I did as a junior, but I’m working on more complicated problems as well.
You can easily find ‘No Silver Bullet’ online http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
He basically splits the complexity of programming into two categories: accidental complexity and essential complexity. The accidental complexity you can fix, it’s the difficulty caused by tooling, programming languages, etc. The essential complexity, that is: the complexity caused by the problem your program is trying to solve, cannot be fixed. To quote the man:
This different way of thinking is something that some people simply will never get, or not at the right level. I’m certainly not a great programmer but I know from experience I’m above average. I know a lot of programmers that simply cannot grasp things above a certain level of abstraction. These are college-educated programmers with years of experience. The easiest way to tell is that bad programmers turn simple problems into complicated code, and good programmers turn complicated problems into simple code.
Nice quote - but I don’t think it does hold up as truly as it did in the 80s. There is an unimaginable wealth of systems and design tools available now that were not around then. Even something take for granted like a gui schema designer - hell, even SQL itself wouldn’t be around until almost a decade later, and that was partly designed to simplify database queries. Every step like that has simplified what we do today. Debugging tools are light years ahead of when I was writing C in the early 90s. Debugging then was pretty much “try and compile it and then fix the errors”. Now there’s linters, memory profilers, automatic pipelines and all the rest of that. Much of that is offset by the fact we do far more complicated things than we did, and that those very tools mean there’s a lot more to learn and master beyond the mere language.
I do concede and agree with your last paragraph. Design is more important than implementation, and elegance of code and concept is a timeless beauty. One of the hardest things I’ve had to learn is that thinking about coding is often far more productive than actually coding, and too many times I’ve been a busy fool, re-writing and starting over many times because I later found out a better way.
All those tools you mention would fall under the accidental complexity header. There have been many advances in that field. But none of those tools reduce the essential complexity. SQL doesn’t mean you don’t have to think about how you organize your data. You still need to think about things like normalization. Even ORM doesn’t free you from this.
Same goes for debuggers, sure it’s easier to inspect code at runtime but that doesn’t help you design good code.
You can reduce this accidental complexity but in the end there is always the core of the essential complexity. The difference with past decades is that for a simple program the accidental complexity would be a huge part of the total complexity, so in that regard you’re right. It has become a lot easier to write trivial programs where the essential complexity is very low.
This may apply to a lot of hobby-level / beginner projects, but in the end it doesn’t have as much an impact on what we do as professionals. As you said, I spend a lot more time thinking about coding than actually writing code. Especially as I got older and more experienced. As a senior developer I write a fraction of the code I did as a junior, but I’m working on more complicated problems as well.