5 ms·

I dig Seth Godin a lot, but the real reason that software trends toward mediocrity over time is that the code base generally becomes an unmaintainable pile of c

I dig Seth Godin a lot, but the real reason that software trends toward mediocrity over time is that the code base generally becomes an unmaintainable pile of crap. I find this this takes place over the course of years due to: 1. Tight development timelines that encourage features getting slapped in quickly at the expense of proper refactoring or architecture. 2. A shifting or unclear product spec - sometimes so dramatic that refactoring or rewriting is prohibitive (a hack is born) 3. The fact that many developers will touch the code over time. Not only will developers have differing code styles, the preferred code styles and patterns of the language and framework change over time too. The attitudes and level of commitment changes over time as original developers leave and new ones come in. If the code finally gets shipped to an outsourcing firm, you can bet that any last traces of quality are going to disappear. This doesn't just happen at lazy or cheap firms - I've seen projects with an incredibly strong development team devolve over time too. It can be prevented, but it happens more often than not. PayPal? Imagine the twisted bunch of cgi they probably still have lying around in their core code base. I'd be willing to bet there are still traces of Peter Thiel and Elon Musk in there, and nobody wants to touch it

panic 11y ago
The problem of software quality is complicated and difficult to reduce to a single set of issues. I don't think anything you've said here contradicts what Seth wrote. I think he's right, though, that economics is the fundamental problem. We bang out code quickly to meet deadlines measured in months despite the decades-long impact a poor decision can have (see JavaScript for example). When we find ourselves slowing down, we add more people to write more code; why are we surprised when our software becomes bloated? But if we missed our deadlines too much, we'd lose the market to our competitor, who wrote their software more quickly. And if we didn't hire more programmers, we'd lose again to our competitor, who hired tons of people to add attractive features. It seems impossible to write good software without losing in the free market. IMO we should be thinking about how to support software projects outside of market-based corporations.
- taeric 11y ago
  JavaScript seems an odd choice for an example. Sure, you can look only at the oddities of the language, but you could also look at it as the choice to allow dynamic scripting in web pages. At that level, it has been a hugely enabling choice that I would not label as a poor decision. That is, there is no real evidence that any other choice would have obviously gone better. Why assert it?
  - carsongross 11y ago
    Objecting to his choice seems odd. There is plenty of real evidence that Javascript has many conceptual and implementation issues and is, generally, poorly thought out. That it has redeeming features is not in question, nor an excuse. Why object to it?
  - Retric 11y ago
    A few days by one person was spent on writing v1. Hundreds of years have been lost dealing with poor choices made over those days. That's not to say they did a poor job, just the timeline was crazy.
    - taeric 11y ago
      My point is you are focused on the losses, with no guarantee that other choices would have had the same gains. Basically, this is an assertion without a valid comparison to back it up. I've become too much of an empiricist in my age.
      - Retric 11y ago
        At some point it would have been to late or to complex etc. But, an extra week would have more than doubled the time he had to work with. Pretending that's going to give anything close to an optimal solution is silly.
- pjc50 11y ago
  See my https://news.ycombinator.com/item?id=11487318 https://news.ycombinator.com/item?id=11487318 on software mutualism.
carsongross 11y ago
Three other social aspects I can think of that contribute to bad software are: * "We have to do something!" - The idea that software can't be done and need only minor modifications/updates in order to be relevant and useful. Churn is confused with progress (see parts of the javascript community, or desktop software after 2000) * "This code sucks, toss it." - Something that I'm certainly guilt of, in violation of the Chesterton dictum “Don’t ever take a fence down until you know the reason why it was put up”. This is in tension with the third point you mention. * "Polishing sucks." - Once something is done, polishing (refactoring, simplifying and tidying) can be viewed as tedious and unbecoming of a creative genius such as ourselves. Large amounts of mental effort are put into small simplifications. Of course, over time, these simplifications compound and lead to truly special code, but nobody really cares about that. We are too busy learning the next framework.
- sievebrain 11y ago
  I think the first one is 95% of the explanation for the state of iTunes. iTunes was essentially done a long time ago, but it's rare to encounter software teams that will go to their manager and say "our product is perfect. we shouldn't work on it anymore". And if you have a product that's done but you still need to work on it, what do you change? You change the parts where improvement is most subjective and hard to measure: like the UI.
  - AnimalMuppet 11y ago
    It is also rare to find managers that will stop monkeying with the product.
Grishnakh 11y ago
I think another big, big factor you're missing is people wanting to justify their existence, or "change for the sake of change". For proprietary software, we see this in several ways: existing teams and managers want to keep their jobs, so they're not going to say, "this product is excellent and we're calling it done. We recommend that you keep Joe around to maintain it, and lay off the rest of us because we're not needed here any more. Joe will report to a different manager, so you can lay off Jim too. Sorry Jim, good luck finding another cushy middle-management job elsewhere!" The other, related dynamic with proprietary software is wanting their software to seem "up-to-date", and giving customers a reason to keep "upgrading". Is this year's Photoshop really that much better than the one from 2 years ago? Probably not, but you're not going to get customers to keep paying over and over for your product if you don't keep making "upgrades". So you end up shoving all kinds of bloat in there and then trying to sell customers on paying for an "upgrade". You don't see a lot of this stuff as much in the F/OSS world, since for a lot of projects, people aren't getting a salary for their work. But F/OSS isn't immune to it: take a look at Gnome3 for a prime example of fixing something that wasn't broken (and ending up with something that's far worse). But the causes for this aren't quite so clear-cut as in the commercial world. Part could be due to idealistic developers wanting to prove they have a better vision. But part could also be that, combined with getting a salary for it: most of the prominent Gnome developers are employed by Red Hat, so they've managed to sucker someone with money into funding their pet project. You don't see this with a lot of other F/OSS where there is no real funding. vim, for instance, has been chugging along for a couple decades now with not too many changes since it's mostly been done by one guy. There are a couple projects to replace it, but they don't have big corporate funding so they're just products of small teams of idealists and aren't moving that fast. A lot of F/OSS projects just don't have much work on them at all; they're in security maintenance mode only, and only see updates when someone finds some little bug or a security vulnerability. When was the last time TeX had any noticeable changes? Yet lots of academics use it every day.
- digi_owl 11y ago
  With both proprietary and FOSS code, the architecture astronauts gets all the praise, while the code janitors go ignored. End result is that doing maintenance gets ignored, while features and bottom up rewrites happen at irregular intervals. Perhaps the one thing that has made the Linux kernel so popular, while user space seems to get reinvented over and over, is that Torvalds insist that once a user space interface has been established, it stays in, unchanged, as long as someone somewhere use it. But user space itself do not hold themselves to that policy. And thus you have all the fretting about the program devs wanting the latest libs because older versions have a different interface etc, even between minor versions. Damn it, look at Microsoft. Only with Windows 8 did they retire the 16 bit Windows stuff that has been around since Windows 3.1 (or even longer), and even then only on 64-bit installs. This is why MS keeps being used around the world. Not because the UI is nice and shiny, not because it all those user helping niceties, but because people can continue doing their thing their way.
CrackpotGonzo 11y ago
What are some examples of well maintaned/upgraded software, if any, that you know of?

panic 11y ago

The problem of software quality is complicated and difficult to reduce to a single set of issues. I don't think anything you've said here contradicts what Seth wrote. I think he's right, though, that economics is the fundamental problem. We bang out code quickly to meet deadlines measured in months despite the decades-long impact a poor decision can have (see JavaScript for example). When we find ourselves slowing down, we add more people to write more code; why are we surprised when our software becomes bloated? But if we missed our deadlines too much, we'd lose the market to our competitor, who wrote their software more quickly. And if we didn't hire more programmers, we'd lose again to our competitor, who hired tons of people to add attractive features. It seems impossible to write good software without losing in the free market. IMO we should be thinking about how to support software projects outside of market-based corporations.

taeric 11y ago
JavaScript seems an odd choice for an example. Sure, you can look only at the oddities of the language, but you could also look at it as the choice to allow dynamic scripting in web pages. At that level, it has been a hugely enabling choice that I would not label as a poor decision. That is, there is no real evidence that any other choice would have obviously gone better. Why assert it?
- carsongross 11y ago
  Objecting to his choice seems odd. There is plenty of real evidence that Javascript has many conceptual and implementation issues and is, generally, poorly thought out. That it has redeeming features is not in question, nor an excuse. Why object to it?
- Retric 11y ago
  A few days by one person was spent on writing v1. Hundreds of years have been lost dealing with poor choices made over those days. That's not to say they did a poor job, just the timeline was crazy.
  - taeric 11y ago
    My point is you are focused on the losses, with no guarantee that other choices would have had the same gains. Basically, this is an assertion without a valid comparison to back it up. I've become too much of an empiricist in my age.
    - Retric 11y ago
      At some point it would have been to late or to complex etc. But, an extra week would have more than doubled the time he had to work with. Pretending that's going to give anything close to an optimal solution is silly.
pjc50 11y ago
See my https://news.ycombinator.com/item?id=11487318 https://news.ycombinator.com/item?id=11487318 on software mutualism.

carsongross 11y ago

Three other social aspects I can think of that contribute to bad software are: * "We have to do something!" - The idea that software can't be done and need only minor modifications/updates in order to be relevant and useful. Churn is confused with progress (see parts of the javascript community, or desktop software after 2000) * "This code sucks, toss it." - Something that I'm certainly guilt of, in violation of the Chesterton dictum “Don’t ever take a fence down until you know the reason why it was put up”. This is in tension with the third point you mention. * "Polishing sucks." - Once something is done, polishing (refactoring, simplifying and tidying) can be viewed as tedious and unbecoming of a creative genius such as ourselves. Large amounts of mental effort are put into small simplifications. Of course, over time, these simplifications compound and lead to truly special code, but nobody really cares about that. We are too busy learning the next framework.

sievebrain 11y ago
I think the first one is 95% of the explanation for the state of iTunes. iTunes was essentially done a long time ago, but it's rare to encounter software teams that will go to their manager and say "our product is perfect. we shouldn't work on it anymore". And if you have a product that's done but you still need to work on it, what do you change? You change the parts where improvement is most subjective and hard to measure: like the UI.
- AnimalMuppet 11y ago
  It is also rare to find managers that will stop monkeying with the product.

Grishnakh 11y ago

I think another big, big factor you're missing is people wanting to justify their existence, or "change for the sake of change". For proprietary software, we see this in several ways: existing teams and managers want to keep their jobs, so they're not going to say, "this product is excellent and we're calling it done. We recommend that you keep Joe around to maintain it, and lay off the rest of us because we're not needed here any more. Joe will report to a different manager, so you can lay off Jim too. Sorry Jim, good luck finding another cushy middle-management job elsewhere!" The other, related dynamic with proprietary software is wanting their software to seem "up-to-date", and giving customers a reason to keep "upgrading". Is this year's Photoshop really that much better than the one from 2 years ago? Probably not, but you're not going to get customers to keep paying over and over for your product if you don't keep making "upgrades". So you end up shoving all kinds of bloat in there and then trying to sell customers on paying for an "upgrade". You don't see a lot of this stuff as much in the F/OSS world, since for a lot of projects, people aren't getting a salary for their work. But F/OSS isn't immune to it: take a look at Gnome3 for a prime example of fixing something that wasn't broken (and ending up with something that's far worse). But the causes for this aren't quite so clear-cut as in the commercial world. Part could be due to idealistic developers wanting to prove they have a better vision. But part could also be that, combined with getting a salary for it: most of the prominent Gnome developers are employed by Red Hat, so they've managed to sucker someone with money into funding their pet project. You don't see this with a lot of other F/OSS where there is no real funding. vim, for instance, has been chugging along for a couple decades now with not too many changes since it's mostly been done by one guy. There are a couple projects to replace it, but they don't have big corporate funding so they're just products of small teams of idealists and aren't moving that fast. A lot of F/OSS projects just don't have much work on them at all; they're in security maintenance mode only, and only see updates when someone finds some little bug or a security vulnerability. When was the last time TeX had any noticeable changes? Yet lots of academics use it every day.

digi_owl 11y ago
With both proprietary and FOSS code, the architecture astronauts gets all the praise, while the code janitors go ignored. End result is that doing maintenance gets ignored, while features and bottom up rewrites happen at irregular intervals. Perhaps the one thing that has made the Linux kernel so popular, while user space seems to get reinvented over and over, is that Torvalds insist that once a user space interface has been established, it stays in, unchanged, as long as someone somewhere use it. But user space itself do not hold themselves to that policy. And thus you have all the fretting about the program devs wanting the latest libs because older versions have a different interface etc, even between minor versions. Damn it, look at Microsoft. Only with Windows 8 did they retire the 16 bit Windows stuff that has been around since Windows 3.1 (or even longer), and even then only on 64-bit installs. This is why MS keeps being used around the world. Not because the UI is nice and shiny, not because it all those user helping niceties, but because people can continue doing their thing their way.

CrackpotGonzo 11y ago

What are some examples of well maintaned/upgraded software, if any, that you know of?