Hacker News Reader

Comment by gcanyon | Hacker News Reader

I think Kay's complaint about engineering rigor ignores the explosive growth of programming. Sure, bridge-builders have rigor; there's also probably about the same number of them today as there were 50 years ago.

The number of programmers has grown by at least two, maybe three orders of magnitude over the last half century. And more importantly, almost anyone can do it. A kid whose closest approach to structural engineering is building a balsa bridge for a weight competition can also write and release an app for Android or iOS that will be seen by millions. Even if it's not a success, it's still just as real a program as MS Office.

That level of access guarantees amateur-level code, and the rigor Kay is suggesting would kill the software industry as we know it.

View on HN

Yeah and I'll tell you, as someone wbo gets to look at a lot of those CAD models that are suposedly introducing rigor, they're often in exactly the same kind of condition as internal codebases.

> That level of access guarantees amateur-level code, and the rigor Kay is suggesting would kill the software industry as we know it.

I don't believe this follows. The level of rigor he's lamenting could be constrained to certain categories of software, based on their impact or information content. Amateur or informally specified systems can still satisfy everything else. There is no reason for most systems that don't touch PII or critical systems or other similar categories of software to have serious engineering behind them if people don't want them to.

Sure, I meant if that rigor was applied to the whole software industry, not selectively, exactly as you say. And that level of rigor is applied sometimes. The most rigorous example I know of is the Space Shuttle guidance system (I think that was it; I read about it twenty years ago). Two independent teams write two entirely separate programs, and then in practice (again, from memory) two versions of program A run, and if they disagree program B is the tie breaker.

Also their QA process was completely adversarial. Finding a bug was a major success for QA, and a major failure for the dev team. They found something crazy like 1 bug per million lines of code.

...the rigor Kay is suggesting would kill the software industry as we know it.

You say that like it's a bad thing.

Anyone's plans to make software sane would kill the software industry as people love and hate it. A substantial portion of this industry involves supporting horrific abortions of a system that seem to live far too long. That includes the functional programming people and anyone who believes some method of theirs will produce an explosion of productivity. Hopefully, the effect will be people quickly rewriting old systems to be sane and creating many new system.

Unfortunately, such starry eyed idealism is unlikely to be realized and the rolling a 1000 pounds of jello up a hill jobs are safe. But this kind of idealism is still needed to motivate the systems builders so it's not a complete loss.

> the rolling a 1000 pounds of jello up a hill jobs are safe

I know that is frowned upon here but boy was that funny.

Well, rigor and quality in building industry are location dependent. I've read a blog of a builder who describes how architects regularly produce dangerous (too thin or just simply missing load-bearing beams) or straight up impossible (gable of negative size, yep) designs. The solution is that the builders just build whatever makes sense and sometimes the contractors simply don't notice.

I'm ignorant in this domain, but wouldn't it be up to the structural engineer to make sure the plans are sound? I always thought that architects dream it up and engineers are responsible for the physics.

Note that Kay actually complained about lack of “real engineering vigor” which maybe was a typo or maybe not.

Reply on news.ycombinator.com