Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I expected it to boil down to the thesis that programming is hard to improve because the complexity that makes it hard is essential, not accidental.

https://web.archive.org/web/20160910002130/http://worrydream...

Surprised that the piece was all focused on the accidental complexity.



I'm think (?) the author's point is that an immense amount of value is inextricably tied up with what appears to be "accidental complexity."

From the article:

> The legacy is the value, it can’t be thrown out.

I agree the author presents this in a bit of a confusing fashion, since the immediately preceding sentence is

> the ideas are what hold the real value.


From experience, I think this is absolutely true.

One of the reasons for the 80/20 rule, specifically that it takes 20% of the time to make 80% of the product and the remaining 80% of the time to make the remaining 20% of the product, is that we perceive most of the accidental complexity to be in that final 20%: technical debt, localization edge cases, bugs, misuses that turn our products into spying tools, etc.

I think that accidental complexity isn't a software paradigm limitation. It's a human thought limitation. It takes time for human organizations to learn how to handle the inevitable yet unanticipated issues and exceptions to the rule, and it takes time to turn them into processes and then to automate them.


The ecosystem delivers a lot of pre-packaged essential complexity - e.g. only now Rust is starting to get the mature libraries to handle difficult domain-specific things. It is hard to program from scratch (no pun intended)




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

Search: