#2 is a big one. If there's one HN ethos that I disagree with, it's the idea that a better engineered solution is always a better solution (full stop). Unless you have infinite time and developers, that's not true.
A better engineered solution is always a better solution. What he is describing is over-engineering.
I am failing to remember who said: the perfect racing car falls apart the moment it crosses the finishing line - all others else are over-engineered. The point is that good engineering is appropriate engineering. All the things that PHBs sometimes think off as the geeks going off on their own obsessions - maintainability, clarity of design, low fault tolerance, high scaling ability - these are either good engineering or over-engineering depending on the stage of the lifecycle, the purpose of the project (air traffic control systems anyone?), the future staffing estimates and so on.
For example in my own area of acedemic-(ish) software engineering, maintainability absolutely trumps delivery dates. Clearly, if you are chasing ramen profitability, it may not.
I am failing to remember who said: the perfect racing car falls apart the moment it crosses the finishing line - all others else are over-engineered. The point is that good engineering is appropriate engineering. All the things that PHBs sometimes think off as the geeks going off on their own obsessions - maintainability, clarity of design, low fault tolerance, high scaling ability - these are either good engineering or over-engineering depending on the stage of the lifecycle, the purpose of the project (air traffic control systems anyone?), the future staffing estimates and so on.
For example in my own area of acedemic-(ish) software engineering, maintainability absolutely trumps delivery dates. Clearly, if you are chasing ramen profitability, it may not.
Context matters.