Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Are you talking about software engineering, or engineering engineering? Because I don't think building engineers create technical debt.

View on HN

Buildings can definitely accumulate technical debt when they're put through a series of changes of use over time. It manifests as odd cable routing, inconsistent floor levels, repeatedly moved doorways, obstructed windows, etc.

The UK houses of parliament are a good, if perhaps extreme example of that: https://www.theguardian.com/news/2017/dec/01/a-tale-of-decay...

They have now finally decided to move the MPs out so they can do the refactoring they've needed to do for years...

What do you call the work that needed to be done in order to remove the existing electrical cables in my house and replace them with a wiring layout that was able to add a second outlet in my bedroom? (Or, far better - the unofficial extra wires that the contractor found which had been loosely spliced into the existing system by the previous owner in order to power the new bathroom lights he added, which just stopped working when we removed the old cable because nobody knew that connection existed).

Technical debt is kicking the can down the road. What you're talking about is mostly just a feature overhaul. The modifications the previous tenant made were technical debt.

I don't agree with this. As was pointed out here too, software changes in production all the time. This happens with Buildings too, but on a different time scale. Buildings that were made with forward layouts for HVAC and electrical systems will be easier to upgrade in the future. If you look at old buildings that had networking and such retrofitted in a visible and ugly fashion, I think its fair to say that you're looking at technical debt.

In the sense that the alternative is to demolish and build a new building, your example is technical debt. But your example is really an example of legacy systems.

Sometimes, supporting the legacy system can be technical debt. But sometimes when people try to replace the legacy system, they spend a lot of time and money and end up costing way more than simply maintaining the legacy system. This is part of why some nuclear plants will continue to operate on PDP-11's until the year 2050.

Technical debt isn't really debt if it's actually just a part of the cost of doing business. You design your system for its intended purpose, and if it's accomplishing that purpose well, you don't need a redesign. Don't break what doesn't need fixing.

Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production. That flexibility means that the first release need not be the last release. The obvious charitable interpretation is that the parent was talking about software.

> Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production.

I used to think this was true, but after talking to architecture/civil engineering friends a lot about this, I've learned that this is less true than I believed. There are often changing requirements for buildings due to different use cases, changing regulations or building codes, or a change in energy prices (or the social cost of using a lot of energy). Sometimes new technologies are used without a lot of experience with them, leading to high operating expenses for the lifetime of the building.

I asked my friend about your comment and he gave me a few interesting examples: 1) "flying form construction" that leads to exposed concrete slabs on buildings that bleed heat in the winter. This was really cheap to build but turned out to be really awful for energy efficiency (once we started caring). 2) a building in the 50s-60s that was built with automatic window blinds. The maintenance cost of fixing the blinds when they inevitably broke led to them not getting fixed, and the building becoming basically useless.

If you're interested in reading more about this, Stewart Brand's "How Buildings Learn" is a really good read for laypeople. I was really surprised by how much of the book could be applied to software engineering.

(This is not a field I'm familiar with so any errors are mine, not my friend's.)

Reply on news.ycombinator.com