Hacker News Reader

While true, NIH can apply to a lot of things including hardware. But why especially software? A lot probably has to do with the fact that many/most people will recognize that rebooting a hardware design is going to be a lot of work and take a long time. Whereas with software, there's more of a temptation to think it's "just a matter of programming" and "how hard can it be?" even by people who should know better.

View on HN

My theory: Hardware and hardware tooling has tangible capital costs. Most people are acutely aware of what they've spent on hardware, so discarding it can be quite painful. Estimating is hard and many devs are terrible at accounting for their time. A rewrite is often underestimated (people always seem to forget about testing--they especially seem to forget how much time they spent manually testing to get to a working state) so the costs of writing software aren't as visible. In my experience, good, seasoned devs feel just as bad about discarding software as they do hardware.

Edit because I posted while running out the door and probably could have explained better: Elsewhere in this thread, dmckeon linked to Spolsky's article on why rewrites are bad. This does a better job than I did of explaining the hidden costs of a software rewrite. In my experience, these costs are rarely tallied up and written down such that they're as visible as, for example, the $50K one spent on creating an injection molding tool, or the millions spent in NRE and component purchases to get an assembly line running. Or even the few thousands spent on a prototype PCBA. In hardware, these capital cost numbers are always in your face. So, even though hardware devs are as bad as software devs in estimating time and accounting for testing, the capital costs provide a built-in, visible incentive to avoid unnecessarily discarding work.

Reply on news.ycombinator.com