Slashdot Mirror
Why You Should Choose Boring Technology
An anonymous reader writes Dan McKinley, a long-time Etsy engineer who now works at online payment processor Stripe, argues that the boring technology option is usually your best choice for a new project. He says, "Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble. ... The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."
In about 1996, Oracle introduced the "Oracle Webserver", allowing you to serve dynamic webpages generated from stored procedures in the database. The beauty of this is that all of your website code is in the database, making it centrally managed and all application security logic is enforced by the database. The webserver is just a dumb client with no code, and has no permissions on any database tables.
In 2001, it was now a mod for Apache and as since been opensourced (mod_owa). I convinced our client try it for a central website that we were developing, as the middle tier crap they were using didn't work. That system went live 2 weeks later with a few very simple webpages. It has been in production ever since and the website has over 50k users and 20+m hits a day.
"Be grateful for what you have. You may never know when you may lose it."
I think it is important enough to have atleast one 'skunk-works' type project that every developer needs to work on, just to keep up with what will be boring a year or two down the road.
I avoided "not boring" for a couple of years and for the last month, while I look at hybrid mobile apps, I am stunned by my lack of knowledge and the abundance of terms, concepts and technologies that mean nothing to me ... angular, ionic, grunt, promises, JSX, reactjs, compass, gulp, firebase... the list could go on and on and on, these are just things I've started researching over the last few weeks, to make sure I make the right choice.
Every organisation needs a "not boring" slot of time for their developers. Not for product that needs to ship NOW.. but for stuff that may need to ship next year.
Yes. I know this for a fact. I'm going through this right now.
Oh, this new NoSQL database is SO fast and wonderful. Except you can't get it to replicate without an Enterprise version, the price of which no one actually calculated into the cost per user budget. Because it's free and open source, except when it's not.
And you need to have at least three servers to run it even without replication. And no, I am not talking about sharding. I mean running a standard one instance of this garbage requires three instances.
Mind you, if you want NoSQL, there are versions out there that have replica sets for free and somehow manage to complete all standard operations with only one server. But we can't use those. No. They're too boring and predictable and STABLE. Not exciting at all.
Not blaming the current developers, who are left with the pile of shit that the other developers made while having all sorts of fun trying shit out and making everyone else figure out how to actually make it *work*.
The last job, they were circling the toilet bowl because we couldn't finish features. Yet their brilliant idea was to switch their technology, and even change from svn to git, and also chef to ansible. This for no discernible reason, other than the fact that it just seemed like a good idea to them at the time.
Bear in mind, I understand why you might want git or ansible or whatever new libraries, but I'd think that we could wait to redesign our whole build process and switch to a new version control system until after we had enough finished features to attract a customer. Or something.
A lot of good people lost their jobs because some architects and a certain CTO wanted to wank off about how bleeding edge they were. Of course, that dumbass still has a job. I hear they're considering a mobile app now. Or something. Good luck with making an app when you laid off all the testers.
With all that talk, you'd think I had gotten laid off. Luckily I managed to get the hell out, but all the people I worked with there got canned a few weeks later. And none of them were fuck-ups. That is the price of not understanding how to maintain a solid foundation to build a project on.
So yeah. Boring. Functional. Boring tech behind your app or site doesn't make it a bad. Bad design does that. Lack of features does that. Failure to understand operating an application on something more complex than your MacBook does that.
The fact that you using the latest thing does NOT make your app good without you knowing what the fuck you are doing.
Personally I think that one of the problems with software development is that we don't treat it like engineering enough. Not engineering in the sense of building a bridge, but engineering in the sense of design (designing a circuit for example). Engineering is inherently a pragmatic discipline where creativity is constrained by various physical, budgetary, and time constraints. Because software has less of the physical constraints, I think that the "art" side can get a little carried away at times. But the main issue is lack of discipline; and that is more of an artefact of the culture that can be associated with software development, rather than anything inherent in the work itself. I'm biased (with an engineering background), but I think that many software companies could benefit from the attitude that comes with engineering.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan