# Thoughts from [[2025]] - doesn't really define the Essential vs Accident complexity well. - https://danluu.com/essential-complexity/ - dan luu's article defines it quite well; # On Accidental Complexity The heavily underestimates how much of the software engineering is accidental complexity. [[Fred Brooks]] gave the factor of 2 (50%). It's a difficult argument to make; I believe that we develop software at much faster pace (Maybe even 10x, including the development in [[Package Manager]]s), but it would be an unrealistic polemic to argue that the "accidental complexity" is 90% (factor of 10) in 1986. Some problems (and solutions) do not rise unless there's scale; we expect much more from the modern software (see [[Software Complexity]]); and i believe that we can make an argument similar to drag being quadratic; accidental complexity is nonlinear with respect to the codebase, requirement complexity, and also the speed of iteration we want to achieve. The software today is much larger than before; and much more ambiguous than before, too. We expect a lot more, such as rapid iteration. We expect to ship our software multiple times a day (if everything else permits us to do so). It is possible that the factor of 2 is what Brooks saw at the current status quo; but looking back, it’s clear that we had much larger factor of improvement since then till now. Operating a software (with no software-admin distinction anymore) is very different too, with even more scope bestowed upon software engineering. These were all *unaccounted* accidental complexity when Brooks proposed the 50% accidental complexity number. However, the concept of the [[Essential vs Accidental Complexity]] is useful; the learnings are: 1. there's a bit of "creative accounting" going on in the middle; the large "gray area" where one can account as either essential or accounting. 2. [[Code-State Dichotomy|Stateful Software]] - software works against the "baggage" of the past. > [!thought] > While reading [[A Philosophy of Software Design]], i realized that essential vs accidental complexity is not covering [[Software Complexity]] %%BEGIN_CONTENT%% # [Brooks 1986 no silver bullet](https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf) ## Highlights > [!quote] [[2025-09-14]] > How much of what software > engineers now do is still devoted to the accidental, as opposed to the essential? Unless it > is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not > give an order of magnitude improvement. > [!quote] [[2025-09-15]] > Not only are there no silver bullets now in view, the very nature of software makes it > unlikely that there will be any > − > no inventions that will do for software productivity, > reliability, and simplicity what electronics, transistors, and large-scale integration did for > computer hardware. We cannot expect ever to see twofold gains every two years. > [!quote] [[2025-09-15]] > 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. > [!quote] [[2025-09-15]] > Changeability. The software entity is constantly subject to pressures for change. > [!quote] [[2025-09-15]] > for > it is the philosophy of modularization, of abstract data types, of hierarchical structuring. > [!quote] [[2025-09-15]] > Nevertheless, such advances can do no more than to remove all the accidental > difficulties from the expression of the design. The complexity of the design itself is > essential; and such attacks make no change whatever in that %%END_CONTENT%%