3 ms·

I'm in Brooks' camp. I see mostly essential complexity. There are problems we've been pounding on for a decade that have solutions that are mostly essential c

I'm in Brooks' camp. I see mostly essential complexity. There are problems we've been pounding on for a decade that have solutions that are mostly essential complexity. Then people come in and create pointless requirements that turn that fairly simple essential complexity... extremely complex. I think the modern problem isn't accidental complexity, it's essential complexity that isn't actually necessary for project success.

geofft 7y ago
Another way of looking at this argument is that the majority of hard problems in software engineering aren't computer science problems, they're people management problems. It's not merely enough to create a programming language with an order-of-magnitude improvement in productivity, you also need to convince all the stakeholders to let the project be developed in that programming language, which includes both helping them get over their unfounded fears ("it won't work") and doing the technical work (or the recursive people work) to get them over their well-founded fears ("how will we hire/train programmers," "what do we do with all our existing code in this other language," "is there a vibrant language ecosystem," "where's the development tooling," etc.). Same applies to other sorts of possible silver bullets. The Linux kernel has been using git for well over a decade, but even GCC (a free software project which has no managers adding requirements to make themselves look good) only switched to git last week. In other words, if you have a 10x technical silver bullet against accidental complexity, it won't look like a silver bullet / it'll appear to get stopped at essential complexity until you do the people work too. Without that, you won't be able to point at very many projects that have actually seen the 10x improvement.
coldtea 7y ago
>There are problems we've been pounding on for a decade that have solutions that are mostly essential complexity. Then people come in and create pointless requirements that turn that fairly simple essential complexity... extremely complex. I think the modern problem isn't accidental complexity, it's essential complexity that isn't actually necessary for project success. That would be a third category of complexity. Essential complexity Accidental complexity and the a new one: Complexity-imposed-as-"essential"-by-marketing-customer-etc. Let's call it Requirements-Complexity
- wool_gather 7y ago
  In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. You can't escape the business logic that needs to be enabled. It's like the old service industry joke "this job would be great...if it weren't for all the customers". There would be no software if there weren't a set of requirements.
  - coldtea 7y ago
    >In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. It's not that clear cut. For me "Essential" is what captures the essence of the problem domain and the requirements in actual use. On top of that, there are lots of "requirements" that are there due to bribes, idiotic "brainstorming" where everyone felt obliged to chime in, what the CEO's spouse things should certainly be there, recent fads, over-thinking it from some execs, etc. The distinction between the "essential" is of utmost importance. First, because these "required but not essential" area is where an engineer can look for tradeoffs (to the benefit of essential areas). Second, because those items might hamper the essential functionality (like a requirement to build a website in C, because the CEO heard "it's the fastest language", can hurt security, maintainability and other aspects, or the requirement to make a banking webpage with small fancy grey on white fonts because they though the design is "cool" hurts readability). Third, because engineers should not just operate on a "follow orders" basis. They also have an ethical responsibility towards the final users (society at large for public software, customers, the customer's employees, etc). And, of course, because not being able to make that distinction, means that the engineer can't tell good from bad, useful for useless, and it's all the same to them. Whether they can convince the customer it's another thing. But engineers should absolutely be able to make the distinction. >There would be no software if there weren't a set of requirements. Which is neither here, nor there. There would also be a hell of a lot of better, faster, more reliable software, if bogus requirements would get pointed out, and removed.
hinkley 7y ago
I see accidental complexity every time I step the debugger into library code. That’s where it’s hiding. In the internal and external impedance mismatches of library code. I had to step into papi the other day. Most Node libraries for http have been designed by someone who loathes code duplication so much that they don’t care if the user-baby goes out with the code duplication bathwater. I pray for a day where code is measured not by lines of code or code coverage but by call stack metrics.

geofft 7y ago

Another way of looking at this argument is that the majority of hard problems in software engineering aren't computer science problems, they're people management problems. It's not merely enough to create a programming language with an order-of-magnitude improvement in productivity, you also need to convince all the stakeholders to let the project be developed in that programming language, which includes both helping them get over their unfounded fears ("it won't work") and doing the technical work (or the recursive people work) to get them over their well-founded fears ("how will we hire/train programmers," "what do we do with all our existing code in this other language," "is there a vibrant language ecosystem," "where's the development tooling," etc.). Same applies to other sorts of possible silver bullets. The Linux kernel has been using git for well over a decade, but even GCC (a free software project which has no managers adding requirements to make themselves look good) only switched to git last week. In other words, if you have a 10x technical silver bullet against accidental complexity, it won't look like a silver bullet / it'll appear to get stopped at essential complexity until you do the people work too. Without that, you won't be able to point at very many projects that have actually seen the 10x improvement.

coldtea 7y ago

>There are problems we've been pounding on for a decade that have solutions that are mostly essential complexity. Then people come in and create pointless requirements that turn that fairly simple essential complexity... extremely complex. I think the modern problem isn't accidental complexity, it's essential complexity that isn't actually necessary for project success. That would be a third category of complexity. Essential complexity Accidental complexity and the a new one: Complexity-imposed-as-"essential"-by-marketing-customer-etc. Let's call it Requirements-Complexity

wool_gather 7y ago
In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. You can't escape the business logic that needs to be enabled. It's like the old service industry joke "this job would be great...if it weren't for all the customers". There would be no software if there weren't a set of requirements.
- coldtea 7y ago
  >In the context of any given project, that's, if anything, a subcategory of Essential. The software is a tool to do something, and the functional requirements are what define the purpose of embarking on the project. It's not that clear cut. For me "Essential" is what captures the essence of the problem domain and the requirements in actual use. On top of that, there are lots of "requirements" that are there due to bribes, idiotic "brainstorming" where everyone felt obliged to chime in, what the CEO's spouse things should certainly be there, recent fads, over-thinking it from some execs, etc. The distinction between the "essential" is of utmost importance. First, because these "required but not essential" area is where an engineer can look for tradeoffs (to the benefit of essential areas). Second, because those items might hamper the essential functionality (like a requirement to build a website in C, because the CEO heard "it's the fastest language", can hurt security, maintainability and other aspects, or the requirement to make a banking webpage with small fancy grey on white fonts because they though the design is "cool" hurts readability). Third, because engineers should not just operate on a "follow orders" basis. They also have an ethical responsibility towards the final users (society at large for public software, customers, the customer's employees, etc). And, of course, because not being able to make that distinction, means that the engineer can't tell good from bad, useful for useless, and it's all the same to them. Whether they can convince the customer it's another thing. But engineers should absolutely be able to make the distinction. >There would be no software if there weren't a set of requirements. Which is neither here, nor there. There would also be a hell of a lot of better, faster, more reliable software, if bogus requirements would get pointed out, and removed.

hinkley 7y ago

I see accidental complexity every time I step the debugger into library code. That’s where it’s hiding. In the internal and external impedance mismatches of library code. I had to step into papi the other day. Most Node libraries for http have been designed by someone who loathes code duplication so much that they don’t care if the user-baby goes out with the code duplication bathwater. I pray for a day where code is measured not by lines of code or code coverage but by call stack metrics.