4 ms·

I've been meaning to give a lightning talk about a related subject someday, called "Why Software Sucks". Basically, software hovers along the fuzzy line betwee

by beat 8y ago

I've been meaning to give a lightning talk about a related subject someday, called "Why Software Sucks". Basically, software hovers along the fuzzy line between "barely works" and "doesn't work". When we start a project, it doesn't work. We add code until it barely works. Then we break it, so it doesn't work. So we add enough scaffold that it barely works and can support the new features, until we break it again, and the cycle begins anew. This is actually embedded as principle in TSTTCPW (the simplest thing that could possibly work), but attempts to waterfall our way out by careful planning are generally doomed, due to unintended consequences and such. Eventually, the software becomes broken and no longer worth fixing (and thus gets abandoned), or it hits feature complete while (barely) working. And what happens when it's "complete"? Do we say "Thank goodness, finally I can go fix all those bugs and design flaws!"? No, never. Instead, we drop that blecherous losing piece of crap as fast as we can and go start on the shiny new project that's been cooking in our minds, the one we couldn't work on because we were hacking our way through the wretched ball of mud that is our old code, wasting time in frustration and shame, just to get it off our plate. So we start working on the shiny new thing. And this time, the code will be good. This time, it won't suck. Yeah, right.

cntlzw 8y ago
A lightning talk I would love to attend.
fjsolwmv 8y ago
The whole world hovers between barely works and doesn't work. That's the theory of evolution that explains the history of life.
- gglitch 8y ago
  Nice observation. I would enjoy a Tao of System Design that coyly smiles and says, The architecture that can be defined is not the true architecture.
  - gmfawcett 8y ago
    It's not nearly as pithy, but I think that this line from "Big Ball of Mud" captured something essential: > "Architecture is a hypothesis about the future that holds that subsequent change will be confined to that part of the design space encompassed by that architecture." http://laputan.org/mud/mud.html#Forces http://laputan.org/mud/mud.html#Forces
- beat 8y ago
  EXACTLY.
gglitch 8y ago
I don't disagree with this, and I'm sure I'd promote the talk, but I'd love to see counterexamples. SQLite?
athenot 8y ago
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.
deleted 8y ago
[deleted]
nathcd 8y ago
For a (not lightning) talk on the subject, I recommend "The Mess We're In" by Joe Armstrong: https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
skybrian 8y ago
On the other hand, you have redundant systems where everything seems fine even if some parts are not working. If you don't have good monitoring, you won't notice when you break something until other things break as well. Or maybe it doesn't stop working and you just have mysterious brownouts or irreproducible bugs? Generally speaking, programming is easier when you have clear feedback. Things either work or they don't, and you don't have to do a lot of expensive testing to gather statistics to show there's a bug.
- erikpukinskis 8y ago
  I wouldn't say that redundancy is the alternative to brittleness. The altnernative is smaller code, less tightly coupled, that uses fewer libraries and more beginner level language constructs. There's no technical impediment to that. It's actually less work technically. It's just hard to design that way, because you have to actually understand your domain much more deeply. That's where stability comes from, not redundancy but the opposite of that. Fewer parts, better understood.
  - skybrian 8y ago
    In a minimalist design, everything has a purpose, so if you remove it, it breaks. That seems good. And yet, brittleness is supposed to be bad. How is it different?
    - erikpukinskis 8y ago
      I would say minimal means something like "just enough flexibility to support one stated use in all predictable contexts". Brittle means "not enough flexibility, so it breaks in some contexts". Removing a component is not a stated use. If a component can be removed during the stated use then that's not minimal, it needs more thought or parts.

by beat 8y ago

cntlzw 8y ago

A lightning talk I would love to attend.

fjsolwmv 8y ago

The whole world hovers between barely works and doesn't work. That's the theory of evolution that explains the history of life.

gglitch 8y ago
Nice observation. I would enjoy a Tao of System Design that coyly smiles and says, The architecture that can be defined is not the true architecture.
- gmfawcett 8y ago
  It's not nearly as pithy, but I think that this line from "Big Ball of Mud" captured something essential: > "Architecture is a hypothesis about the future that holds that subsequent change will be confined to that part of the design space encompassed by that architecture." http://laputan.org/mud/mud.html#Forces http://laputan.org/mud/mud.html#Forces
beat 8y ago
EXACTLY.

gglitch 8y ago

I don't disagree with this, and I'm sure I'd promote the talk, but I'd love to see counterexamples. SQLite?

athenot 8y ago

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.

deleted 8y ago

[deleted]

nathcd 8y ago

For a (not lightning) talk on the subject, I recommend "The Mess We're In" by Joe Armstrong: https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4

skybrian 8y ago

On the other hand, you have redundant systems where everything seems fine even if some parts are not working. If you don't have good monitoring, you won't notice when you break something until other things break as well. Or maybe it doesn't stop working and you just have mysterious brownouts or irreproducible bugs? Generally speaking, programming is easier when you have clear feedback. Things either work or they don't, and you don't have to do a lot of expensive testing to gather statistics to show there's a bug.

erikpukinskis 8y ago
I wouldn't say that redundancy is the alternative to brittleness. The altnernative is smaller code, less tightly coupled, that uses fewer libraries and more beginner level language constructs. There's no technical impediment to that. It's actually less work technically. It's just hard to design that way, because you have to actually understand your domain much more deeply. That's where stability comes from, not redundancy but the opposite of that. Fewer parts, better understood.
- skybrian 8y ago
  In a minimalist design, everything has a purpose, so if you remove it, it breaks. That seems good. And yet, brittleness is supposed to be bad. How is it different?
  - erikpukinskis 8y ago
    I would say minimal means something like "just enough flexibility to support one stated use in all predictable contexts". Brittle means "not enough flexibility, so it breaks in some contexts". Removing a component is not a stated use. If a component can be removed during the stated use then that's not minimal, it needs more thought or parts.