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

Overengineering confessions. He that is without sin among you, let him cast the first stone at her.

There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously.

We don’t really have good measurements for - and often overlook those aspects - which causes us collectively to suffer only after a great commitment of time and labor. I’m pretty convinced that complexity isn’t just mentally confusing but actually hard measurable, as long as we have language to describe it and a well tuned skepticism towards unnecessary layers of indirection. Function coloring is one such attempt, imo, at explaining the great costs of something which looks innocent.



Good abstraction is the foundation for most of what we do. Bad abstraction is worse than no abstraction. Not everything needs to be abstracted. Ontology is bad abstraction (is a has a stuff). Some people are bad at abstraction and some people are bad at writing business code; Both can be good coders.


> Ontology is bad abstraction (is a has a stuff).

Is “can do X” included in that definition (ie are you alluding to composition vs inheritance)? Can you elaborate on what constitutes good abstraction, in your book?




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

Search: