8 ms·

Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. I do tire of programmers acting as if the neces

Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. I do tire of programmers acting as if the necessity of maintenance is some novel and unexpected problem, unique to software development, presented with hyperbolic titles like "software is drowning the world". Is physical infrastructure "drowning the world" because it needs to be maintained?

72deluxe 6y ago
The inability to fully understand how a system works due to the interconnecting pieces is not a problem unique to software either! That ship sailed a long time ago. E.g. with cars can the average person now repair it at home and maintain the entire car themselves? It would be foolish to recommend that we "fix" cars because of our inability to personally understand the entire thing from inception to finish, yet some feel we can apply the same to software. Just look at the Windows Internals books to understand the complexity of just the systems in the operating system. It isn't something that needs to be "fixed" just because something is complex. Everything is more complex than we think it is, and that's not really a problem.
- imglorp 6y ago
  Car maintenance can be shifted to another party with a different business model, eg leasing your car makes it someone else's problem. Similarly, "Functions as a Service" makes many problems the hosting provider's problem. All of the low level goop is theirs. You still have OP's problems but the responsibility surface is reduced.
  - pdimitar 6y ago
    But then you get an entirely new and surprising goop of problems like bursty lag problems (one out of 500 requests finishes in 5s instead of 0.1s), lack of consistency because one of the datacenters is offline, and so many others. It's more like "you now have to deal with different problems" much more than it is "you have to deal with less problems". Maybe the problem quantity got reduced from 1000+ to 50+ but the latter might swallow much more time to solve so it's really questionable which of both is better.
- cxr 6y ago
  I don't know whether or not you've had the opportunity/personal experience of owning two cars concurrently for which you are the only party responsible for doing repairs and maintenance, and where one is much newer (say >10 years), putting you in a position to be able to compare and contrast the two. Cars are not a good example to point to. The thing that would make cars a good example would be if cars were shown to exhibit a steady increase in essential complexity. In that case, yes, we might point to them and say, "Maybe the situation for software is the same, and we're mistaken to have any unreasonable expectations to the contrary?" But that doesn't match reality. Car manufacturers are as guilty as software developers of producing things that have gotten steadily complex without good engineering reasons to justify the complexification. (Pre-emptive request: please do not respond to this comment as if I'm arguing that cars have not become safer or more fuel efficient.)
  - 72deluxe 6y ago
    Yes I have a 1972 VW Beetle, and a 2016 VW Beetle. I can safely say that the former is far simpler and also doesn't require a computer to diagnose or repair. It also doesn't have any firmwares that I can't update, eg. the bluetooth controller in the modern Bug, or the stereo. I can't enable the telephone button on my steering wheel without paying VW. I can't enable Android Auto without paying VW £200 here in the UK. (They couldn't even get it to work when I asked them to). As for the mechanical components of the car - the modern Bug is a diesel (non-PD) so has a common rail fuel system. I can read fault codes with the OBD2 mechanism but not everything is accessible. Both tremendous fun but the modern one is 100 times more complex and I would struggle to maintain it single-handedly. But I don't feel the need to reduce the modern car or "fix" the issue of its complexity simply because it is more complex. My wife has a Mini that has developed a fault but who knows what sensor has failed according to the OBD2 codes?! I don't feel the need to "fix" that and reduce it to the old 1991 Mini Cooper I had (which had its own set of baffling problems, like in-line fuses for important things like the injector but a fuse box for non-essential things like the interior light..... but that's another story).
pdimitar 6y ago
I didn't see in the article any claims that the problems outlined are unique to software development, can you point them out? Hyperbolic titles are indeed a problem of our age though, I agree on that completely. But your prejudice towards programmers who are supposedly thinking their problems are novel and unexpected is not justified.
MaxBarraclough 6y ago
> Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. That sounds a bit broad. In the general aviation world, engine designs from the 60's are still in widespread use.
- paulryanrogers 6y ago
  > That sounds a bit broad. In the general aviation world, engine designs from the 60's are still in widespread use. As is leaded fuel, to the delight off everyone living within a few miles of airports. Old can be good, until it's not anymore. There's often survivorship bias involved as the worst--or unadaptable--designs have naturally fallen out of use or been supplanted.
- gchamonlive 6y ago
  He is talking about the second law of thermodynamics in realised designs. You can use designs from the 60s today and the result will be a brand new system that in time will rot away and need to be replaced by, possibly the same design. That doesn't invalidate what he is talking about. Even the pyramids of Giza will eventually rot away given time. The difference in software, in my opinion, is speed in which change occurs.
- AdrianB1 6y ago
  As a GA pilot I find that a counter-argument: the fact that these engine designs from the 60's are still in widespread use is showing how far behind GA is. These engines work, but they are less performant and economic than car engines of 2020, while costing a lot more (smaller market, regulations, certifications). The old, heavy, underpowered and ubiquitous Cessna 172s are the best example of what is wrong in GA.
  - MaxBarraclough 6y ago
    I should have better explained my point. Their fuel efficiency is atrocious, their power output is pitiful given the size and mass, and they require leaded fuel, as paulryanrogers mentioned. My point wasn't that they're ahead of their time. Engine technology has of course improved in the last 60 years. My point was that they've stuck around. Of course, there are examples of long-lived software, too.
diroussel 6y ago
This posing of the problem is not the interesting part of the article. It’s the proposed solution that should be discussed.
jrochkind1 6y ago
In some cases arguably. https://www.strongtowns.org/the-growth-ponzi-scheme https://www.strongtowns.org/the-growth-ponzi-scheme But I think the initial-to-maintenance ratio of software is both different than for physical infrastructure, but also perhaps more importantly, very different than many decision-makers expect.
Micoloth 6y ago
To be fair, I don't agree with this point of view at all. Things in the physical world break down beacuse they are made of matter, and the entire concept of "working" is a very simplified modeling of their behaviour that doesn't include second-order effects like tear,consumption of materials etc. Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. The _only_ reason we still don't have a reliable and solid code infrastructure (in the sense explained by the article) is our inability as a community to once and for all define a solid foundation for the principles of computing. Hence all the hacked together languages, tools and frameworks that people have piled on each other over the decades. If one century of efforts hasn't been enough, fine. But we absolutely can work towards that goal.
- throw0101a 6y ago
  > Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. Brian Cantrill had a good observation in a 2007 Google TechTalk introducing Dtrace: > In software the blueprints are the machine. In software once you design the thing you've built it: the design is the machine. That's why the waterfall model is so fundamentally flawed. This idea that you could design the design before you design it, which is what the waterfall model is essentially saying, is flawed. Software is both, it's both information and machine. (@3m40s) * https://www.youtube.com/watch?v=6chLw2aodYQ https://www.youtube.com/watch?v=6chLw2aodYQ I originally ran across it on Google Video: * http://video.google.com/videoplay?docid=-8002801113289007228 http://video.google.com/videoplay?docid=-8002801113289007228
- drewcoo 6y ago
  Not sure I agree with this view of software. Social constructs are not immutable any more than physical ones. They're more likely to change, from what I've seen. Making software is about groups of people interacting, side effects of the software, and lossy interfaces more than it is about mathematics.
- blackbrokkoli 6y ago
  That is an extremely simplified view of non-software. Hardware standards shift because of an Apple PR camopaign. We stopped using zeppelins only after one disaster of several dozens made very public by live radio coverage. Non-Sufficiently standardized rockets explode because countries can't pick a measurement system. The auto industry in a country changes overnight because a dictator decides that the roadside to travel on shall be switched on a whim. Just like software, infrastructure/hardware/whatever is an unfathomably complex web made from science, faith, half-knowledge, geopolitics, coincidences, rules, dick moves, physics and random tweets. I don't think we are winning anything by trying to lift software onto some kind of pedestal of specialness in every regard...
blandflakes 6y ago
A lot of programmers I know have no hard feelings about needing to maintain software. My product managers, on the other hand, don't necessarily understand that every line of code has potential long-term cost (and obviously, they ideally also have long-term benefit).

72deluxe 6y ago

The inability to fully understand how a system works due to the interconnecting pieces is not a problem unique to software either! That ship sailed a long time ago. E.g. with cars can the average person now repair it at home and maintain the entire car themselves? It would be foolish to recommend that we "fix" cars because of our inability to personally understand the entire thing from inception to finish, yet some feel we can apply the same to software. Just look at the Windows Internals books to understand the complexity of just the systems in the operating system. It isn't something that needs to be "fixed" just because something is complex. Everything is more complex than we think it is, and that's not really a problem.

imglorp 6y ago
Car maintenance can be shifted to another party with a different business model, eg leasing your car makes it someone else's problem. Similarly, "Functions as a Service" makes many problems the hosting provider's problem. All of the low level goop is theirs. You still have OP's problems but the responsibility surface is reduced.
- pdimitar 6y ago
  But then you get an entirely new and surprising goop of problems like bursty lag problems (one out of 500 requests finishes in 5s instead of 0.1s), lack of consistency because one of the datacenters is offline, and so many others. It's more like "you now have to deal with different problems" much more than it is "you have to deal with less problems". Maybe the problem quantity got reduced from 1000+ to 50+ but the latter might swallow much more time to solve so it's really questionable which of both is better.
cxr 6y ago
I don't know whether or not you've had the opportunity/personal experience of owning two cars concurrently for which you are the only party responsible for doing repairs and maintenance, and where one is much newer (say >10 years), putting you in a position to be able to compare and contrast the two. Cars are not a good example to point to. The thing that would make cars a good example would be if cars were shown to exhibit a steady increase in essential complexity. In that case, yes, we might point to them and say, "Maybe the situation for software is the same, and we're mistaken to have any unreasonable expectations to the contrary?" But that doesn't match reality. Car manufacturers are as guilty as software developers of producing things that have gotten steadily complex without good engineering reasons to justify the complexification. (Pre-emptive request: please do not respond to this comment as if I'm arguing that cars have not become safer or more fuel efficient.)
- 72deluxe 6y ago
  Yes I have a 1972 VW Beetle, and a 2016 VW Beetle. I can safely say that the former is far simpler and also doesn't require a computer to diagnose or repair. It also doesn't have any firmwares that I can't update, eg. the bluetooth controller in the modern Bug, or the stereo. I can't enable the telephone button on my steering wheel without paying VW. I can't enable Android Auto without paying VW £200 here in the UK. (They couldn't even get it to work when I asked them to). As for the mechanical components of the car - the modern Bug is a diesel (non-PD) so has a common rail fuel system. I can read fault codes with the OBD2 mechanism but not everything is accessible. Both tremendous fun but the modern one is 100 times more complex and I would struggle to maintain it single-handedly. But I don't feel the need to reduce the modern car or "fix" the issue of its complexity simply because it is more complex. My wife has a Mini that has developed a fault but who knows what sensor has failed according to the OBD2 codes?! I don't feel the need to "fix" that and reduce it to the old 1991 Mini Cooper I had (which had its own set of baffling problems, like in-line fuses for important things like the injector but a fuse box for non-essential things like the interior light..... but that's another story).

pdimitar 6y ago

I didn't see in the article any claims that the problems outlined are unique to software development, can you point them out? Hyperbolic titles are indeed a problem of our age though, I agree on that completely. But your prejudice towards programmers who are supposedly thinking their problems are novel and unexpected is not justified.

MaxBarraclough 6y ago

> Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. That sounds a bit broad. In the general aviation world, engine designs from the 60's are still in widespread use.

paulryanrogers 6y ago
> That sounds a bit broad. In the general aviation world, engine designs from the 60's are still in widespread use. As is leaded fuel, to the delight off everyone living within a few miles of airports. Old can be good, until it's not anymore. There's often survivorship bias involved as the worst--or unadaptable--designs have naturally fallen out of use or been supplanted.
gchamonlive 6y ago
He is talking about the second law of thermodynamics in realised designs. You can use designs from the 60s today and the result will be a brand new system that in time will rot away and need to be replaced by, possibly the same design. That doesn't invalidate what he is talking about. Even the pyramids of Giza will eventually rot away given time. The difference in software, in my opinion, is speed in which change occurs.
AdrianB1 6y ago
As a GA pilot I find that a counter-argument: the fact that these engine designs from the 60's are still in widespread use is showing how far behind GA is. These engines work, but they are less performant and economic than car engines of 2020, while costing a lot more (smaller market, regulations, certifications). The old, heavy, underpowered and ubiquitous Cessna 172s are the best example of what is wrong in GA.
- MaxBarraclough 6y ago
  I should have better explained my point. Their fuel efficiency is atrocious, their power output is pitiful given the size and mass, and they require leaded fuel, as paulryanrogers mentioned. My point wasn't that they're ahead of their time. Engine technology has of course improved in the last 60 years. My point was that they've stuck around. Of course, there are examples of long-lived software, too.

diroussel 6y ago

This posing of the problem is not the interesting part of the article. It’s the proposed solution that should be discussed.

jrochkind1 6y ago

In some cases arguably. https://www.strongtowns.org/the-growth-ponzi-scheme https://www.strongtowns.org/the-growth-ponzi-scheme But I think the initial-to-maintenance ratio of software is both different than for physical infrastructure, but also perhaps more importantly, very different than many decision-makers expect.

Micoloth 6y ago

To be fair, I don't agree with this point of view at all. Things in the physical world break down beacuse they are made of matter, and the entire concept of "working" is a very simplified modeling of their behaviour that doesn't include second-order effects like tear,consumption of materials etc. Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. The _only_ reason we still don't have a reliable and solid code infrastructure (in the sense explained by the article) is our inability as a community to once and for all define a solid foundation for the principles of computing. Hence all the hacked together languages, tools and frameworks that people have piled on each other over the decades. If one century of efforts hasn't been enough, fine. But we absolutely can work towards that goal.

throw0101a 6y ago
> Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. Brian Cantrill had a good observation in a 2007 Google TechTalk introducing Dtrace: > In software the blueprints are the machine. In software once you design the thing you've built it: the design is the machine. That's why the waterfall model is so fundamentally flawed. This idea that you could design the design before you design it, which is what the waterfall model is essentially saying, is flawed. Software is both, it's both information and machine. (@3m40s) * https://www.youtube.com/watch?v=6chLw2aodYQ https://www.youtube.com/watch?v=6chLw2aodYQ I originally ran across it on Google Video: * http://video.google.com/videoplay?docid=-8002801113289007228 http://video.google.com/videoplay?docid=-8002801113289007228
drewcoo 6y ago
Not sure I agree with this view of software. Social constructs are not immutable any more than physical ones. They're more likely to change, from what I've seen. Making software is about groups of people interacting, side effects of the software, and lossy interfaces more than it is about mathematics.
blackbrokkoli 6y ago
That is an extremely simplified view of non-software. Hardware standards shift because of an Apple PR camopaign. We stopped using zeppelins only after one disaster of several dozens made very public by live radio coverage. Non-Sufficiently standardized rockets explode because countries can't pick a measurement system. The auto industry in a country changes overnight because a dictator decides that the roadside to travel on shall be switched on a whim. Just like software, infrastructure/hardware/whatever is an unfathomably complex web made from science, faith, half-knowledge, geopolitics, coincidences, rules, dick moves, physics and random tweets. I don't think we are winning anything by trying to lift software onto some kind of pedestal of specialness in every regard...

blandflakes 6y ago

A lot of programmers I know have no hard feelings about needing to maintain software. My product managers, on the other hand, don't necessarily understand that every line of code has potential long-term cost (and obviously, they ideally also have long-term benefit).