4 ms·

I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themsel

I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind. Later, I worked at a smaller company that let a young talent bring in a newer, more complex technology stack, made for solving problems at a scale they not only didn't have, but would never even aspire to reach. His reason was clearly that he wanted it on his resume; it took me a while to figure out that was his supervisor's reason for letting him do it. Both probably left soon after, leaving behind a higher maintenance load that would have helped them only if they reached a scale 1,000x bigger than there was any prospect of. These two cases (and several others like them) have convinced me that it is possible to screw this up in either of two directions. No doubt there is a good rule of thumb to determine how to get it right, but I haven't found it yet. The best I know of is, to be aware that it is very possible to get this wrong in either direction.

a-priori 4y ago
"Choose boring technologies" doesn't imply "... and then never change ever again even when it becomes obsolete and unsupported". That's where the first company went wrong. It means to choose technology components that are stable and boring (but still actively developed with a healthy community around them!). It also means to break this rule if and when that thing is important enough to your success that it makes sense to spend innovation points on it because it'll set you apart. But also recognizing that those instances are rare, and that's where good engineering judgment and leadership comes in.
- atoav 4y ago
  "Choose boring technologies" is one of those phrases that makes sense when it makes sense, unless it doesn't. I find the negative expression of the same idea much more fitting: "Don't choose technology purely out of exitement". In that negative version the word purely does the heavy lifting: If all you have as a reason to choose a thing is excitement it might be a bad choice unless you can afford a failed attempt. In reality very often the "more exciting" choice will also come with their own additional pros/cons. It might be that your exciting Rust-Webservice has a smaller community backing its components, but maybe the APIs of the few components you really interact with is such a joy to use that it will save you weeks over the Java equivalent, while giving you magnitudes faster startup times and decent testability. In programming there are so many angles to consider, that simplistic answers are rarely do reality justice. There is however the danger of wearing rose tinted glasses when weighing the cons of the more exciting solution.
- jstummbillig 4y ago
  Agreed. The first scenario really suffers from conflating "boring" with "obsolete". If anything, most exciting technology has a much higher propensity to becoming obsolete than, and also long before, most boring technology does.
  - a-priori 4y ago
    Yes I think this is the key insight: if you have two technologies that will solve your problem, both reasonably popular and actively developed, the one that is ten years old is far more likely to still be actively developed in another ten years than one that is one year old. You're using survivorship bias in your favour.
    - marcosdumay 4y ago
      Well, only if both work about as well as each other. Good technologies are likely to outsurvive bad ones once the good ones get a minimum of popularity.
- ksec 4y ago
  Yes, something like PHP / Laravel and Ruby Rails, but not Perl.
ainar-g 4y ago
I would say that technology that requires constant (re)writing of everything cannot be called boring. I could writing a project in COBOL, which is an old technology, but certainly isn't boring. Its age has actually made it “exciting” (that is, the opposite of “boring”, regardless of the actual feelings working with it would result in).
_-david-_ 4y ago
>I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind. Can you expand on this? What was the boring technology?
- rossdavidh 4y ago
  A proprietary programming language called "Natural", and an associated database called "Adabas". Both actually had some advantages, and the internal culture had developed effective ways of working around their limitations, but being proprietary, and that old, had definite downsides.
  - tim333 4y ago
    Ah - you could argue having a proprietary programming language was interesting. Boring is PHP and mysql.
deleted 4y ago
[deleted]

a-priori 4y ago

"Choose boring technologies" doesn't imply "... and then never change ever again even when it becomes obsolete and unsupported". That's where the first company went wrong. It means to choose technology components that are stable and boring (but still actively developed with a healthy community around them!). It also means to break this rule if and when that thing is important enough to your success that it makes sense to spend innovation points on it because it'll set you apart. But also recognizing that those instances are rare, and that's where good engineering judgment and leadership comes in.

atoav 4y ago
"Choose boring technologies" is one of those phrases that makes sense when it makes sense, unless it doesn't. I find the negative expression of the same idea much more fitting: "Don't choose technology purely out of exitement". In that negative version the word purely does the heavy lifting: If all you have as a reason to choose a thing is excitement it might be a bad choice unless you can afford a failed attempt. In reality very often the "more exciting" choice will also come with their own additional pros/cons. It might be that your exciting Rust-Webservice has a smaller community backing its components, but maybe the APIs of the few components you really interact with is such a joy to use that it will save you weeks over the Java equivalent, while giving you magnitudes faster startup times and decent testability. In programming there are so many angles to consider, that simplistic answers are rarely do reality justice. There is however the danger of wearing rose tinted glasses when weighing the cons of the more exciting solution.
jstummbillig 4y ago
Agreed. The first scenario really suffers from conflating "boring" with "obsolete". If anything, most exciting technology has a much higher propensity to becoming obsolete than, and also long before, most boring technology does.
- a-priori 4y ago
  Yes I think this is the key insight: if you have two technologies that will solve your problem, both reasonably popular and actively developed, the one that is ten years old is far more likely to still be actively developed in another ten years than one that is one year old. You're using survivorship bias in your favour.
  - marcosdumay 4y ago
    Well, only if both work about as well as each other. Good technologies are likely to outsurvive bad ones once the good ones get a minimum of popularity.
ksec 4y ago
Yes, something like PHP / Laravel and Ruby Rails, but not Perl.

ainar-g 4y ago

I would say that technology that requires constant (re)writing of everything cannot be called boring. I could writing a project in COBOL, which is an old technology, but certainly isn't boring. Its age has actually made it “exciting” (that is, the opposite of “boring”, regardless of the actual feelings working with it would result in).

_-david-_ 4y ago

>I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind. Can you expand on this? What was the boring technology?

rossdavidh 4y ago
A proprietary programming language called "Natural", and an associated database called "Adabas". Both actually had some advantages, and the internal culture had developed effective ways of working around their limitations, but being proprietary, and that old, had definite downsides.
- tim333 4y ago
  Ah - you could argue having a proprietary programming language was interesting. Boring is PHP and mysql.

deleted 4y ago

[deleted]