4 ms·

One of the most nonsensical things I have read on here in a long time. Software is not like a tv show or a stand up comedy set or an album. It is not a cultura

One of the most nonsensical things I have read on here in a long time. Software is not like a tv show or a stand up comedy set or an album. It is not a cultural artifact. It is machinery. We don’t really get bored of a bread slicer. A school bus does not become tiresome. “My french press, it lacks its initial spark!” Machines break, or fall behind evolving requirements (e.g. the bus only takes leaded gas). These are functional shortcomings. The idea of somehow withdrawing a functional useful piece of software from society does not make much sense. There are copies out there, first of all. What are you going to do, hunt them all down? You can stop maintaining it but in many cases, you can’t even prevent other people from working on it. Do you think even Larry Ellison could kill the Oracle database?

et1337 4y ago
> Machines break, or fall behind evolving requirements Requirements now evolve so fast that a "functional useful piece of software" without a maintainer will become useless in about 5 years. Imagine trying to compile a project you haven't touched in 5 years. I know for a fact that even Go, which offers arguably the strongest backward compatibility guarantees out there, wouldn't compile my employer's codebase from 5 years ago.
- 2h 4y ago
  Highly misleading. I've compiled plenty of older Go code. It just seems like you don't know how to deal with Go code, unless it's been nicely packaged as a module with go.mod
- SoftTalker 4y ago
  That's why I've basically quit software. The vast (vast) majority of the code I've written over the past three decades is useless. It is no longer used, and it could not be used even if someone wanted to use it. It's obsolete, because all the underpinnings have moved on. It's sort of depressing to be in the final years of my career and be able to point to nothing that I've created. I'm still working but I've quit learning new frameworks or languages. It used to be fun, now it's just tiring and seems pointless.
  - xwolfi 4y ago
    Maybe find joy in the fact that without your temporary contribution, the next step would never have started ? I mean it's like a lot of jobs: a taxi drivers cant really pinpoint his accomplishments, a nurse will see all person they ever cure die one day, things like that. Contrary to what someone said above, software is not a machine, it's the state reconfiguration of a machine, one of its many inputs. As a programmer all you did was align the knobs to make some inputs produce some outputs, but upstream and downstream changes will change input shape and output requirement, or the machine will change its constraints or the programmers will have figured no way to state change it. Your contribution was important, but thanl god we dont use the state configuration you wrote 20 years ago to solve today's problems.
  - mark_l_watson 4y ago
    True enough. Sorry for a tangent: this is what I really love about some languages like Common Lisp where very old software (that may still be very useful!) still builds and runs.
  - smaudet 4y ago
    I think its the curse of doing development professionally - except the rare case where open source monetization has worked well enough to support a long career, closed source software is designed to be disposable. You build something fast because marketing or sales wanted it, not because it was a good idea or anybody found it useful. Most people probably hated your feature. But, OFC, giving it away for free is nearly impossible to actually make money off of. Like the taxi driver, probably nobody will remember you unless you said something particularly impactful to someone. Someone working as a pro-bono ambulance driver is more likely to receive accolades, but that's still difficult.
  - uberduper 4y ago
    This has been on my mind for the last 15 years. I'm an ops/systems/architect person. I don't expect any of the systems and services I build to exist after 10 years. At least, not in the way I built them. This makes me want to invest time into hobbies where I create things that endure. Of course, I don't have time for that because I'm too busy building temporary solutions to what feels more and more like unimportant problems.
2h 4y ago
I think you missed the unspoken point of the article. The Seinfeld interview in particular is excellent, and maybe the best example of the last twenty years of "leaving on top". King honestly thought they were cancelled, because even then "ending early" was unheard of. The point is that people get tired, they lose motivation, or they just feel that it's good enough. They lay down the gauntlet for the next programmers. Not in earnest, but in resignation.
- SoftTalker 4y ago
  And I disagree that Seinfeld ended early. I think what happened is exactly what he was trying to avoid, "‘It was good but then it started to kinda run out of gas…‘" The last season was not great. It easily could have been worse though. They had enough momentum for another season or two at least if they had wanted to milk it.
  - 2h 4y ago
    somehow you read the article (assumedly), read a top comment, read MY comment, and still missed the point of the article. Its not about whether or not Seinfeld ended early in your opinion or my opinion. Its "assuming that Seinfeld DID end early, why did they do that, and what can others learn from that".
    - SoftTalker 4y ago
      No, I read the article, and appreciate the point, but I don't think Seinfeld is a great example. They quit earlier than they could have, but if the objective was to "leave the audience wanting a little more" then they were already too late. He didn't really give any other reason such as being tired or losing motiviation. The Bill Watterson example cited by other commenters is better.
      - 2h 4y ago
        As I already mentioned, I do not care about the point you are arguing. I only care about the point I made, which is "assuming Seinfeld DID end early, why did they do that, and what can people learn from it".
codemac 4y ago
> Software is not like a tv show or a stand up comedy set or an album. It is not a cultural artifact. It is machinery. You get two things wrong here imo, though I'm not saying the article is great. 1. A lot of software is a cultural artifact. For instance, anything with a user interface we can become nostalgic for. See: pretty much all pop art like Warhol. Video games are another example. 2. It's the humans quitting, not the machinery. If a school bus driver gets tired of driving the bus, the bus has to stop until another driver is found. The same is true of a lot of software, especially open source.
- smaudet 4y ago
  > 2. It's the humans quitting, not the machinery. Is not as true as you think, the common reasons for software to "die": 1. The platform is not made anymore - we use different processors, hard-drives. A hard drive fails and a replacement can't be bought, or a PSU blows and the motherboard/processor are irrevocably damaged. 2. The software production infrastructure disappears - some core library updates, some set of dependent dependencies cannot be (easily) rebuilt. Software (MMOs in particular) can also die for social reasons, or manufactured ones (Windows discontinuing Pinball in newer OS versions). I would argue though, although some humans are doing some quitting (not supporting, trashing something early), for those downstream, it is as if the machinery had started quitting. Humans abandoning useful tools is fairly rare, evidenced even in recent memory with users of Adobe CS2/CS3 still running their (legally purchased) software even as Adobe sends out unlawful and libelous letters/emails...
birdymcbird 4y ago
> “ One of the most nonsensical things I have read on here in a long time.” at risk of sounding arrogant, maybe you missing important experience so this not resonate with you. me time in big tech had many teams or even orgs focused on adding features to some legacy product or service. product managers pitched doing X or Y as big wins for customer experience. managers, directors, and vps all got onboard. so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement. you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work. software not have to end like tv show. but you reach maturity level where now people doing things for political reason, to justify headcount, because they need complexity to demonstrate promotion requirement. all the wrong reasons. root causes many: over hiring.. obsession with growth..empire building..promotion. instead of next true innovation just adding duct tape and doing work with no value for you real customer. knowing when to stop and refocus is key skill and having focus to do in large organization very hard. need founder like entrepreneur business person mindset and strong influence or top down leadership mandate to stop the nonsense.
- smaudet 4y ago
  > "so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement. you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work." I think you are mixing up three things: - 1. A feature being done "X works very well". - 2. Scope of software "When is Product Y that does X finished?" - 3. Politics/Software mistakes "Does this software suck because it was written by monkeys or because our pointy haired boss gave us some expensive crapware" 1. Is a matter of philosophy. Unix one is that a tool does one job, does it well, then it is finished. I think this is the real "being done", the OP's post is so much nonsense. It works, it keeps working, in absence of a better tool, it doesn't make sense to re-invent the wheel. Even if you do (invent flight, e.g.), not all use cases make sense for flight (delivering goods by rail is much more efficient and less error prone than any drone fleet could ever hope for, at least over distance). You do lose some convenience, if you want a hole borer you could either use a screwdriver (or similar) and a hammer, or you could buy or build some fancy pneumatic tool, but really, how many hole borers do you want to buy (concrete vs wood vs acrylic)? The urge to put everything into one product is the mistake - it saves some time up front, but it really only makes sense when you have the persistent and constant need at scale - in my example, maybe if you are building houses, but not for someone who just wanted to do a repair or make some wood furniture. 2. The scope of the software, is defined in part by its philosophy, but in the end it ends up having one, and generally being better at a couple things versus terrible at a bunch of things is the difference between a successful product and dead product. Think of Windows, or Mac OS - the former is good at video games (for a variety of reasons), otherwise besides momentum it doesn't have much going for it. The latter too - its good at video/photos and great at creating iOS apps. Otherwise it too doesn't have a whole lot going for it. Not to leave out the third, Linux, its good at configurability, and great at being a server/embedded OS, otherwise there's a whole lot of reasons its not so great. What is the scope of the scope? Well that's called having a feature set, being able to release. If you engineered well, there is little long term support. Or if there are technology changes/upgrades, then support is required as well. This affects large and small apps, regardless of philosophy - OFC large apps seem to change frequently, but even small ones get security upgrades, bug-fixes, even occasionally new features if the use is common enough. 3. Deciding what goes where and who does what, that's politics, not software. Even the act of a team of engineers working on a project, is cause for politics. But that's still just what some humans did, and it doesn't necessarily reflect reality. Sure, some product probably gets bloated some busy work happens, but if you can still use the (old) software, that doesn't matter. At least until it stops become possible to safely use, the software is fine. Besides, for open source projects at least, when this time (inevitably) comes, the point of the license is to allow for forking, restarting with something that still works or recently did work. I think the only time I can justify this sort of "just throw it away" behavior, is for when you have a closed source, decades old piece of software which cannot be modified. Even with proprietary software, you can re-use source or binary components. Even for non-modular monolithic code-bases, you can extract business logic, utilities, etc, pretty much the only time this is not possible is in case of direct or indirect obfuscation, and even then it is usually not of possibility but of practical cost. When you attempt to re-build the project from scratch, you may attempt to start from simpler principles, usually to either run into the same bugs, (re) discover your set of principles is incomplete, or simply find yourself rebuilding the same solution, maybe with a face lift, or running on the latest and greatest platform.
