Hacker News Reader

Comment by jasim | Hacker News Reader

Correctness and robustness happen to all software, when exposed to end-users for a long enough time.

Internally the software would be a ball of mud, a fragile patchwork of incoherent code that nobody wants to touch. A lot of these programs become immutable logs - if you want to change a feature, you add more code because you're afraid to touch anything that already exist.

Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out, and from outside the software looks like an impenetrable, rugged piece of craftsmanship. This has happened to me in the early years of my career (proud of the robustness, not proud of the code), and I've witnessed it so many times outside. So yeah - robustness and correctness is either a matter of correct-by-construction, or correct-over-time.

View on HN

> Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out

There are two ways this can be true: if the code paths users traffic are debugged, and if users only traffic code paths that are not buggy. In the end, all and only the code paths that are used are useful. Isn't that a truism?

Like I said, I feel this perspective (and thank you for responding!). But I'm kind of sick of working on codebases that are absolutely littered with dead code paths that are hopelessly interwoven with live code paths, to the point that when you know you're breaking something, you hope you're only breaking something that isn't used. To me, it's a really depressing, fatalistic worldview.

> A lot of these programs become immutable logs - if you want to change a feature, you add more code because you're afraid to touch anything that already exist.

Amen to that. Can we as an industry find ways to do this better in the first place, instead of resigning ourselves to "immutable log" as an inevitability?

I'm naive, but I think the adoption of Typed FP, and the resulting cultural education and change, is one route to solving this problem. But it is a social and economic problem more than anything else. Or I guess - since the spectrum of competence in other fields of human endeavor is distributed widely (a bell curve?), we'll have to expect it to happen to software as well. Not a very optimistic thought, but at least we can be content with what we have :)

> Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out, and from outside the software looks like an impenetrable, rugged piece of craftsmanship.

I disagree. I think they only feel robust. I think more importantly this mode of development is defensible and always gives one something concrete in the case of being asked "so what's the product of this 3 days of work?".

Reply on news.ycombinator.com