Choose Boring Technology (2015)

My internal devops group has this issue. We had a working system on teamcity and the hashicorp stack and linkerd. Now we are working on a brand new system using gitlab and openshift and istio. Highly redundant with, from my perspective, only incremental advantage. At the beginning I spoke out against this, but failed to convince anyone. Progress has been alright because of our new 10x hire who hated the old tech and loves the new stuff. But once he is out of the picture, we will be maintaining two highly redundant stacks both requiring deep technical knowledge to maintain effectively. I guess bailing is always an option, but I would prefer to be a force for good somehow. Any suggestions?

Actually, also as an engineer much happiness comes from shipping products. Also, happiness comes from programming as opposed to configure and/or repearing a baroque tech stack with technologies that are not needed anyway but still break every other week. The latter thing comes with anger and the desire to scold (if not worse) the persons who needlessly brought in the complexity. If you want to learn new things there is your spare time where you are welcome to experiment with whatever.

I guess it goes like this: Is there much at stake? Choose a boring technology. Is it a experiment or a toy project? Choose whatever floats your boat, knock yourself out, have fun and learn on the way.

Trying out new things makes a ton of sense. But trying them out in a domain where unforeseen consequences could potentially destroy you is not a smart move.

The one you and your team master, where all the failing modes are known and predictable

I don’t do “boring,” as much as I do “mature and robust.” I like shipping products, as opposed to just “writing” them, and shipping is boring. Lots of annoying intricacies and processes.

I’m writing a fairly large-scale app, right now.

It’s written in Swift (frontend), using IB (classic UIKit), and PHP/MySQL/Postgres (backend).

It does not use SwiftUI (shiny), or Rust (shiny, but a bit more dusty), or some form of NoSQL.

I picked standard UIKit, because I like SwiftUI, but the app has a fairly intricate and non-simple storyboard. I am not confident that SwiftUI is up to the task, and I know that IB can do it.

I’ve been writing in Swift since the day it was announced, so I already know it is up to the task, despite being a fairly new kid on the block.

I picked PHP, because I’m already quite decent with it, and, despite the hate, it is a perfectly good, performant, proven, and supported enterprise language. There’s a better than even chance the server will be swapped or rewritten in the future, so it’s a good idea to use my implementation as a PoC and architecture model, anyway. It will need to run the system during the nascent phase of the project, so it needs to be solid and secure. There’s no way I will take the risk of writing such a critical system, in a language I barely know (See this scar? I’ve done that -long story).

I picked MySQL and Postgres, because they are proven, robust databases, and can be installed on most low-cost hosting solutions (the app is for an NPO). I used PDO to interact with the databases, for security and reliability, anyway, so it’s entirely possible to add support for more databases, in the future.

Also, backend is not my specialty. What I did, was design a layered architecture that will allow future “shiny” engineers a path to replacing the engine. I wrote an abstraction layer into the server, allowing a pretty wholesale subsystem replacement. The app communicates with the server through a classic REST-like JSON API, so there’s another place for a swap. I’m not married to a system like GraphQL, with the need for dependencies; but the layered architecture allows use of GraphQL, anyway, if people really want it (it is cool and robust, but is difficult to use without some big dependencies).

Speaking of dependencies, I do everything in my power to eliminate them. I have been badly burned, in the past (not too distant, either -I had to do an emergency dependencyectomy, just a couple of weeks ago), by over reliance on dependencies. It means some extra work, on my part, but not crippling.

Speaking of boring, few things are more boring than documentation, testing and quality coding techniques. My testing code usually dwarfs my implementation code. I spend many boring hours, running tests, and examining results.

In my experience, I don’t think I’ve ever written a test that wasn’t necessary. They always expose anomalies. I just went through that, in the last week or so, as I was refactoring a legacy system for the app I’m writing. I actually encountered and fixed a couple of issues (including a really embarrassing and scary security bug) that have been in the backend for two years.

But that’s just me. WFM. YMMV.