Choose Boring Technology

I don't believe that the only reasonable alternative to that is to "choose boring tech" though. Like so many things in life, it's very contextual, and this is where you need someone with a lot of background and war wounds who can discern valuable improvements from yet-another-CADT-library-rewrite. Sometimes they're hard to differentiate from an old crusty cynic though.

I'm resistant to either pole - I think there's often a 'middle way', where you can leverage proven, high-quality software (think PostgreSQL) while still benefiting from modern approaches (pragmatic functional idioms, etc). I'm old enough to remember when the industry was generally more entrenched in ossified approaches - it definitely has its downsides too!

The hard part is when a (supposedly) proven technology turns out to be a turd. Much of the job of choosing good tech appears to be using heuristics to avoid low quality tech with good marketing. I'd love to have better tools to guide that problem!

~ Dijkstra (1988) "On the cruelty of really teaching computing science" (EWD1036).

- I reported 5 bugs, and they were all ignored, so I'm not going to report any more now. It'd just be a waste of my time.

- I reported a bug, and in the process of fixing that, the developer broke something else even worse. (In one case, it turned a "delete some" button into a "delete all" button which caused a minor catastrophe for all users.) Now I want the developer to not touch anything. I know what little bugs exist in the system, and I've come up with my own ways to work around them, thank you very much.

- As a consequence of some other bug fix, it came to light that the developer has no backups. (I don't have sufficient pull to fix that underlying problem.) I want the developer to not touch anything.

- The users aren't the buyers, and it's easy for the buyers to know where to report bugs, but that information is hidden from the users. As a result, all of the bugs that cropped up during demos (for or by C-level execs and VPs) are fixed, but nothing beyond that.

- We brought on new users, and they don't know that the software is custom built (2 months ago!), so they don't know it's possible to file bug reports. Or they don't know where to report them. Or they're afraid it's going to be onerous. Whatever the reason, they think this program has always been around and can't be changed.

- Maybe the process really is onerous. One company has gotten increasingly naggy about all bug reports including a 1/2GB blob of logs and other PII that takes several minutes to generate. Even when I just want to report "there's no way to do X, and there should be a way to do X", I get nagged 3 or 4 times to include this diagnostic blob, and it's implied that my bug won't get much attention without one. I only rarely report bugs to that company these days.

- Since the early days of a popular website, the keyboard shortcuts were supremely annoying. In the interests of being supportive of that great new venture, I only reported issues which caused the system to be completely unusable. Later, when the major issues had been ironed out and people did report that stealing and remapping all the standard OS text editing keys was maybe not the nicest thing to do, we were told the system was 3 years old already and by now someone else "would surely complain if it was an annoying problem".

In other words, everyone from users to developers comes to depend on the status quo. The softness of software is a benefit during initial development, but mostly just a liability later. We value the status quo even more than quality.

"And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is."

Yup. You get the freedom to choose a language and/or database with unknowns but you lose the freedom to leave work at a reasonable hour to see your family, pursue a hobby, or just veg out. Experimenting with new (to your organization) languages and infrastructure pieces is something you do between projects, not during.

It reminds me of something a jazz musician said in an interview, "The audience doesn't pay to see you rehearse. Rehearsal is done on your own time away from audiences." Rehearsals are where you try new techniques, harmonies, instruments, etc.