How boring should your team's codebases be

The new one had "hand rolled cryptography", which should make you twitch uncontrollably if you know anything about security.

The new application had, among other failings, hard-coded (unchangeable!) RSA keys used for communication channels. As in, all customers shared the same keys. I can't remember the exact specifics, but I swear at some point there was something like encrypted JSON in XML. Or was it encrypted XML in JSON? Does it matter which?

The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing.

You don't want to know what happened to the new app when it was tested with malicious inputs.

The testing team were told "not to go too hard on it", because that would "derail the project".

This just feels like bad development and isn't unlike being given a random .properties/.ini file with no explanations of what the values mean. Sounds like someone didn't do their job, or the processes to encourage (require) them to do so weren't in place.

> For onboarding new members, I would have thought it preferable to have a JSON configuration, where both documentation and validation of configuration options are provided by a JSON Schema file.

You know, this can work, but then you need your applications to be able to read that file and feeding it in through your container management solution (which many use for a variety of reasons) wouldn't be as easy. Even without containers, you'd still need to look out so you don't end up with 20 JSON files all of which might need to be changed for a new environment.

Honestly, something like JSON5 https://json5.org/ was pretty cool because of added comments, but otherwise JSON is a bit cumbersome to use. That said, some web servers like Caddy have gone for accepting JSON configuration as well, which lends itself nicely to automation, so it's still a valid approach: https://caddyserver.com/docs/json/

Then a lesson in this case is to use large corporate approved technologies, regardless of how inefficient, costly and complex they might be.

Programmers always insist that the new flavor of X solves a ton of pain. Occasionally they are right, but more often than not programmers adopting four new technologies- if they ship at all - deliver what Rich Hickey called “a knit house” in one of his talks: a system that solves a problem, sometimes in a pretty way, but is never able to be extended or grow. Sometimes the actual software is fine enough, but the choices are so novel that it ends up being maintained by one or two people who get it, and growing the team is a nightmare. Either way, it’s a knit house.

Here's some of the things we encounter:

* A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them.

* Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases.

* Complex code can be a hindrance to onboarding new developers. Boring code can be a hindrance to onboarding new features.

* You often end up in a situation where you're reinventing the wheel and you're spending increasing amounts of development time on keeping the wheel round. At some point you've got to consider a ready-made solution to your problem or consider hiring more people to deal with it.

* Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high.

Creating a company off the back of a flavour-of-the-month tech stack isn't a good idea. But I can't see how any large software company can scale without having a bit of spice somewhere.