Hacker News Reader

Comment by crabl | Hacker News Reader

I feel like Kowloon is a decent metaphor for software design at most typical large SaaS companies: small changes accreted over time that lead to an impenetrable, wandering structure that only the residents (developers) truly understand.

View on HN

“We build our computers the way we build our cities — over time, without a plan, on top of ruins.”

― Ellen Ullman, Life in Code: A Personal History of Technology

Nicholas Negroponte's The Architecture Machine goes deep into analogizing software and housing along the dimension of "improvised / iterated on by the users" to "waterfall designed by committee"

(free with archive account, fascinating book, dedicated to "the first machine that can appreciate the gesture" https://archive.org/details/architecturemach00negr/page/n15/...)

It's a fascinating comparison—I've seen this happen at companies too. Makes you wonder if imposing something akin to building codes for software development could prevent this kind of sprawling complexity.

i've never seen coding standards properly enforced on any large project, nobody has time to read through and scrutinize 30 files of code every time somebody creates a new feature when everybody has their own work to be doing too. at my last job we had mandatory code reviews and some days half of the entire day was just doing that. it didn't long before reading turned into skimming and skimming just turned into clicking approve.

I was thinking less about self-imposed code reviews and more about regulatory frameworks—principles borrowed from architecture and construction, like mandated documentation, reviews, and inspections.

There's some precedent for this: software in medical devices face strict regulations after incidents like Therac-25.

While most software might not carry the same life-or-death risks, data breaches are increasing in frequency and impact. We should at least be thinking about how we can improve our processes as an industry.

> I was thinking less about self-imposed code reviews and more about regulatory frameworks—principles borrowed from architecture and construction, like mandated documentation, reviews, and inspections.

This exists in automotive, cf. ASPICE. And even more extensively in aviation.

And no, it doesn't help fight sprawl much sadly.

The HN crowd is mostly web and mobile and unaware how broad the software field is, even though software in safety-critical applications of course predates both.

given that it takes medical devices billions of dollars in testing to get to market this is a great way to just crush technology entirely. and even so the FDA is recognizing the error of some of its ways and lowering the barriers to entry for things like hearing aids.

Sadly I have to agree. It has to be mechanically enforced or it doesn't actually last, even with good intentions. (Or a BDFL, but those have scaling limits and Life™ stuff)

Which is a shame because I'm pretty convinced that slowing down and having time to do those reviews is net-good in the (not-very-)long run. Much of the space (and bugs) in even a very well run large project are from accumulating gaps until nobody knows how things truly work - it takes time to eliminate them and end up in a simpler, smaller, more sustainable state.

Business moves faster than clean software architecture.

If there was 'code', arguably, nothing would be built in the first place.

Other industries innovate despite having to follow codes and industry standards. They just innovate slower.

Engineering standards are built on piles of corpses. We’re lucky that most of the growth of our industry has been in non-life-critical areas.

But regulation and standards are coming eventually - shoddy code will just have to kill a few thousand people first.

The problem isn't that we fail to apply the same rules for software development in safety-critical and non-safety-critical contexts. The problem is that we do apply the same software in both contexts.

Gatekeeping the entire industry isn't the answer unless you want to cripple it... but if someone wanted to issue regulations along the lines of "Don't steer your nuclear-powered aircraft carrier with a Windows app," I wouldn't object to that.

Better Windows 95 than JavaScript

A ton of businesses also die or crater in slow-mo after they have loaded up on tech debt and grown. Its less likely in pure software, as the exponential curve outruns the need for exponential devs, but it happens..

Yes, it certainly would have prevented a lot of things, including the creation of the OS and software you used to suggest it.

I feel like like that recently. Just examining an app that was largely written in isolation and ... I just discovered a new auth endpoint / service that nobody knew we had, and it does not behave logically. It has all sorts of limits that impedes testing / troubleshooting.

Pain ...

For the record I am going to eventually direct this app to the "normal" auth service and fix it all up, but man why is it this way???

Is this a reference to the “I divorced my wife and this is what it taught me about B2B sales” joke?

Maybe... that's why I've been fascinated by it. :|

I think this applies to anything that is created over more than a single generation. Basically anything the government touches eventually goes this way too.

Reply on news.ycombinator.com