somenameforme 4y ago
You and I may have read the article somewhat differently. I felt his concluding example was out of harmony with the article, and much more similar to what you're saying. But his early argument was largely that it's OK for a French press to be done. That it's okay, and even good, for a French press to just be a French press. It doesn't mean you can't go buy Seinfeld on blu-ray, it just means that Seinfeld is done. Instead many commercial ventures that make a metaphorical French press instead insist on trying "expand" that French press. Next thing you know it has self insulation, then a new fancy self-plunging pneumatic plunger, and then it becomes an online service, and why not connect your new French process to your friends' French presses, and now your French press has streaming video, now in 4k!, and so on endlessly. At some point you just want your French press back. The examples of this in software are endless especially with endless efforts to turn everything into a service to try to extract rent. And the exact same is also happening in the machine world. Note the recent big news about farmers now being "granted" the right to repair their own tractors - just like they had 20 years ago. Things often become worse over time when companies refuse to just let them be done, but our economic system poses a major deterrence to ever finishing anything.
RandomWorker 4y ago
Highly agree here! Software is more or less a service albeit it being an high automated one or software leveraged service. I call it a service not a product because it takes man power to keep it running and would stop if we stop paying the monthly server and domain fees. Furthermore, because web technology and evergreen browsers are a thing we constantly need to be vigilant for changing standards and interpretations of the same output. I stop telling my clients that they pay us to build and buy, but it’s build and maintain afterwards. That always raises a few questions as building in one way versus the other can lead to higher or lower levels of costs in that maintenance phase. And, it can’t be cost effectively decoupled. Some governmental agencies think that these are separate services and should be acquired through two different bidding processes, that seems to be a bad idea as small updates will be cheap for those that know the underlying mechanics of the project but expensive for a third party.

et1337 4y ago

> Machines break, or fall behind evolving requirements Requirements now evolve so fast that a "functional useful piece of software" without a maintainer will become useless in about 5 years. Imagine trying to compile a project you haven't touched in 5 years. I know for a fact that even Go, which offers arguably the strongest backward compatibility guarantees out there, wouldn't compile my employer's codebase from 5 years ago.

2h 4y ago
Highly misleading. I've compiled plenty of older Go code. It just seems like you don't know how to deal with Go code, unless it's been nicely packaged as a module with go.mod
SoftTalker 4y ago
That's why I've basically quit software. The vast (vast) majority of the code I've written over the past three decades is useless. It is no longer used, and it could not be used even if someone wanted to use it. It's obsolete, because all the underpinnings have moved on. It's sort of depressing to be in the final years of my career and be able to point to nothing that I've created. I'm still working but I've quit learning new frameworks or languages. It used to be fun, now it's just tiring and seems pointless.
- xwolfi 4y ago
  Maybe find joy in the fact that without your temporary contribution, the next step would never have started ? I mean it's like a lot of jobs: a taxi drivers cant really pinpoint his accomplishments, a nurse will see all person they ever cure die one day, things like that. Contrary to what someone said above, software is not a machine, it's the state reconfiguration of a machine, one of its many inputs. As a programmer all you did was align the knobs to make some inputs produce some outputs, but upstream and downstream changes will change input shape and output requirement, or the machine will change its constraints or the programmers will have figured no way to state change it. Your contribution was important, but thanl god we dont use the state configuration you wrote 20 years ago to solve today's problems.
- mark_l_watson 4y ago
  True enough. Sorry for a tangent: this is what I really love about some languages like Common Lisp where very old software (that may still be very useful!) still builds and runs.
