5 ms·

Does that mean that Geniuses would be terrible software engineers, since removing complexity is seldom the right thing to do business-decision wise?

edoceo 5y ago
What? IME removing complexity removes costs. That's a good choice. I can't think of a case where it didn't happen. Of course this only works for the removable complexity, which is discovered through analysis (possibly iterative/recursive)
- alex_smart 5y ago
  Time spent removing complexity is time not spent developing features. And your users/clients care more about features than complexity (which is completely invisible to them) or even speed. They don't even care if your app runs 10 times slower than it needs to, as long as it runs at an acceptable speed. That is why software engineers are seldom rewarded at their companies for "removing complexity", only for finishing projects.
  - edoceo 5y ago
    Sounds like our companies and clients are very different. As for the feature/maintenance trade-off, a reasonable CBA will show the answer. I don't think it's quite as absolute as you've described.
  - torstenvl 5y ago
    You're right that, given a set amount of programming time, working on features versus working on performance is zero-sum. But that doesn't mean you should always work on features. If anything, it only means that feature-bloat is doubly bad, not only adding logic and binary size, but imposing opportunity cost. Most users hate features. Nobody has ever sworn at their computer because they had to make a mess in Excel to use VLOOKUP() before XLOOKUP() was invented (even though I love XLOOKUP()). Plenty of swearing happens because the computer just won't respond or it's taking whole minutes to send each email when you're trying to leave work on Friday night.
    - alex_smart 5y ago
      > Plenty of swearing happens because the computer just won't respond or it's taking whole minutes Of course, my point was that it is usually not beneficial to worry about performance until that happens. And when it does, improving the performance of the product becomes a project in its own right. Misbehaving parts of the software are diagnosed and fixed, usually by introducing even more complexity.
