4 ms·

It's turtles all the way down. Using a lightweight, comprehensible framework is good, until you hit the limits of that framework and start pulling in lots more

by beat 12y ago

It's turtles all the way down. Using a lightweight, comprehensible framework is good, until you hit the limits of that framework and start pulling in lots more libraries to fill the gaps (the Sinatra/Cuba world). Using a heavyweight, complete library is good, until you start suffering from bugs caused by incomprehensible magic buried deep inside (the Rails world). I see the same problem in microservices versus monolithic apps. If you use microservices, you have a lot of duplication and inter-component configuration management complexity. If you use monolithic apps, you get the big ball of mud. Or, as I sometimes put it, "Which kneecap do you want to get shot in?" The underlying problem isn't fashion, or bloat. It's that software is very, very complex. Unless you're doing hardcore embedded work in assembly language, you're building a raft on an ocean of code you won't read and can't understand. A friend of mine put it well once. He said that you should have deep understanding of systems one layer from yours (ie your frameworks), and at least a shallow understanding of things two or three layers away (operating systems, etc). If you don't have some grasp of the things you depend on, you're relying on magic and are vulnerable. But you can't realistically expect to know it all.

j03m1 12y ago
Which knee do you want to get shot in is the best way I've heard this explained. Ever.
- beat 12y ago
  "I don't believe in the no-win scenario." -Captain Kirk A lot of the problems we face in software engineering are Kobiyashi Maru tests. They're no-win scenarios, tests of character rather than ingenuity. There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another.
  - chongli 12y ago
    There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another. Right, but I'm not about to believe we're even close to that limit. Every day we have people writing bugs which, from a state of the art perspective, are already solved problems. It's like people are out there riding horses while others are driving past in their cars. I think it's a little better to say that a lot of the problems we face in software engineering are cultural, not technical. So many people adopt these tribalistic mindsets when discussing their preferred technologies rather than allowing themselves to be open to better ideas.
    - beat 12y ago
      Sure, there are lots of projects that are cranking out junk redundant code on legacy systems. But even if you do use the best tools, the best processes, the best analysis, the irreduceable complexity remains. For example, I have to read data from one source, and write it to another. I can have a single app provide api for both the writing source and the reading source, or I can have two separate apps and two separate apis. But I can't get away from the problem of reading and writing. That's irreduceable. If I have separate apps for the two apis, I have a configuration management issue. If I have a monolithic app that does both, I have a coupling issue. Imagining that Bleeding Edge Technology of the Month will make this go away is wishful thinking. But facing the truth is awful, so we choose the wishful thinking.
      - chongli 12y ago
        I'm not merely talking about junk redundant code but entire classes of problems such as memory errors (null pointers etc.) and race conditions (in many, though not all, cases). If you compare software engineering to another field like aerospace or structural engineering it's laughable how little rigour and formality takes place in most software. It's shocking how much disdain programmers show for mathematics which gives us the tools to prove that our applications are correct.
        dkersten 12y ago
        It's shocking how much disdain programmers show for mathematics which gives us the tools to prove that our applications are correct. I personally think these things are great but too expensive. My customers care about solving their problems not perfection. There's a balance to be struck and I'm not excusing bad software, but if the customer isn't willing to pay for better and is happy with the current quality, there is little incentive to put in this extra effort (and therefore cost) when the resources could instead be put to work on providing value in ways the customer does care about. I guess after you exceed the customers quality requirements/expectations, there are diminishing returns. I'd love to produce perfect software, but nobody will pay me to do it.
- gofishdigital 12y ago
  Maybe there's a lot of meta commentary in "Arrow to the knee" afterall?
0xdeadbeefbabe 12y ago
After reading that I feel about as lost as I did after that XKCD about correlation and causation https://xkcd.com/552/ https://xkcd.com/552/ Also, just because your comment is popular does not mean your comment is good. The popularity heuristic may be a little better than the OP suggests though, maybe.

by beat 12y ago

j03m1 12y ago

Which knee do you want to get shot in is the best way I've heard this explained. Ever.

beat 12y ago
"I don't believe in the no-win scenario." -Captain Kirk A lot of the problems we face in software engineering are Kobiyashi Maru tests. They're no-win scenarios, tests of character rather than ingenuity. There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another.
- chongli 12y ago
  There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another. Right, but I'm not about to believe we're even close to that limit. Every day we have people writing bugs which, from a state of the art perspective, are already solved problems. It's like people are out there riding horses while others are driving past in their cars. I think it's a little better to say that a lot of the problems we face in software engineering are cultural, not technical. So many people adopt these tribalistic mindsets when discussing their preferred technologies rather than allowing themselves to be open to better ideas.
  - beat 12y ago
    Sure, there are lots of projects that are cranking out junk redundant code on legacy systems. But even if you do use the best tools, the best processes, the best analysis, the irreduceable complexity remains. For example, I have to read data from one source, and write it to another. I can have a single app provide api for both the writing source and the reading source, or I can have two separate apps and two separate apis. But I can't get away from the problem of reading and writing. That's irreduceable. If I have separate apps for the two apis, I have a configuration management issue. If I have a monolithic app that does both, I have a coupling issue. Imagining that Bleeding Edge Technology of the Month will make this go away is wishful thinking. But facing the truth is awful, so we choose the wishful thinking.
    - chongli 12y ago
      I'm not merely talking about junk redundant code but entire classes of problems such as memory errors (null pointers etc.) and race conditions (in many, though not all, cases). If you compare software engineering to another field like aerospace or structural engineering it's laughable how little rigour and formality takes place in most software. It's shocking how much disdain programmers show for mathematics which gives us the tools to prove that our applications are correct.
      - dkersten 12y ago
        It's shocking how much disdain programmers show for mathematics which gives us the tools to prove that our applications are correct. I personally think these things are great but too expensive. My customers care about solving their problems not perfection. There's a balance to be struck and I'm not excusing bad software, but if the customer isn't willing to pay for better and is happy with the current quality, there is little incentive to put in this extra effort (and therefore cost) when the resources could instead be put to work on providing value in ways the customer does care about. I guess after you exceed the customers quality requirements/expectations, there are diminishing returns. I'd love to produce perfect software, but nobody will pay me to do it.
gofishdigital 12y ago
Maybe there's a lot of meta commentary in "Arrow to the knee" afterall?

0xdeadbeefbabe 12y ago

After reading that I feel about as lost as I did after that XKCD about correlation and causation https://xkcd.com/552/ https://xkcd.com/552/ Also, just because your comment is popular does not mean your comment is good. The popularity heuristic may be a little better than the OP suggests though, maybe.