- smaudet 4y ago
  I think its the curse of doing development professionally - except the rare case where open source monetization has worked well enough to support a long career, closed source software is designed to be disposable. You build something fast because marketing or sales wanted it, not because it was a good idea or anybody found it useful. Most people probably hated your feature. But, OFC, giving it away for free is nearly impossible to actually make money off of. Like the taxi driver, probably nobody will remember you unless you said something particularly impactful to someone. Someone working as a pro-bono ambulance driver is more likely to receive accolades, but that's still difficult.
- uberduper 4y ago
  This has been on my mind for the last 15 years. I'm an ops/systems/architect person. I don't expect any of the systems and services I build to exist after 10 years. At least, not in the way I built them. This makes me want to invest time into hobbies where I create things that endure. Of course, I don't have time for that because I'm too busy building temporary solutions to what feels more and more like unimportant problems.

2h 4y ago

I think you missed the unspoken point of the article. The Seinfeld interview in particular is excellent, and maybe the best example of the last twenty years of "leaving on top". King honestly thought they were cancelled, because even then "ending early" was unheard of. The point is that people get tired, they lose motivation, or they just feel that it's good enough. They lay down the gauntlet for the next programmers. Not in earnest, but in resignation.

SoftTalker 4y ago
And I disagree that Seinfeld ended early. I think what happened is exactly what he was trying to avoid, "‘It was good but then it started to kinda run out of gas…‘" The last season was not great. It easily could have been worse though. They had enough momentum for another season or two at least if they had wanted to milk it.
- 2h 4y ago
  somehow you read the article (assumedly), read a top comment, read MY comment, and still missed the point of the article. Its not about whether or not Seinfeld ended early in your opinion or my opinion. Its "assuming that Seinfeld DID end early, why did they do that, and what can others learn from that".
  - SoftTalker 4y ago
    No, I read the article, and appreciate the point, but I don't think Seinfeld is a great example. They quit earlier than they could have, but if the objective was to "leave the audience wanting a little more" then they were already too late. He didn't really give any other reason such as being tired or losing motiviation. The Bill Watterson example cited by other commenters is better.
    - 2h 4y ago
      As I already mentioned, I do not care about the point you are arguing. I only care about the point I made, which is "assuming Seinfeld DID end early, why did they do that, and what can people learn from it".

codemac 4y ago

> Software is not like a tv show or a stand up comedy set or an album. It is not a cultural artifact. It is machinery. You get two things wrong here imo, though I'm not saying the article is great. 1. A lot of software is a cultural artifact. For instance, anything with a user interface we can become nostalgic for. See: pretty much all pop art like Warhol. Video games are another example. 2. It's the humans quitting, not the machinery. If a school bus driver gets tired of driving the bus, the bus has to stop until another driver is found. The same is true of a lot of software, especially open source.

smaudet 4y ago
> 2. It's the humans quitting, not the machinery. Is not as true as you think, the common reasons for software to "die": 1. The platform is not made anymore - we use different processors, hard-drives. A hard drive fails and a replacement can't be bought, or a PSU blows and the motherboard/processor are irrevocably damaged. 2. The software production infrastructure disappears - some core library updates, some set of dependent dependencies cannot be (easily) rebuilt. Software (MMOs in particular) can also die for social reasons, or manufactured ones (Windows discontinuing Pinball in newer OS versions). I would argue though, although some humans are doing some quitting (not supporting, trashing something early), for those downstream, it is as if the machinery had started quitting. Humans abandoning useful tools is fairly rare, evidenced even in recent memory with users of Adobe CS2/CS3 still running their (legally purchased) software even as Adobe sends out unlawful and libelous letters/emails...

birdymcbird 4y ago

> “ One of the most nonsensical things I have read on here in a long time.” at risk of sounding arrogant, maybe you missing important experience so this not resonate with you. me time in big tech had many teams or even orgs focused on adding features to some legacy product or service. product managers pitched doing X or Y as big wins for customer experience. managers, directors, and vps all got onboard. so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement. you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work. software not have to end like tv show. but you reach maturity level where now people doing things for political reason, to justify headcount, because they need complexity to demonstrate promotion requirement. all the wrong reasons. root causes many: over hiring.. obsession with growth..empire building..promotion. instead of next true innovation just adding duct tape and doing work with no value for you real customer. knowing when to stop and refocus is key skill and having focus to do in large organization very hard. need founder like entrepreneur business person mindset and strong influence or top down leadership mandate to stop the nonsense.