ratww 5y ago
No, it doesn't, and no, it isn't. As much as some people like to pretend it doesn't exist, accidental complexity is a thing, and reducing it is part of our job. Also, there are ways of removing complexity of processes before they are turned into software, but that requires talking with people and agreeing. Not every program has to do everything.
- alex_smart 5y ago
  >accidental complexity is a thing Of course it is, in fact it is pretty much all-pervasive in our field, even in very successful software companies - which makes me question whether removing it is as valuable as people make it out to be.
  - recursive 5y ago
    Even after removing some, there's still likely to be some less. It seems like it's probably good to remove it, all else being equal.
  - ratww 5y ago
    Of course it's is valuable. Complexity makes software expensive to make, so removing it is literally worth a lot of money that can be better spent making features. Nobody buys software because it's accidentally complex, they buy it because of features, quality (which is something that's also affected by complexity!), etc. The only reason complexity is prevalent is due to a shortage and geniuses (and also a shortage of "Some" too, if we're going by Alan Perlis' quote).
  - NikolaNovak 5y ago
    Yes, and I think you provided a lot of the answer. You can spend 5 years customizing off the shelf ERP software to do insane things because John in accounting and Jane in HR won't budge from weird processes they built over the decades... Or you can use that opportunity for business transformation, simplify their processes and their program, save money, reduce errors, improve responsiveness and timeliness, and generally make it a win win win. Not all complexity can be reduced of course. I can imagine self driving cars, rocket science, etc are all about critical edge cases. But when it comes to business, and particularly back office processes (where a huge amount of IT goes) , a lot of complexity is unnecessary. Each company each department each person is certain they are special, unique, and their requirements are paramount and unchangeable. But if you move around a bit you'll come to believe otherwise.
josephg 5y ago
Most things in life and programming exist on a trade off curve of goodness vs simplicity. Making the thing better means giving up simplicity. Making it simple means removing features people want. Geniuses invent new ways to get both. Those ideas permanently move the trade off curve outwards. In programming, some abstractions which have done this are: Operating systems (Abstracting away the hardware), Grace Hopper’s invention of program libraries, high level languages and compilers, HTTP and JSON, tcp/ip (replacing custom transmission protocols), and there’s lots more. Calculus and the Arabic numeral system are examples in mathematics. (It’s insanely difficult to multiply using Roman numerals!)
- alex_smart 5y ago
  >Operating systems (Abstracting away the hardware), Grace Hopper’s invention of program libraries, high level languages and compilers, HTTP and JSON, tcp/ip (replacing custom transmission protocols) How many of us get to work at such lofty problems though? >Calculus and the Arabic numeral system are examples in mathematics. Eye roll. Of course reducing complexity is the very essence of mathematics. Let us not pretend that software engineers are mathematicians.
  - josephg 5y ago
    > How many of us get to work at such lofty problems though? How many of us choose to work on such lofty problems? You can work on whatever you want, whenever you want. But lofty, unproven ideas don’t pay Google salaries. Your career is a choice, not a prison. And of course most software engineers aren’t mathematicians. We’re talking about genius - and most of us are a long way from that. Most of us are lucky if we manage to invent a couple complexity reducing concepts in our entire careers. But lots of great computer science ideas have “come down the mountain” from mathematics adjacent work. Functional programming wasn’t invented by C lovers like me. But I love closures, pure functions, and map / filter / reduce. This stuff makes certain problems lovely. And we wouldn’t have any of this without mathematically minded CS.
- patrickdavey 5y ago
  I once read a book called "simplicity" by de bono I think it was... He made the point (I think) that you do want simplicity, you don't want simplistic. That is: it should be able to do all the things you want to, but in an easy to use manner. Worth striving for I believe.
p1necone 5y ago
I think there's an unspoken implication that "complexity" refers to implementation complexity, not removing needed functionality.

edoceo 5y ago

What? IME removing complexity removes costs. That's a good choice. I can't think of a case where it didn't happen. Of course this only works for the removable complexity, which is discovered through analysis (possibly iterative/recursive)

alex_smart 5y ago
Time spent removing complexity is time not spent developing features. And your users/clients care more about features than complexity (which is completely invisible to them) or even speed. They don't even care if your app runs 10 times slower than it needs to, as long as it runs at an acceptable speed. That is why software engineers are seldom rewarded at their companies for "removing complexity", only for finishing projects.
- edoceo 5y ago
  Sounds like our companies and clients are very different. As for the feature/maintenance trade-off, a reasonable CBA will show the answer. I don't think it's quite as absolute as you've described.
- torstenvl 5y ago
  You're right that, given a set amount of programming time, working on features versus working on performance is zero-sum. But that doesn't mean you should always work on features. If anything, it only means that feature-bloat is doubly bad, not only adding logic and binary size, but imposing opportunity cost. Most users hate features. Nobody has ever sworn at their computer because they had to make a mess in Excel to use VLOOKUP() before XLOOKUP() was invented (even though I love XLOOKUP()). Plenty of swearing happens because the computer just won't respond or it's taking whole minutes to send each email when you're trying to leave work on Friday night.
  - alex_smart 5y ago
    > Plenty of swearing happens because the computer just won't respond or it's taking whole minutes Of course, my point was that it is usually not beneficial to worry about performance until that happens. And when it does, improving the performance of the product becomes a project in its own right. Misbehaving parts of the software are diagnosed and fixed, usually by introducing even more complexity.

ratww 5y ago

No, it doesn't, and no, it isn't. As much as some people like to pretend it doesn't exist, accidental complexity is a thing, and reducing it is part of our job. Also, there are ways of removing complexity of processes before they are turned into software, but that requires talking with people and agreeing. Not every program has to do everything.

alex_smart 5y ago
>accidental complexity is a thing Of course it is, in fact it is pretty much all-pervasive in our field, even in very successful software companies - which makes me question whether removing it is as valuable as people make it out to be.
- recursive 5y ago
  Even after removing some, there's still likely to be some less. It seems like it's probably good to remove it, all else being equal.
- ratww 5y ago
  Of course it's is valuable. Complexity makes software expensive to make, so removing it is literally worth a lot of money that can be better spent making features. Nobody buys software because it's accidentally complex, they buy it because of features, quality (which is something that's also affected by complexity!), etc. The only reason complexity is prevalent is due to a shortage and geniuses (and also a shortage of "Some" too, if we're going by Alan Perlis' quote).
- NikolaNovak 5y ago
  Yes, and I think you provided a lot of the answer. You can spend 5 years customizing off the shelf ERP software to do insane things because John in accounting and Jane in HR won't budge from weird processes they built over the decades... Or you can use that opportunity for business transformation, simplify their processes and their program, save money, reduce errors, improve responsiveness and timeliness, and generally make it a win win win. Not all complexity can be reduced of course. I can imagine self driving cars, rocket science, etc are all about critical edge cases. But when it comes to business, and particularly back office processes (where a huge amount of IT goes) , a lot of complexity is unnecessary. Each company each department each person is certain they are special, unique, and their requirements are paramount and unchangeable. But if you move around a bit you'll come to believe otherwise.

josephg 5y ago

Most things in life and programming exist on a trade off curve of goodness vs simplicity. Making the thing better means giving up simplicity. Making it simple means removing features people want. Geniuses invent new ways to get both. Those ideas permanently move the trade off curve outwards. In programming, some abstractions which have done this are: Operating systems (Abstracting away the hardware), Grace Hopper’s invention of program libraries, high level languages and compilers, HTTP and JSON, tcp/ip (replacing custom transmission protocols), and there’s lots more. Calculus and the Arabic numeral system are examples in mathematics. (It’s insanely difficult to multiply using Roman numerals!)

alex_smart 5y ago
>Operating systems (Abstracting away the hardware), Grace Hopper’s invention of program libraries, high level languages and compilers, HTTP and JSON, tcp/ip (replacing custom transmission protocols) How many of us get to work at such lofty problems though? >Calculus and the Arabic numeral system are examples in mathematics. Eye roll. Of course reducing complexity is the very essence of mathematics. Let us not pretend that software engineers are mathematicians.
- josephg 5y ago
  > How many of us get to work at such lofty problems though? How many of us choose to work on such lofty problems? You can work on whatever you want, whenever you want. But lofty, unproven ideas don’t pay Google salaries. Your career is a choice, not a prison. And of course most software engineers aren’t mathematicians. We’re talking about genius - and most of us are a long way from that. Most of us are lucky if we manage to invent a couple complexity reducing concepts in our entire careers. But lots of great computer science ideas have “come down the mountain” from mathematics adjacent work. Functional programming wasn’t invented by C lovers like me. But I love closures, pure functions, and map / filter / reduce. This stuff makes certain problems lovely. And we wouldn’t have any of this without mathematically minded CS.
patrickdavey 5y ago
I once read a book called "simplicity" by de bono I think it was... He made the point (I think) that you do want simplicity, you don't want simplistic. That is: it should be able to do all the things you want to, but in an easy to use manner. Worth striving for I believe.

p1necone 5y ago

I think there's an unspoken implication that "complexity" refers to implementation complexity, not removing needed functionality.