3 ms·

Rather than lazy programmers or evil managers, I think what primarily stops us keeping software simple is that we often seek to model complex systems, or code c

Rather than lazy programmers or evil managers, I think what primarily stops us keeping software simple is that we often seek to model complex systems, or code complex problems. Given this, the “wrong tool (technology or language) for the job” simply complicates the already complex?

astrobe_ 4y ago
Every time I have let complexity live, or increased it in a program, it was due to deadlines, bugs in third party software, artificial complexity in third party interfaces, fear of touching a part that's a "ball of mud"... Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. TFA talks about artificial vs essential complexity, with the term "impedance" being used to talk about artificial complexity introduced by the tool being used, typically the programming language. As the author notes, the tool being chosen is partly a political choice. The paradox they talk about, is that e.g. doing CGI in C is "wrong", but on the other hand if you are extremely good at C, you might be more productive than using, say Perl. Between the lines of TFA, you read because productivity. The "wrong" tool is a local optimum (of your all-C shop). If you want to go after the global optimum, you need training. And that's another political decision - which can be tough to make, because as typically don't have expertise in the field, you don't know what's right and are likely to fall for fads or new hires that supposedly brings that expertise to you.
- Beldin 4y ago
  This reminds me of the 737 MAX. It was deliberately designed to have a flight profile very close to the original 737 so as not to require retraining pilots. That worked adequately, but not good enough. (The MCAS system would have been different or even absent if pilot retraining was done anyway.) Basically, they tried this approach but didn't recognise they crossed the threshold where letting go of old flight characteristics makes sense.
- acdha 4y ago
  > Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. Where I’ve seen gratuitous complexity introduced by the technical staff it’s been a situation where a 1.5x programmer thought they were being 10x when they larded up the architecture early, leaving the project behind schedule seemingly without enough time to fix it. The problem wasn’t the average programmer but letting the one a bit above average set the direction.
revskill 4y ago
Because 10x programmers/architects tell us to do so.

astrobe_ 4y ago

Every time I have let complexity live, or increased it in a program, it was due to deadlines, bugs in third party software, artificial complexity in third party interfaces, fear of touching a part that's a "ball of mud"... Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. TFA talks about artificial vs essential complexity, with the term "impedance" being used to talk about artificial complexity introduced by the tool being used, typically the programming language. As the author notes, the tool being chosen is partly a political choice. The paradox they talk about, is that e.g. doing CGI in C is "wrong", but on the other hand if you are extremely good at C, you might be more productive than using, say Perl. Between the lines of TFA, you read because productivity. The "wrong" tool is a local optimum (of your all-C shop). If you want to go after the global optimum, you need training. And that's another political decision - which can be tough to make, because as typically don't have expertise in the field, you don't know what's right and are likely to fall for fads or new hires that supposedly brings that expertise to you.

Beldin 4y ago
This reminds me of the 737 MAX. It was deliberately designed to have a flight profile very close to the original 737 so as not to require retraining pilots. That worked adequately, but not good enough. (The MCAS system would have been different or even absent if pilot retraining was done anyway.) Basically, they tried this approach but didn't recognise they crossed the threshold where letting go of old flight characteristics makes sense.
acdha 4y ago
> Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. Where I’ve seen gratuitous complexity introduced by the technical staff it’s been a situation where a 1.5x programmer thought they were being 10x when they larded up the architecture early, leaving the project behind schedule seemingly without enough time to fix it. The problem wasn’t the average programmer but letting the one a bit above average set the direction.

revskill 4y ago

Because 10x programmers/architects tell us to do so.