Hacker News new | past | comments | ask | show | jobs | submit login

> Even though Fred Brooks explained why in 1986. There are essential tasks and there are accidental tasks. The tools really only help with the accidental tasks.

I don't know this reference, so I have to ask: Was "accidental" supposed to be "incidental"? Because I don't see how "accidental" makes any sense.




The Mythical Man-Month, by Fred Brooks.

Chapter 16 is named "No Silver Bullet—Essence and Accident in Software Engineering."

I'll type out the beginning of the abstract at the beginning of the chapter here:

"All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. 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."


From the abstract that definitely sounds like he meant "incidental": Something that's a necessary consequence of previous work and / or the necessary but simpler part of the work.


It's Aristotelian language. Accidental means a feature which isn't constitutive (of the activity).


Brooks makes reference to this at some point in a later edition of the book, and about the confusion the word choice caused.

By accidental, he means "non-fundamental complexity". If you express a simple idea in a complex way, the accidental complexity of what you said will be high, because what you said was complex. But the essential complexity is low, because the idea is simple.

Anniversary edition, p182.

"... let us examine its difficulties. Following Aristotle, I divide them into essence - the difficulties inherent in the nature of the software - and accidents - those difficulties that today attends its production but that are not inherent"


I wonder why people no longer write technical books with this level of erudition and insight; all I see is "React for dummies" and "Mastering AI in Python" stuff (which are useful things, but not timeless)


You have to look at fundamental books to get there like Designing Data-Intensive Applications or Software Development Pearls (Karl Wiegers)


Because, let's be fair, most of us STEM people are no longer educated in the classics the way some were 50 years ago.


I'm actually writing a book right now, Effective Visualization, and I'll explain why. It is a book focused on Matplotlib and Pandas.

I have almost a dozen viz books. Some written over 50 years ago.

While they impart knowledge, I want the knowledge but also the application. I'm going to go out and paint that bike shed. You can go read Tufte or "Show me the Numbers" but I will show you how to get the results.


> I don't know this reference

Right there is your problem. Read the Mythical Man-Month and Design of Design. They are not long books and it's material that's hard to find elsewhere. Old rat tacit knowledge.


It comes from philosophy: essential vs accidental.

https://plato.stanford.edu/entries/essential-accidental/


Buy and read the book. There is a reason the 25th aniversery eddition has been still in print for more than 30 years. It is a timeless combuter book that everyone should read and keep an their bookshelf.


"Accident" in the same sense as "accident of birth" not "traffic accident".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: