3 ms·

This really depends on the kind of industry. If we follow the money trail, software exists to achieve a business goal, either directly or indirectly. As with mo

This really depends on the kind of industry. If we follow the money trail, software exists to achieve a business goal, either directly or indirectly. As with most things in business, what matters is "good enough". Some software exists outside of this environment, usually because it is beholden to an impeccable level of quality (defined as never caught in a non-deterministic state, resillient, etc). This can be: — software used by millions of people, all poking at obscure edge cases; — software used by lots of other software, for the same reasons; — software commissioned by high stakes businesses (space, life-support systems...), where the amount of life or money lost, should the software fail, is simply unacceptable. This in turn guides what I decide to work on. If your employer/client views your software purely as a cost center, you can guarantee the quality you are allowed to deliver will always remain mediocre. Good enough to support the business but no more. I learned to stay away from those industries.

hellisothers 8y ago
As I was reading this post I was about to reply with something similar but you nailed it. The vast majority of software written isn’t there just to be pretty, it serves a business goal and as long as that goal is met (on time!) and the cost of supporting it is within budget then why fix something that isn’t broken.
beat 8y ago
I used to work on a system that moved a hundred billion dollars a day. Yes, billion. Downtime costed thousands of dollars a minute simply in floating interest from money not moving, and a serious outage could damage the entire economy. That's some serious high availability requirements. For purposes of its extreme performance and availability requirements, it barely worked. That doesn't mean it was bad code! It was great code. But it could have been better. It could have been much better. And it wasn't, because once it met those requirements, work got applied to expanding its feature set instead. Which was, in a way, also a requirement. Pick any "impeccable level of quality" system, and you'll find the same thing. Heart monitors. Mars launches. Whatever. The software barely works, given the difficulty of the requirements. I'd argue that it's actually irresponsible for businesses to try to do any better than that! The cost of bouncing the rubble with code quality is a resource that could be much better spent on other things. Think of it in terms of the 80/20 rule. Dig into that last 20%, and you'll spend 80% of your effort on it. It's not a good tradeoff. The Pareto Principle isn't a measure of how bad we are, it's a measure of how good we are. When we attend to its wisdom, we get the most work done. edit: Scope is not the only requirement. Schedule is also a requirement! Pareto Principle again! Taking four times as long to get 20% better code is failure. We don't just have to create features. We create features with the resources we have, the technology we have, the people we have, within the schedule we have. A blown schedule is a failed requirement. Software not delivered on time is, in fact, broken.
- faitswulff 8y ago
  What do you mean by barely working (and as a corollary, does it even make sense for it to do more than that)? The spectrum of correctness seems quite limited; you said it yourself, software starts out not working, and then when it's correct, it works. It seems pretty binary to me. Do you mean that the software is brittle, doesn't handle edge cases, has bugs, etc? It seems to me that once software is correct, there's not much more to do in terms of working.
  - beat 8y ago
    Yes, I mean brittleness, inability to handle edge cases, etc. Oftentimes, this means that it's boxed-in and can't grow in certain necessary directions without major rework. For example, take a deployment configuration where the target environments are hardcoded, with duplicate-minus-variation configuration files. Works fine, for the existing environments. But it can't handle a new one, not without duplicating again. Correcting this means going to some sort of a template configuration with parameters in a data store. Bit rot is part of this. Works fine in Windows 10, but it'll fail come Windows 11, etc. And yes, part of what I'm arguing is that it doesn't even make sense for software to be better than barely working. I've hit a point where I think code that works too well is a project management smell.
- cleong 8y ago
  By definition wouldn't all bridges "barely work"? Yes it's spec'd to handle X load, now putting X+1 might cause some damage because it was never tested or designed for X+1.
  - jungler 8y ago
    All bridges follow similar designs, even if their implementations are original. Digital systems tend to fail in original ways all the time, because the design is something intentionally new. If it weren't, you'd just copy the existing software. Which doesn't mean that we have no reusable or generalizable quality metrics - we do. But they tend to express things that correlate to an abstract of quality, and not a failure threshold. The most honest systems in software are the ones that do not scale, because they have built in their hard failure point - and from that, tolerance metrics similar to bridges can be predicted and planned for. It's software that has to do everything in a multitude of configurations at great speed that runs into deep architectural issues, because it hypothesizes a bridge that will someday tolerate an infinite load.

hellisothers 8y ago

As I was reading this post I was about to reply with something similar but you nailed it. The vast majority of software written isn’t there just to be pretty, it serves a business goal and as long as that goal is met (on time!) and the cost of supporting it is within budget then why fix something that isn’t broken.

beat 8y ago

I used to work on a system that moved a hundred billion dollars a day. Yes, billion. Downtime costed thousands of dollars a minute simply in floating interest from money not moving, and a serious outage could damage the entire economy. That's some serious high availability requirements. For purposes of its extreme performance and availability requirements, it barely worked. That doesn't mean it was bad code! It was great code. But it could have been better. It could have been much better. And it wasn't, because once it met those requirements, work got applied to expanding its feature set instead. Which was, in a way, also a requirement. Pick any "impeccable level of quality" system, and you'll find the same thing. Heart monitors. Mars launches. Whatever. The software barely works, given the difficulty of the requirements. I'd argue that it's actually irresponsible for businesses to try to do any better than that! The cost of bouncing the rubble with code quality is a resource that could be much better spent on other things. Think of it in terms of the 80/20 rule. Dig into that last 20%, and you'll spend 80% of your effort on it. It's not a good tradeoff. The Pareto Principle isn't a measure of how bad we are, it's a measure of how good we are. When we attend to its wisdom, we get the most work done. edit: Scope is not the only requirement. Schedule is also a requirement! Pareto Principle again! Taking four times as long to get 20% better code is failure. We don't just have to create features. We create features with the resources we have, the technology we have, the people we have, within the schedule we have. A blown schedule is a failed requirement. Software not delivered on time is, in fact, broken.

faitswulff 8y ago
What do you mean by barely working (and as a corollary, does it even make sense for it to do more than that)? The spectrum of correctness seems quite limited; you said it yourself, software starts out not working, and then when it's correct, it works. It seems pretty binary to me. Do you mean that the software is brittle, doesn't handle edge cases, has bugs, etc? It seems to me that once software is correct, there's not much more to do in terms of working.
- beat 8y ago
  Yes, I mean brittleness, inability to handle edge cases, etc. Oftentimes, this means that it's boxed-in and can't grow in certain necessary directions without major rework. For example, take a deployment configuration where the target environments are hardcoded, with duplicate-minus-variation configuration files. Works fine, for the existing environments. But it can't handle a new one, not without duplicating again. Correcting this means going to some sort of a template configuration with parameters in a data store. Bit rot is part of this. Works fine in Windows 10, but it'll fail come Windows 11, etc. And yes, part of what I'm arguing is that it doesn't even make sense for software to be better than barely working. I've hit a point where I think code that works too well is a project management smell.
cleong 8y ago
By definition wouldn't all bridges "barely work"? Yes it's spec'd to handle X load, now putting X+1 might cause some damage because it was never tested or designed for X+1.
- jungler 8y ago
  All bridges follow similar designs, even if their implementations are original. Digital systems tend to fail in original ways all the time, because the design is something intentionally new. If it weren't, you'd just copy the existing software. Which doesn't mean that we have no reusable or generalizable quality metrics - we do. But they tend to express things that correlate to an abstract of quality, and not a failure threshold. The most honest systems in software are the ones that do not scale, because they have built in their hard failure point - and from that, tolerance metrics similar to bridges can be predicted and planned for. It's software that has to do everything in a multitude of configurations at great speed that runs into deep architectural issues, because it hypothesizes a bridge that will someday tolerate an infinite load.