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.