5 ms·

Part of me wonders why nobody tries to make software like we make buildings... After some time, it's all done and nothing else needs to be added. People will b

Part of me wonders why nobody tries to make software like we make buildings... After some time, it's all done and nothing else needs to be added. People will be quick to point out that "the hardware keeps changing so the software has to adapt". This is true, but why not design the software in such a way that different drivers can easily be substituted (so the drivers can change but the interface doesn't)? I did this with my open source project. I haven't made any code changes for over a year and it still works perfectly and still relevant. I don't understand why there is such a fetish in this industry for never finishing any project. I find the whole attitude very frustrating.

DC-3 5y ago
You know buildings also require maintenance, right?
- sophacles 5y ago
  And they regularly get overhauls and additions.
- cryptica 5y ago
  Hardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference. But that's not even important to my argument. To suggest that software maintenance and building maintenance are anything alike is ignoring the entire context of the two activities. With buildings, builders have very little control over the wear and tear caused by the environment. In software, developers collectively have total control over the software and hardware environment which determines whether or not software breaks. Most of the wear and tear in software is a direct result of people compulsively changing stuff in other software (or hardware) up the stack - It's all 100% avoidable. If the software never changed materially (aside from bug fixes), it would not break. Simple as that. And most of the software changes are simply taking us round in circles. New generations of developers undoing the work of the previous generation, then later reversing direction again, surely we've all seen it happening at most of the software companies we've worked at...
  - JetSpiegel 5y ago
    > Hardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference. Linux is more akin to a template of all buildings in the world, which are all the Burj al Arab (of course each building is mostly empty, everyone just uses some part of it). If someone in Mongolia finds a wrongly tiled bathroom in room 221B, Linus changes that tile in its template. A few weeks later, all Burj al Arab in the world are torn down and replace with a new one, only slightly better.
    - cryptica 5y ago
      This sounds terribly inefficient. Why include the tiles as part of the design? Why not instead have a specification about what kinds of tiles are supported and how they should be laid out instead (just an interface)? Then other projects could take care of providing designs for tiles... Tile providers will need to change to adapt any changes to the core layout, but the core layout doesn't need to change often since the fickle parts are not part of it.
      - JetSpiegel 5y ago
        Micro-houses are for the time-rich. Ain't nobody got the time to select all the sub-specifications for a simple house. It's simpler to live in a small corner of the Burj al-Arab, you can piggyback on some work made by the big hoteliers. The metaphors are crumbling...
uncomputation 5y ago
A couple things: > so the drivers can change but the interface doesn't This is already how it is. Take write(sockfd, …). Sure there are some configuration options in the parameters but nothing compared to the real complexity of networking. This is the downside to abstraction; roughly, the least complex implementation wins. Eventually, we shift and add more and more standards, but it’s never cutting edge (and for good reason). > I haven't made any code changes for over a year Relatively speaking, a year is nothing in the timeline of software, so this is not surprising and it’s likely that even if you hadn’t written your software in a abstracted way (which kudos to you for doing so), it would still be fine after only one year. write() has been the same interface for over 40 years. Also, not to rain on anybody’s parade, but OSS is - generally - not held to the same performance standards that proprietary code is. This makes sense intuitively right? “If I’m paying for it, it better work.” And the vast, vast majority of code is not OSS. We just get a false impression since, by definition, we only have access to OSS. The worst that can happen for bad OSS is lack of adoption or a tsunami of incoming GitHub issues. For proprietary code, you could lose your job if a product doesn’t take. > I don't understand why there is such a fetish in this industry for never finishing any project This is similar to the argument that a company, once it has a good product, should just stop. Why do we need updates?, I like the features we have, Don’t change it, it’s perfect. But to survive in the market - not just on GitHub or code coverage tests - requires constant competition and innovation. If Intel launches a new multi-register write feature, Chip Company X can’t just say “Well our project is done.” It’s not anymore! And if it, then Chip Company X might be done too…
- nikanj 5y ago
  > Also, not to rain on anybody’s parade, but OSS is - generally - not held to the same performance standards that proprietary code is. This makes sense intuitively right? “If I’m paying for it, it better work.” I've noticed the opposite to be true. Code from a proprietary vendor is buggy? Too bad, the corp just a faceless, nameless borg of an entity that doesn't care about your bugs. OSS has bugs? You can easily go rant at the poor coders who are working on it
  - fiddlerwoaroof 5y ago
