4 ms·

I think I should have been a bit more clear but I also like that the question was a bit vague because there is a lot of interesting comments highlighting things

by _pdp_ 11y ago

I think I should have been a bit more clear but I also like that the question was a bit vague because there is a lot of interesting comments highlighting things I never thought about it. I believe that software engineers failed in some ways because we always factor the maintenance as part of the development cost. In other words, we assume that we have to maintain a system once it is built. It is even more relevant with web applications which give the impression that they are in a constant flux. I don't buy the idea that web apps needs to adopt because standards don't move that fast and almost all browser are backwards compatible with sites that were developed in the 80s. I don't know what is behind HN but its simplistic, non-fluid interface hasn't been changed (I don't know actually) since it was made which for me shows that it is possible to make something useful without the need to constantly change. There are many example like that. I also like the analogy that some of you wrote about physical systems. Indeed, there are physical systems that hasn't been changed for years and they still work. There is also a lot of software systems, mainly SCADA stuff, that are also designed never to be changed. Not long ago I heard a story about a pentest on a SCADA system that was controlling a dam. Despite that the pentest found a bunch of vulnerabilities, it was not possible to change the system because its author was dead long ago. The dam operated just fine even with the vulnerabilities in its software. Another point I wanted to bing about is about defining time and version constrains. Back in the days software was not continues. In other words you get Doom 1. Doom 2 is a different story. Therefore, Doom 1 source code can go free. I would say that Doom was very much low to zero maintenance system, albeit a software one. Bugs were part of the character of the software. Hacking the software through its bugs was as close as it get to magic in the digital world. As we get more connected we require to maintain the software. These are just a few things that came to my mind. I will add more thoughts as I go over your comments.

blincoln 11y ago
"The dam operated just fine even with the vulnerabilities in its software." IMO the key thing to keep in mind is that twenty years ago, it was very common to have systems that were truly "air-gapped" from everything else. E.g. in the 1980s or 1990s, someone probably had to operate that dam's SCADA system from a particular console in a particular room. "As we get more connected we require to maintain the software." Yes. As soon as everyone started networking everything together - and especially after they started putting everything on the internet - those old systems become a dangerous liability. IMO it is effectively impossible to have a truly fixed-design system continue to operate in a reliable way when it exists in a changing environment. Computing systems are too complex for any designer to understand all of the possible conditions in advance. While it's true that if nothing goes wrong, the dam will probably continue to operate correctly, if it's now attached to a network, then there are all sorts of things that can make those vulnerabilities an issue later: - Obviously there's the possibility of someone tampering with it for malicious purposes. Maybe they're a foreign government who wants to destabilize the US. Maybe they're a malicious stock trader who wants to short the stock of the dam owner. - If it's a really poorly-written system from the 1980s, it probably crashes if it receives input beyond a certain length, because of e.g. a buffer overflow. Maybe someone mistypes an IP address in a configuration field and suddenly a database client tries to connect to it and triggers that bug. - Does it represent time in some way? If so, is it going to enter unexpected territory when whatever counter it uses flips over? If it's old enough that the author is dead, it's probably using a 32-bit integer at most, and so is susceptible to the same kind of problem as legacy Unix systems. Etc. IMO, as soon as computing systems start to be networked together, they have to be treated more like plants in a garden than machines in a factory - if there isn't a "gardener" keeping things under control, it will turn into a disaster. It's still a deterministic system, but it's one in which the number of variables is far too high (IMO) to effectively plan out every possible contingency and response in advance. Maintenance can be minimized, but not eliminated.
PaulHoule 11y ago
For operational software that runs a business you are going to need to change the software because the business changes. It is true that the visual UI of HN looks stable but behind the scenes they are always making changes to improve the community. Part of it is dealing with attacks & spam, part of it is trying to shape the behavior of users who are in the grey area between positive and negative contribution. So far as security, that is another force for perpetual change.
deleted 11y ago
[deleted]

by _pdp_ 11y ago

blincoln 11y ago

"The dam operated just fine even with the vulnerabilities in its software." IMO the key thing to keep in mind is that twenty years ago, it was very common to have systems that were truly "air-gapped" from everything else. E.g. in the 1980s or 1990s, someone probably had to operate that dam's SCADA system from a particular console in a particular room. "As we get more connected we require to maintain the software." Yes. As soon as everyone started networking everything together - and especially after they started putting everything on the internet - those old systems become a dangerous liability. IMO it is effectively impossible to have a truly fixed-design system continue to operate in a reliable way when it exists in a changing environment. Computing systems are too complex for any designer to understand all of the possible conditions in advance. While it's true that if nothing goes wrong, the dam will probably continue to operate correctly, if it's now attached to a network, then there are all sorts of things that can make those vulnerabilities an issue later: - Obviously there's the possibility of someone tampering with it for malicious purposes. Maybe they're a foreign government who wants to destabilize the US. Maybe they're a malicious stock trader who wants to short the stock of the dam owner. - If it's a really poorly-written system from the 1980s, it probably crashes if it receives input beyond a certain length, because of e.g. a buffer overflow. Maybe someone mistypes an IP address in a configuration field and suddenly a database client tries to connect to it and triggers that bug. - Does it represent time in some way? If so, is it going to enter unexpected territory when whatever counter it uses flips over? If it's old enough that the author is dead, it's probably using a 32-bit integer at most, and so is susceptible to the same kind of problem as legacy Unix systems. Etc. IMO, as soon as computing systems start to be networked together, they have to be treated more like plants in a garden than machines in a factory - if there isn't a "gardener" keeping things under control, it will turn into a disaster. It's still a deterministic system, but it's one in which the number of variables is far too high (IMO) to effectively plan out every possible contingency and response in advance. Maintenance can be minimized, but not eliminated.

PaulHoule 11y ago

For operational software that runs a business you are going to need to change the software because the business changes. It is true that the visual UI of HN looks stable but behind the scenes they are always making changes to improve the community. Part of it is dealing with attacks & spam, part of it is trying to shape the behavior of users who are in the grey area between positive and negative contribution. So far as security, that is another force for perpetual change.

deleted 11y ago

[deleted]