Was "accidental" and "essential" supposed to be swapped in this line?
... techniques like version control and software testing have done wonders for turning the essential into accidental.
I get confused because I thought we wanted to get rid of accidental complexity and preferred to focus on dealing with the essential stuff... but we dont want get rid of version control nor testing?
I read that as meaning: tracking changes and dealing with bugs was "essential complexity" in software development, back in Brooks' day, but now they're "solved problems" so if you're not using version control or automated testing, then you have unnecessary complexity in your dev workflow -- therefore it is now "accidental complexity" that you could avoid.
Sean is right. My idea was that what looks like essential look accidental after an improvement is found. Hindsight is 20/20.
For example, Brooks mentions that conceiving of the data structures and their relationships was an essential task--it's just part of the job. But in the context of the projects he was referring to, what he meant by data structures was a detailed account of the layout of memory and the algorithms that will walk the pointers, etc. Data structures were customized for every job.
Nowadays, 99% of the time we just use the built-in data structures. There were advances in generic data structures available in the standard libraries. But also our CPUs and memories are millions of times more powerful than what they had, so we can afford to use suboptimal, generic data structures most of the time.
So what seemed to be essential has now become accidental, then solved away by the standard library. Brooks couldn't see that that was possible from his perspective. And we likely have similar blindspots.
A question I like to ask myself is "What are some ways I can 'waste' CPU and memory on a problem?" It's useful for getting ideas for problems that seem essential that are really not.
Was "accidental" and "essential" supposed to be swapped in this line?
... techniques like version control and software testing have done wonders for turning the essential into accidental.
I get confused because I thought we wanted to get rid of accidental complexity and preferred to focus on dealing with the essential stuff... but we dont want get rid of version control nor testing?
I read that as meaning: tracking changes and dealing with bugs was "essential complexity" in software development, back in Brooks' day, but now they're "solved problems" so if you're not using version control or automated testing, then you have unnecessary complexity in your dev workflow -- therefore it is now "accidental complexity" that you could avoid.
Sean is right. My idea was that what looks like essential look accidental after an improvement is found. Hindsight is 20/20.
For example, Brooks mentions that conceiving of the data structures and their relationships was an essential task--it's just part of the job. But in the context of the projects he was referring to, what he meant by data structures was a detailed account of the layout of memory and the algorithms that will walk the pointers, etc. Data structures were customized for every job.
Nowadays, 99% of the time we just use the built-in data structures. There were advances in generic data structures available in the standard libraries. But also our CPUs and memories are millions of times more powerful than what they had, so we can afford to use suboptimal, generic data structures most of the time.
So what seemed to be essential has now become accidental, then solved away by the standard library. Brooks couldn't see that that was possible from his perspective. And we likely have similar blindspots.
A question I like to ask myself is "What are some ways I can 'waste' CPU and memory on a problem?" It's useful for getting ideas for problems that seem essential that are really not.