4 ms·

I think it has less to do with the quality of developers and more to do with perverse incentive structures surrounding commercial software design. A piece of so

I think it has less to do with the quality of developers and more to do with perverse incentive structures surrounding commercial software design. A piece of software that optimally solves a problem for the user is rarely optimal for generating revenue. Hence the common practice of companies breaking and sabotaging their own products to get the upsell while slowly turning them into spyware. The fundamental problem is engineers being forced to operate in bad faith, which interferes with them actually doing their jobs. Obviously there is also bad free software out there, but it has more benign afflictions. Free software also tends to steadily improve with time, but commercial software is a roll of the dice with every update.

stingblue 6y ago
I would think that depends on the type of commercial software - if, for example, it's used in a large bank where faulty software could screw up a few million customer accounts - anyone who rolls the dice with that will soon be jobless. THAT software (application, OS, utilities, etc.) is usually VERY well tested.
- BlargMcLarg 6y ago
  Even there, you can make the software work and be secure, and still get away with loads of maddening practices and making software that just barely does what it does, waiting for the customer to fund a feature. Is it a smart business move? Debatable (I'd argue overdelivering on a SaaS product also helps bring in new customers). From a moral standpoint, I find it incredibly difficult to justify penny pinching and filling hours with malpractices and bureaucracy. And for what it is worth: personal experience tells, a lot of customers are quite accepting of faulty software, as long as the damage can be reverted and minimized. Even those in finance. Wouldn't be the first time I see people casually solve a bug that caused millions worth of damage.
swiley 6y ago
Often the end user isn't even the one making the decision about buying/installing the software. (see: consumer OSes/firmware, "ed tech," most coorperate software.)
megameter 6y ago
To me, the issue seems to be shared in common with "hard" engineering and infrastructure - it's easier to build than to maintain. The demo is easy, the thing people count on for their own work is a Sisyphean monstrosity. The difference is just one of speed and scale. The software starts paying for maintenance almost immediately. People see a open source codebase that is now "good enough" for their problem, and within months it becomes a popular dependency, and then a singularity. Construction that goes wrong, on the other hand, often has a narrative that plays out over decades. The featureset of a bridge or building grows little with time, and often slims down, and so while the maintenance can be physically costly, it isn't like the building gets remodelled and rewired each year to do a new thing, which is a thing that happens often to software. Software companies that can really embrace the "maintenance of a singularity" role usually last, even if they accrue some tremendous technical debt: see Microsoft, Oracle, Adobe for some examples. Companies that try to elude that outcome, on the other hand, have to have a business model of disposability: Apple tends to obsolete software when new hardware hits, as do most game companies. The companies that let the product rot are the common failure case, and the companies that keep the product small are themselves small.
mbrodersen 6y ago
Of course it has nothing to do with developer skills. Follow the money! Fixing bugs/selling upgrades makes money. Writing perfect software makes you bankrupt.

stingblue 6y ago

I would think that depends on the type of commercial software - if, for example, it's used in a large bank where faulty software could screw up a few million customer accounts - anyone who rolls the dice with that will soon be jobless. THAT software (application, OS, utilities, etc.) is usually VERY well tested.

BlargMcLarg 6y ago
Even there, you can make the software work and be secure, and still get away with loads of maddening practices and making software that just barely does what it does, waiting for the customer to fund a feature. Is it a smart business move? Debatable (I'd argue overdelivering on a SaaS product also helps bring in new customers). From a moral standpoint, I find it incredibly difficult to justify penny pinching and filling hours with malpractices and bureaucracy. And for what it is worth: personal experience tells, a lot of customers are quite accepting of faulty software, as long as the damage can be reverted and minimized. Even those in finance. Wouldn't be the first time I see people casually solve a bug that caused millions worth of damage.

swiley 6y ago

Often the end user isn't even the one making the decision about buying/installing the software. (see: consumer OSes/firmware, "ed tech," most coorperate software.)

megameter 6y ago

To me, the issue seems to be shared in common with "hard" engineering and infrastructure - it's easier to build than to maintain. The demo is easy, the thing people count on for their own work is a Sisyphean monstrosity. The difference is just one of speed and scale. The software starts paying for maintenance almost immediately. People see a open source codebase that is now "good enough" for their problem, and within months it becomes a popular dependency, and then a singularity. Construction that goes wrong, on the other hand, often has a narrative that plays out over decades. The featureset of a bridge or building grows little with time, and often slims down, and so while the maintenance can be physically costly, it isn't like the building gets remodelled and rewired each year to do a new thing, which is a thing that happens often to software. Software companies that can really embrace the "maintenance of a singularity" role usually last, even if they accrue some tremendous technical debt: see Microsoft, Oracle, Adobe for some examples. Companies that try to elude that outcome, on the other hand, have to have a business model of disposability: Apple tends to obsolete software when new hardware hits, as do most game companies. The companies that let the product rot are the common failure case, and the companies that keep the product small are themselves small.

mbrodersen 6y ago

Of course it has nothing to do with developer skills. Follow the money! Fixing bugs/selling upgrades makes money. Writing perfect software makes you bankrupt.