npteljes 5y ago
A work of art is never finished, merely abandoned. Also, Why do you think building are finished at any time? The insides change a lot, living space expands to the attic, old wiring get replaced, walls get extra support, roof gets patched, replaced, or maybe they even build a new story.

DC-3 5y ago

You know buildings also require maintenance, right?

sophacles 5y ago
And they regularly get overhauls and additions.
cryptica 5y ago
Hardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference. But that's not even important to my argument. To suggest that software maintenance and building maintenance are anything alike is ignoring the entire context of the two activities. With buildings, builders have very little control over the wear and tear caused by the environment. In software, developers collectively have total control over the software and hardware environment which determines whether or not software breaks. Most of the wear and tear in software is a direct result of people compulsively changing stuff in other software (or hardware) up the stack - It's all 100% avoidable. If the software never changed materially (aside from bug fixes), it would not break. Simple as that. And most of the software changes are simply taking us round in circles. New generations of developers undoing the work of the previous generation, then later reversing direction again, surely we've all seen it happening at most of the software companies we've worked at...
- JetSpiegel 5y ago
  > Hardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference. Linux is more akin to a template of all buildings in the world, which are all the Burj al Arab (of course each building is mostly empty, everyone just uses some part of it). If someone in Mongolia finds a wrongly tiled bathroom in room 221B, Linus changes that tile in its template. A few weeks later, all Burj al Arab in the world are torn down and replace with a new one, only slightly better.
  - cryptica 5y ago
    This sounds terribly inefficient. Why include the tiles as part of the design? Why not instead have a specification about what kinds of tiles are supported and how they should be laid out instead (just an interface)? Then other projects could take care of providing designs for tiles... Tile providers will need to change to adapt any changes to the core layout, but the core layout doesn't need to change often since the fickle parts are not part of it.
    - JetSpiegel 5y ago
      Micro-houses are for the time-rich. Ain't nobody got the time to select all the sub-specifications for a simple house. It's simpler to live in a small corner of the Burj al-Arab, you can piggyback on some work made by the big hoteliers. The metaphors are crumbling...

uncomputation 5y ago

A couple things: > so the drivers can change but the interface doesn't This is already how it is. Take write(sockfd, …). Sure there are some configuration options in the parameters but nothing compared to the real complexity of networking. This is the downside to abstraction; roughly, the least complex implementation wins. Eventually, we shift and add more and more standards, but it’s never cutting edge (and for good reason). > I haven't made any code changes for over a year Relatively speaking, a year is nothing in the timeline of software, so this is not surprising and it’s likely that even if you hadn’t written your software in a abstracted way (which kudos to you for doing so), it would still be fine after only one year. write() has been the same interface for over 40 years. Also, not to rain on anybody’s parade, but OSS is - generally - not held to the same performance standards that proprietary code is. This makes sense intuitively right? “If I’m paying for it, it better work.” And the vast, vast majority of code is not OSS. We just get a false impression since, by definition, we only have access to OSS. The worst that can happen for bad OSS is lack of adoption or a tsunami of incoming GitHub issues. For proprietary code, you could lose your job if a product doesn’t take. > I don't understand why there is such a fetish in this industry for never finishing any project This is similar to the argument that a company, once it has a good product, should just stop. Why do we need updates?, I like the features we have, Don’t change it, it’s perfect. But to survive in the market - not just on GitHub or code coverage tests - requires constant competition and innovation. If Intel launches a new multi-register write feature, Chip Company X can’t just say “Well our project is done.” It’s not anymore! And if it, then Chip Company X might be done too…

nikanj 5y ago
> Also, not to rain on anybody’s parade, but OSS is - generally - not held to the same performance standards that proprietary code is. This makes sense intuitively right? “If I’m paying for it, it better work.” I've noticed the opposite to be true. Code from a proprietary vendor is buggy? Too bad, the corp just a faceless, nameless borg of an entity that doesn't care about your bugs. OSS has bugs? You can easily go rant at the poor coders who are working on it
- fiddlerwoaroof 5y ago

npteljes 5y ago

A work of art is never finished, merely abandoned. Also, Why do you think building are finished at any time? The insides change a lot, living space expands to the attic, old wiring get replaced, walls get extra support, roof gets patched, replaced, or maybe they even build a new story.