smaudet 4y ago
> "so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement. you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work." I think you are mixing up three things: - 1. A feature being done "X works very well". - 2. Scope of software "When is Product Y that does X finished?" - 3. Politics/Software mistakes "Does this software suck because it was written by monkeys or because our pointy haired boss gave us some expensive crapware" 1. Is a matter of philosophy. Unix one is that a tool does one job, does it well, then it is finished. I think this is the real "being done", the OP's post is so much nonsense. It works, it keeps working, in absence of a better tool, it doesn't make sense to re-invent the wheel. Even if you do (invent flight, e.g.), not all use cases make sense for flight (delivering goods by rail is much more efficient and less error prone than any drone fleet could ever hope for, at least over distance). You do lose some convenience, if you want a hole borer you could either use a screwdriver (or similar) and a hammer, or you could buy or build some fancy pneumatic tool, but really, how many hole borers do you want to buy (concrete vs wood vs acrylic)? The urge to put everything into one product is the mistake - it saves some time up front, but it really only makes sense when you have the persistent and constant need at scale - in my example, maybe if you are building houses, but not for someone who just wanted to do a repair or make some wood furniture. 2. The scope of the software, is defined in part by its philosophy, but in the end it ends up having one, and generally being better at a couple things versus terrible at a bunch of things is the difference between a successful product and dead product. Think of Windows, or Mac OS - the former is good at video games (for a variety of reasons), otherwise besides momentum it doesn't have much going for it. The latter too - its good at video/photos and great at creating iOS apps. Otherwise it too doesn't have a whole lot going for it. Not to leave out the third, Linux, its good at configurability, and great at being a server/embedded OS, otherwise there's a whole lot of reasons its not so great. What is the scope of the scope? Well that's called having a feature set, being able to release. If you engineered well, there is little long term support. Or if there are technology changes/upgrades, then support is required as well. This affects large and small apps, regardless of philosophy - OFC large apps seem to change frequently, but even small ones get security upgrades, bug-fixes, even occasionally new features if the use is common enough. 3. Deciding what goes where and who does what, that's politics, not software. Even the act of a team of engineers working on a project, is cause for politics. But that's still just what some humans did, and it doesn't necessarily reflect reality. Sure, some product probably gets bloated some busy work happens, but if you can still use the (old) software, that doesn't matter. At least until it stops become possible to safely use, the software is fine. Besides, for open source projects at least, when this time (inevitably) comes, the point of the license is to allow for forking, restarting with something that still works or recently did work. I think the only time I can justify this sort of "just throw it away" behavior, is for when you have a closed source, decades old piece of software which cannot be modified. Even with proprietary software, you can re-use source or binary components. Even for non-modular monolithic code-bases, you can extract business logic, utilities, etc, pretty much the only time this is not possible is in case of direct or indirect obfuscation, and even then it is usually not of possibility but of practical cost. When you attempt to re-build the project from scratch, you may attempt to start from simpler principles, usually to either run into the same bugs, (re) discover your set of principles is incomplete, or simply find yourself rebuilding the same solution, maybe with a face lift, or running on the latest and greatest platform.

somenameforme 4y ago

You and I may have read the article somewhat differently. I felt his concluding example was out of harmony with the article, and much more similar to what you're saying. But his early argument was largely that it's OK for a French press to be done. That it's okay, and even good, for a French press to just be a French press. It doesn't mean you can't go buy Seinfeld on blu-ray, it just means that Seinfeld is done. Instead many commercial ventures that make a metaphorical French press instead insist on trying "expand" that French press. Next thing you know it has self insulation, then a new fancy self-plunging pneumatic plunger, and then it becomes an online service, and why not connect your new French process to your friends' French presses, and now your French press has streaming video, now in 4k!, and so on endlessly. At some point you just want your French press back. The examples of this in software are endless especially with endless efforts to turn everything into a service to try to extract rent. And the exact same is also happening in the machine world. Note the recent big news about farmers now being "granted" the right to repair their own tractors - just like they had 20 years ago. Things often become worse over time when companies refuse to just let them be done, but our economic system poses a major deterrence to ever finishing anything.

RandomWorker 4y ago

Highly agree here! Software is more or less a service albeit it being an high automated one or software leveraged service. I call it a service not a product because it takes man power to keep it running and would stop if we stop paying the monthly server and domain fees. Furthermore, because web technology and evergreen browsers are a thing we constantly need to be vigilant for changing standards and interpretations of the same output. I stop telling my clients that they pay us to build and buy, but it’s build and maintain afterwards. That always raises a few questions as building in one way versus the other can lead to higher or lower levels of costs in that maintenance phase. And, it can’t be cost effectively decoupled. Some governmental agencies think that these are separate services and should be acquired through two different bidding processes, that seems to be a bad idea as small updates will be cheap for those that know the underlying mechanics of the project but expensive for a third party.