The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (or could bankrupt you).
All of that said, today's tech landscape is far less edgy than the early days of cloud, NoSQL, and NodeJS. I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI.
Biggest time wasters and innovation token consumers IMO is third-party vendors, especially shiny startups/products.
Don't waste your time, money and energy being someone else's guinea pig, you need to be focused on your business problems. Bigger companies that have engineers and resources to waste can try these out for you and eventually that startup you knew a few years ago will either be successful and ready for you to use or dead and you will be glad you didn't waste the effort.
Same goes for propropertary cloud services that have no business being proprietary. Biggest culprits here are data silo-ing lock-ins like DataDog, avoid like the plague. Use the standard off the shelf tools for everything you can, OSS may require slightly higher upfront integration costs in some cases, less than you think though, sometimes it's substantially faster due to integrations.
Generally speaking if a project has been around long enough folks have already encountered every problem and shared every solution. If you are stuck with some proprietary vendor for some important part of your stack and you are hitting an edge condition you had better hope you are a big enough fish for them to care (hint: You aren't).
I guess at the end of the day keep yourself off the Kool-Aid, ignore marketing speak and always ask hard questions of things and you will avoid innovation token sinks.
It’s interesting that the wisdoms of “buy, don’t build” and “NiH” etc. seem to be shifting in general.
I think a lot of people have been realizing through the pain of maintenance that dependencies are liabilities and that general, open source solutions with a bit of plumbing are often the lesser evil in that regard.
Given my anecdotal experience it seems to be true in the small, and I can imagine how this problem is even more pronounced in the large.
> It’s interesting that the wisdoms of “buy, don’t build” and “NiH” etc. seem to be shifting in general.
I don't know how these can ever be a "wisdom". It's often taken out of context and most people don't even understand how or where it should applied. If you blindly apply anything it's never a wisdom.
Something like "buy, don't build" earn companies $$$ and there is likely heavy influence from those trying to profit from it more than a general wisdom.
And then it will slowly come back to "my home grown solutions don't scale and I pay too many people to maintain all my infra, there's gotta be a better way!"
Or more simply, the urge to centralize and then decentralize has been repeated many times already in the computer industry, sometimes they are legitimate reasons, but often its grass is greener type of thinking which rules many engineering cultures.
I am using express for a side project. A popular middleware was last touched 10 years ago. You can read all the source in 5 minutes. And it works. I craft forms tags like it is 1999 and use .ejs files which is like active server pages. If there is a problem I can figure it out from first principles. It is a relief compared to modern stacks.
Say you are a startup in storage niche. Well, big companies aren't going to try using you because you need to have like 10+ years of proven work record before they even consider trying. So, you find yourself in a catch 22 situation.
What you can do is find another startup who'd agree to use your product. Maybe fore cheap. Maybe for sharing some resources with them, like marketing or engineering expertise in some area. And that's the only way to get any "mileage".
Maybe you could bribe your way in, or maybe you could be "lucky" to personally know someone important in a big company, which will allow you to gather that mileage without cooperating with other startups... but if you are a nobody, not only won't you be able to get an interview with a relevant exec, you won't be even able to contact that exec to ask for an interview. These people treat their interviews as a hugely valuable service which they aren't willing to provide to the plebs.
Storage (and other kinds of infra startups) all face these problems. They are solved via a number of factors:
1. Huge amounts of upfront VC investment to allow time to actually build out an enterprise ready product.
2. Leadership heavyweights with experience in the industry, both on the business relationship side and equally importantly on the technical side.
These two factors allow people like Andy Bechtolsheim and John Colgrove to build these sorts of companies and sell directly into enterprise from the get go.
This makes sense because startups have no money to spend on these things anyway, enterprises are used to accepting some free/cheap hardware to "test things out". In fact when I used to run an IaaS company we would frequently get a free box or two when AMD or Intel launched a new CPU architecture, they would push marketing spend through Dell or HP to allow us to have one to play with.
These aren't the companies I was talking about though. I was talking about chasing shiny things that are half-baked. You can't sell a half-baked storage product to anyone so it's not really a concern.
For example, if you were using Typescript to build a mobile app, you might be tempted to use TypeORM (32k stars on GitHub, been around since 2016, widely used). If you wanted to also use transactions and concurrency then this would be a mistake, because you would quickly find that TypeORM's SQLite adapter doesn't have a connection pool or locking for transactions, and will happily execute statements inside a transaction then roll them back without your knowledge.
And I never heard of TypeORM until now, which means that it's not boring tech in my eyes. I find it hard to classify anything in the node world as boring, considering the infamous churn rate. Popular yes, boring no.
Ive been increasingly disliking ORMs in general lately. After a few days of trying to identify connection leaks and poorly optimized queries in a SQLAlchemy application, I’m starting to lose my hair.
I think this actually speaks well to the point of the article. We can simplify the logic a lot by using boring tech, in this case, separating the query builder logic from the connection/transaction logic. Switching from one very complex ORM, to two more understandable simple systems, and getting back to more grass roots with querying.
Query builders are the way to go. The pick of the bunch is jOOQ IMO but not everyone is on the JVM but I would be looking for something similar if I had to code on a different platform.
Writing an app in a microservice architecture with services in Rust, Go, and Nim. Database is a serverless DB like Planetscale. Front end in HTMX. Etc…
I think any tech your team is not already familiar with, and isn’t the standard pick, is an innovation token.
So I agree 100% with this, but postgres is so easy and scales infinitely (for the meaning of infinite in 99% of business use cases), I suppose I don’t understand why I would choose MySQL. Do folks just use it as a user cache? Most systems I’ve designed of worked on have required a central database so MySQL never seemed the right fit.
MySQL has better compression and IME can scale further thanks to redo log and alternative engines. Still love Postgres's rich feature set for smaller DBs.
> I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI.
Spending a few hundred K on Unnecessary Kubernetes (and the surprises that result) is definitely still a popular thing amongst junior/mid devops people.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
There are frameworks that take outrageous amounts of time producing very little, besides opinionated staff. Basically assembly for X in disguise, demanding everyone be "educated" and up to task.
Meanwhile the world moved on.
Blockchains, making your own JS framework/language/static site generator/MQTT alternative/etc, building a desktop GUI toolkit, making your own VCS, retro hipster type stuff like handwriting HTML with no templates or JS, or using Linux without some kind of configuration management system...
This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement.
It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea.
The specific languages it calls out are Python and PHP, which IMO are bug-prone languages with serious performance/efficiency implications. Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet).
I would say more important is “write boring code”, and it is easier to write boring to-the-point code in modern languages without implicit null references, with sum types for modeling mutually-exclusive data, and with as many other common pitfalls statically eliminated as is possible.
Choosing a language before you even have an app matters. Changing the language your app is already written in or tacking on a microservice so you can use a 2nd language.... not such a good idea.
I chose php 8 years ago because I already knew it. Would I write my app in a different language today if I could? Probably. Should I do that now, when I have very few bugs (basically none of which are related to my language choice) and no performance issues? Probably not. Have I been tempted because shiny? Yes.
Delivering actual value to customers is what matters and there hasn't been anything I couldn't solve with a bit more PHP. Rewriting the whole app would probably kill my business.
Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws.
Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtually nonexistent (eg. Kotlin or Haskell).
Here are some examples of more common bugs:
* Misunderstanding of the desired functionality (eg. giving admin permissions to regular users).
* Not being able to predict all valid input forms (eg. user names with accented characters).
* Forgetting to handle errors coming from multiple levels below the immediate level that's being worked with (eg. dealing with SSL-related problems in HTTP client / server communication).
* Simply forgetting to implement some uncommon bit of functionality (usually related to cleanups, deletion etc.)
----
Currently in-use programming languages have roughly the same ability to deal with these, as I call them, "macro-problems" of programs. All of them are equally ill-equipped and unprepared for them. Tightening the type system or chasing after nulls is working at a resolution that's too fine. At this resolution programmers usually still have a good chance of figuring out the problems without the aid of types or similar automation.
NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place.
NPE issues are also very very difficult to chase down.
"very very difficult" on what scale? How many "verys" before it gets really hard?
Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable.
Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit.
And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.
> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs
You are also choosing
-to let your team choose their own IDE
- easy to debug
- frameworks that works out of the box
- and continue to work regardless of Kotlin versions (since one doesn't use Kotlin)
- to no have to deal with a number of "interesting" ways to write code
I like Kotlin. But it is more nuanced than some people would like to have us believe.
Personally I think I have spent far more time over the last three or four years hand holding Kotlin and cleaning up "clean code" than I have saved by less NPEs.
Agreed, also, imo boring implies that failure modes are well understood or at least documented and have a bigger community to rely on when you eventually hit them.
Eh, I would argue Kotlin is solidly boring right alongside Java now. It's still "mostly" Java if you are using it in the same places you can use Java.
I'm with you generally though. Yes choose boring tools, JVM, PostgreSQL, etc. But also write boring code using boring architectures deployed on boring platforms.
Definitely. The only real downside to going with Kotlin nowadays is hiring developers; it's reasonably easy to find Java developers who want to try Kotlin, but hard to hire people experienced in Kotlin.
I think the reason it resonates with people is that a common failure mode in technology is picking the wrong tech for the problem, and this often happens because engineers like to learn and pick things they are unfamiliar with so that they get that buzz. Most of the value in this article can be boiled down to telling engineers to not make tech decisions based on the brainy feelgoods. It's like telling people to eat their vegetables. Boring, straightforward advice, but a good path to a healthier body.
> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea.
But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one?
> Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet).
At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology.
Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.
Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.
> Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit.
Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns.
> but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case.
Isn't this premise aligned with the philosophy written in the article?
1. You needed to learn something new (so no longer boring, and prime for innovation token)
2. You needed to use something different for a systems language context (innovation token time)
> But if you make the choice of Java (boring) over Kotlin (shiny new)
New doesn't mean exciting. Programming languages are boring – even new ones. If you see a programming language attracting a lot of excitement, beware, but otherwise whatever you're comfortable with will be fine.
I am six months into a startup. It's a Python monolith with Postgres. It's been a success. There's a product-market fit, paying customers, and a healthy roadmap. The team picked boring tech, and it was the right call. Now, we are scaling to add exponentially more customers and hiring more people. We need to add resilience. We must tackle challenges around back pressure, flaky third parties, etc. Now is the time to introduce additional complexities because they pay for themselves. Such complexities are introducing dedicated read models and caching so we compute on write instead of every query/request, some messaging tech. We want to use Node instead of Django for our client-facing Dashboards and Dynamo for some tables.
In summary, the evolutionary journey of a system starting with a monolith, with a single language, and single db tech with some gnarly SQL isn't very sexy. Still, it takes you a long way before you must reevaluate and acknowledge that optimising for Flow and Pivoting over everything else turns into Flow and Cost to Serve. Your mileage may, of course, vary.
The problems you describe are what Elixir solves out of the box simply by being based on Erlang, including caching and pushing real-time data to dashboards. It’s also easy to learn coming from Python and Ruby.
I feel like this has been misunderstood for years. I note this paragraph:
But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down.
I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing to do something in PHP would be using up an innovation token.
Average quality is so much higher for certain languages (Clojure and OCaml also come to mind). I don’t mind a 5% pool size when 95% of the alternative can’t build things.
This is almost never a bad thing. It means you have fewer people to compete with when advertising a position and the people that use a niche technology generally have more passion for their craft.
Although it also delays hiring - I work for a startup using Kotlin, and we've had maybe three candidates _ever_ who have used Kotlin beyond hobby projects. And I was one of them!
"Boring" is subjective, and even objectively defined it can't be measured. Therefore yes IMHO, F# qualifies as 'boring' for you.
However, unless you're an isolated entity (e.g., SOHO) or fully remote, your business environment also factors into that equation. Node.js might be 'boring' in the USA but anecdotal (read: edgy) in entire subcontinents.
Economically speaking, a 'boring' tech stack is one that generates the least 'friction' for its devs. (friction may be construed as added cost beyond base material requirements, eg. time or complexity added by bureaucracy, or cognitive toll induced by steep-n-quirky learning curves, as opposed to the fastest road to MVP / RC / shipping).
I hate this, as usual all blanket statements are false assumptions. The presentation is mainly focused at new paradigms but technology is there to help us fix problems, and I totally agree that jumping on a cutting edge tech is very risky in most of the cases and can end up in wasting a lot of time finding workarounds on either limitations, bugs or immaturity of the chosen tech, BUT my problem with this is "where do you draw the line?".
Is an on premise service boring tech? should we use that instead of aws?
Is github actions too cutting edge? should we keep using jenkins for ci/cd? etc.
It really depends on so many factors (like in house experience, really understanding the product and engineering needs, costs etc) and it does not take in consideration the "problems" of boring tech and why modern tech has tried to solve or avoid them.
The last director who mentioned that to me and built everything in django and had huge scalability issues and took about 1 year and a half to refactor a part of the app to move away from context and orm.
In my opinion the only thing that matters is "how coupled are you with the tech and how optimized for deletion and change is your code/infra"
> BUT my problem with this is "where do you draw the line?"
Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring".
If your team can configure AWS services in their sleep but have never touched a bare metal box then AWS is boring. On the flip side, if you're a bunch of Linux greybeards and wrote the book on iptables but can barely spell VPC then on-prem is boring.
This is also where the concept of "innovation tokens" comes in. C++ is well established and quite far from innovative on its own, but if you're building a web app and your team is full of new graduates and interns that have only ever touched Javascript and Python then using C++ would spend one of your "innovation tokens" as your team is busy learning it instead of learning the business domain.
100% agreed, as I mentioned in house knowledge (and engineering size) matters when deciding this.
In your example, if you only have recent graduates in your team you have a whole lot of different problems :D
In a more common setup (some seniors, some juniors) given they will have to learn something on the road anyway, wouldn't you want to, for example, use managed services instead of "boring" services? Use svelte instead of angular? use flask instead of django? or fastify instead of express?
And if you go boring because there's more literature on them, you will soon find out that most of it is confusing as it spans over the years (have you ever used springboot? so many different ways of doing things that evolved in time...) and in the beginning you'll end up using the - by the book- approach which does bring some complex problems (try refactoring the auth module out of an app).
In the end what you are doing is moving the problem of figuring things out later in the future, when things are much more complex and refactoring is much more costly.
But I agree with you in the end it depends on the org, which is why you should not choose boring tech by default, and not choose cool tech by default either and think more about what would really give you speed of execution and maintainability in an always changing business domain AND keep things small enough that can be refactored out in an as-easy-as-possible way.
ps of course this is after like the first year of your startup, there's no point of doing any of this, or even choosing any technology if your company dies in 3 months.
pps i still don't understand why early stage startups don't do everything in javascript (FE+BE) so the same engineers can contribute to both part of the stack and then decide what to change depending on the business needs
One of the main points of this essay is that you have a certain budget for innovation, exemplified in a fixed token count, you spend on your tech stack. Once you are out of tokens, you end up injecting too much risk into the project, and it is likely to fail.
I think this view has to be generalized. Your budget isn't simply affecting the tech of the system, but it also affects the whole: business case, decision loop, company maturity, etc. If the business case is a true moonshot vision of epic proportions, you have to think about what tech stack can support it. In some cases, you can be fairly conservative in your tech choices. That's probably a good idea if the business case is pretty wild and ambitious since it will ground the project nicely.
However, in many cases things go hand in hand. There's often some important complex part of the business case which require complexity in the tech stack. Say, for the sake of the current spotlighted tech, the central component need a large language model. Then, that LLM is going to eat into your development effort budget quite a lot. You should probably focus on getting the core part of the system running quickly, and support it by conservative tools.
The flip side is a quite straightforward business case. Then, the competitive edge needs to come from better application of the tech, and that will often require more innovative approaches.
In summary: you need to think about where the innovation is in the project, and modify the tech choices accordingly.
edit: Apparently "choose boring technology" is just clickbait, and in fact the guy advocates for all the nuanced technology selection advocated here.... so errr, apparently he in fact is saying "don't chose boring technology" or something, whatever.
I completely disagree with almost any blanket philosophy on technology.
Don't choose boring technology.
Choose technology that suits the context:
* choose what you like for personal projects
* choose tech your team has the skills with
* choose tech that won't be a problem to recruit people for (I'm looking at you, Ruby On Rails)
* choose tech that gets the job done
* choose tech that the industry is moving towards
* choose tech that levels up your team's skills and makes them feel excited that they are learning and advancing
* choose tech that allows you to meet the priorities of the project (your project does, define priorities, right. right?) security/availability/maintainability/performance/compatibility/whatever
* choose tech that ensures your team and company won't be left behind when market skills move on
* choose the cutting edge if you think that's the right choice for some reason
It seems pointless to me to say "choose boring technology".
It turns out that it’s impossible to reasonably title any talk or article without it being considered a blanket statement. This is why you attach the talk or article to the hyperlink so people can continue understanding more of what you are saying.
Well, this is just clickbait. Choose boring technology means sth pretty concrete for someone without context. It’s not that you can’t reasonably title it. It’s that you can’t reasonably title it to generate views.
I understand the sentiment, but then one should expect criticism of the schism between title and content.
"Clickbait" has been apparently watered down to the point of meaninglessness then. You title things to get people to want to read them if you're sharing information you think is important. The term "clickbait" is typically used to refer to false and misleading titles to generate ad revenue for garbage content.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that". [0]
I want to choose tech that has the least amount of maintenance. For example I had to build a web app thing for something I'm doing. The many frameworks available are of course trivial to string together but now I'm looking at a huge amount of dependencies all that require a lot of maintenance. I went with avoiding all but the the most critical libraries for authentication but is there a better way? I found even writing in OCaml and generating js into a docker file to be hosted by someone else who maintains node.js was actually less maintenance than me using any existing frameworks
I prefer jQuery and jQueryUI - actually I go one further and use the devextreme components so I have paid support (outrageous I know) for spa's or something like umbraco for CMS but they are very unsexy and old. Delphi for cross platform applications, but try and sell that as a development platform :-D
I think the big advantage of this sort of stuff is you have a million debugged and working examples to pick from and people who know them inside out.
Edit: I watch the kids trying to figure out how to release things on docker with their multiple git branches and merges, and re-engineering their microservices frameworks, and each time I die a bit inside. This was all done so long ago, why continue to make it harder. Now I'm not talking something google scale, but something with a few hundred users and maybe 20 concurrent, why would you do this, sigh.
i found the key in reducing maintenance overhead is to avoid complex build tools that claim to manage your dependencies and use frameworks that don't frequently break compatibility.
While I see how this makes sense, I don't like this. If most people follow this strategy, we will end up with utter stagnation, or even devolution.
"Boring" technology also has many hidden costs - most importantly, opportunity costs of not having several times higher productivity due to the warts and quirks of the boring tools. Sure, with enough practice one can work around them but every backwards issue takes a good chunk of productivity out of the project.
I get the argument of "if it's not mainstream, where will we find programmers" - but that's more of a cultural issue of wanting expert programmers out of the box instead of investing in them and training them.
Ultimately, this line of thinking is like saying 640K RAM is enough for everyone. Sure, you might say C++ and Go is enough for everyone, but there are many unrealised gains left on the table.
We don't get new innovative databases because of small startups deciding they want to roll their own database as part of building their new fangdangled AI thing.
We get new innovative database either by new innovative database companies that rightfully spend their time and effort trying a new idea in the space or out of huge companies with R&D budgets to build such things, like Spanner.
Startups choosing boring tech for everything that isn't their core/critical innovative area should actually accelerate innovation by focussing effort more efficiently.
I do agree that the whole hiring aspect of it is hot garbage though. If Haskell is the best fit for what you are making and is considering boring in your field (say you are doing verification) then it makes perfect sense to use it even if the pool is smaller because a) people that stick to Haskell despite its difficulties probably have more passion for the craft and b) it's way more likely someone that knows Haskell has some exposure to your field, verification in this case.
Same can apply to lots of "niche" languages/tools/etc. Boring is relative to what you are working on.
I build distributed systems primarily. For me boring is Java. I imagine C++ is boring for game devs/GPU folks. etc.
This was the second time I've read that talk. Please don't accuse me of not reading it. As all of us, it might be that I completely overlook, or interpret something entirely differently or outright wrongly, but I think this is entirely uncalled for.
Edit: I kind of see what you mean now. My paragraph about hiring was somewhat tangential. I am sorry.
i strongly disagree with that. what makes technology boring is the fact that it has less unknowns. ie no hidden costs. that doesn't mean there are no costs, but the costs of eg java are well documented. if those costs are a problem you can choose other tech with different costs. the danger with interesting tech is that the costs are unknown. you do not want unknowns in your tech stack. you have enough unknowns in the problem that you want to solve.
unless of course you are solving boring problems. most of the work out there is solving old and boring problems. there is no innovation to be had. in that case you may innovate in your tech stack instead.
in other words, choose one area to innovate. don't innovate in multiple areas at once.
Is boring technology even an option in high-velocity fields like ML/AI?
I can pick boring databases and boring servers but when it comes to model architectures, model weights, GPUs, serving frameworks, etc. there's been such massive improvements lately that it doesn't feel like anything has settled enough to be "boring".
If I need a language model, or an image classifier, or an ASR model, there are older options which might be "boring", but they're not nearly as powerful as the latest options. Does choosing boring ML tech mean sitting out on massive recent advancements?
99.999...% of us don't work or seriously touch in AI in any way. At best you make an API call to something that might do some AI, but at that point its just another service.
So for the vast majority of people doing dev work, boring choices are correct. I've had a lot of junior devs come to me with proposals for microservice architectures that can autoscale, be orchestrated, have 0 downtime with red/blue deployments, etc, etc, when at the end of the day it could be done with a boring, single server (plus second for resiliency, but not needed for scaling) with just a few endpoints. It will be done much faster & simpler, which means it will be cheaper and less likely to fail.
My guess is that the same is true in a lot of AI work. Yes there is core stuff that needs to be performant, scalable, and modern, but I'm sure there is also a ton of boring old regular internal corporate infra that can be done 'boring'.
The first approach will be significantly cheaper if using the cloud.
It allows you to use spot/ephemeral instances and scale down capacity to almost zero cost without any loss in availability.
Single server in the cloud is great for dev environments and if you don't care about uptime. But given that poor uptime is toxic for customer retention only incompetent businesses would deliberately not choose to use something better suited. Especially when it's so much cheaper.
> The first approach will be significantly cheaper if using the cloud.
Only if you're regularly scaling down to zero (AKA too few paying customers to stay in business).
> only incompetent businesses would deliberately not choose to use something better suited.
There's a time and place for both approaches. If you're serving anywhere near the number of users needed to show a profit, spot instances are extremely expensive.
I think the whole point is that you only have a limited “cutting edge budget” so if you are somewhat forced to spend that budget on cutting edge ML models then don’t overload your team _also_ using cutting edge languages or infrastructure or databases.
So save your budget for what will really make your product unique instead of “wasting” it on things that in the end won’t give you a real competitive advantage.
The point is to constrain innovation to the areas that you vitally need it.
Say you are building some sort of visual AI startup, say something that does generative AI things with videos.
You would a) use a boring AF web stack b) use ffmpeg and c) don't go and try do a bunch of silly serverless things, d) try use one of the relatively settled model serving platforms if it's viable for you.
Then you can use all of your innovation budget on your model itself, your training infrastructure etc, things that will provide you with a competitive advantage over people trying to do the same thing as you.
> Does choosing boring ML tech mean sitting out on massive recent advancements?
that's the point that for new tech it is hard to see where is the hype and where are real advancements which can be useful, and author's choice not to take the risk.
Say you bought the hype of GPT, and integrated it to your product to unlock new cases, but it also can add lots of confusion and quality issues, which author prefers to avoid.
But that choice has absolutely nothing to do with being boring or not. It's a business/product decision.
ChatGPT costs serious money, is easy to integrate with and is great for specific, general tasks. But it hasn't been trained on recent datasets, can't take advantage of internal or custom datasets and has restrictions on how it can be used.
Also most companies will never allow exfiltration of sensitive data to a third party.
Dan McKinley's innovation model is solid. If you're familiar with entrepreneurial literature (eg. HBR), or financial analytics, or even the prosumer DIY scene, you'll land on the same general principles.
"Boring" is essentially a synonym for "reliable," a principle that holds true across sectors, especially in tech-adjacent fields. Nintendo's success is a case in point for the power of commoditizing reliable tech.
Google's polyglot approach (Go, Kotlin, Dart…) might seem like an exception, but it's more likely a symptom of being "too big to notice friction." This will eventually manifest as either tech debt or a talent bottleneck.
As for sectors that defy the "boring is best" mantra, they're rare. Even buzz-heavy areas like crypto and Web 3.0 often rely on tried-and-true languages like Java or Python. Domain-Specific Languages (DSLs) are the real game-changers, bridging monoliths to human-centric solutions. The only sector that genuinely benefits from "non-boring" tech is cutting-edge R&D—think languages like Julia.
Looks like a very convoluted way to say that you should avoid mistakes, but with confusion between familiarity and in depth analysis.
Worst surprises generally comes from non verified expectations, and ends up to hard to workaround problems that becomes clear in hindsight «It never really worked that way».
You have better chances to avoid that with tech you are familiar with, but the only real way is to verify how the thing is built, and on what principles, confront that to your knowledge, and if it aligns you have greatly improved the chances of things going smoothly.
Since people are generally not rational and rarely do those checks, when working with a team, going with familiarity is the safe route.
I do agree with a lot of the presentation. A word of caution though: some technologies that start by offering simplicity evolve over time to provide a very difficult to grok environment. So the evaluation about the cost of maintenance is not a do once and forget.
And sometimes boring means roll your own. An important aspect of this for me is to pick the simplest solution: A bit of code > A library > A Framework > Platform, which I think is in line with the presentation.
- choose the tech stack ur team is most comfortable with
- focus on getting PPL to try your product, then revenue, then scale and then microservices - in that order
React and Vue probably qualify as a boring tech, but you could also use traditional server-rendered apps, e.g. with Java, php, etc., with jQuery on the client side.
Though it was far less clear when this article was written than it is now, if you're starting from scratch on a webapp today it's hard to go wrong with React.
there are a lot of voices against react too, so i would be careful. react is a good choice in that its downsides are well known and documented, so at least you can make an informed choice. but i would cast a wider net and look at svelte, vue and angular as well.
personally i use aurelia, but it being less popular means that less people write about it so there may be hidden downsides.
i am already familiar with it which is sufficient to qualify as boring for me. and i am also solving boring problems which allows me to spend my innovation tokens on my tech stack.
boring is what you already know and don't need to spend a lot of time learning, or, if you don't know any, then it's what is widely known and well documented.
Already know? I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases.
Look at 'boring' php, facebook was using this language at scale, so they had to develop a just in time compiler for the whole thing. Python didn't have that problem, so it still doesn't have a just in time compiler (for the default interpreter)
Also look at all the changes and action in the JDK (ever since JDK11). Is that also boring?
i think it that the definition of 'proven' technology smells of silos: if you come from the Java world, then everything else is not relevant, same for php/python, same for the nodejs world.
true, it's a matter of judgement. i don't think that chosen software has to be proven in general, but if i chose it i want to be sure that i can trust it myself. everyone is free to make up their own criteria what that means for them. it's a risk assessment.
This is one of those pieces of advice that you don't need to get super specific about and can follow as loosely as fits your circumstances, but in general I think it's nice!
I am doing a freelance thing and opted for mostly "boring" technology and so far it's working out great:
* OCI containers (Ubuntu based) with Docker and Docker Swarm because it's simple/stable enough and has the features needed
* Apache httpd as the web server of choice, because it has mod_auth_openidc integration to be an OpenID Connect Relying Party, less abstraction than a Kubernetes Ingress, too
* .NET with ASP.NET and EF (Core) for the API, because the ecosystem is pretty coherent and it does most of what I need, yet still has an okay type system (much like Java)
* Vue with various popular packages (Pinia, Vue Router, VueRequest/Axios, VueI18n, PrimeVue, PrimeFlex, PrimeIcons, ...) for the front end, because it's a good fit for the SPA and is simpler to use than React (IMO), yet doesn't have the complexity of Next/Nuxt; I actually considered Angular for the more batteries-included design, but Composition API is just great and most of those libraries are really easy to import and setup
* MariaDB as the database of choice, because for simpler projects it's also easier to use MySQL/MariaDB than PostgreSQL: the model driven development tooling with MySQL Workbench is nice because of the codegen for migrations with dbmate later, as long as you don't need lots of complex in-database processing or transactional DDL, it just works
* off the shelf software for day 2 concerns: Portainer for managing the cluster, Keycloak for user management, Matomo for analytics, Uptime Kuma for uptime monitoring, Apache Skywalking for APM and rsync for backups (for now); reasonably stable options for all of the code I don't want to write myself, especially in regards to auth/user management
Will a blog post on what and how I built ever get lots of attention? Probably not. But is it good for shipping software? I'd argue that definitely!
It lets me iterate reasonably quickly and also any learning I do is useful and not overwhelming due to its limited scope: e.g. adding VeeValidate instead of Vuelidate, configuring unplugin-vue-components, discovering VueUse, adding Capacitor into the mix, considering and subsequently discarding AutoMapper for EF/DTO, adding a plugin to my IDE to generate Entity mappings from a live database, working with spatial types in MariaDB (a bit less nice than PostGIS, but serviceable).
All of this also scales far enough for the current resources at my disposal. At the point where the performance of Apache httpd wouldn't be enough, there'd probably be a bigger team that can migrate it to something else.
Admittedly, sometimes this also means using SaaS for certain concerns, like using Mapbox for geocoding/routing, because self-hosting OpenMapTiles/OSRM/whatever would slow me down too much.
I randomly started building UXWizz[0] 13 years ago, on a (not completely sober) New Year's Eve, and choose the most boring stack ever: PHP, MySQL, jQuery. The platform has evolved so much over the years, but it's easier to maintain and install than day one, even if the codebase is 100x the size. I did do a refactoring in 2020[1], rewriting the entire front-end from spaghetti jQuery to TypeScript/React/MaterialUI, which you might argue is not the most boring stack, but simply "the norm" and a safe and easy and maintainable option. Now, three years later, I feel like I can make changes, add or remove any feature and create new ways to install the platform with ease (e.g. Docker? Simply add a COPY line in a Docker file using the LAMP stack to copy the PHP files; new UI element or page to display data from DB? Add a basic React component, a 5 lines PHP file with a MySQL SELECT query in it returning the data, and a fetch request).
In 13 years I've seen analytics companies come and go, trends and stacks appear and disappear, and I think I've managed pretty well to keep up even with corporations with millions in founding while being myself a solo-founder and having worked on it mostly as a side project, I think this was the secret: keep the technology simple and focus on improving the current features as opposed to adding new ones. Also, be passionate about performance and simplicity: if you can make something both faster and simpler at the same time, do it now, it would save you so much time in the long run. This includes dev tooling too: like moving from webpack to parcel or vite (10s vs 1s build times, worth in the long run), or creating Gulp.JS tasks to automate manual process like uploading files, setting the file version in a readme file, and adding guards (if checks) like making sure you don't publish the dev version instead of the production one. Oh, and another secret: keep updating the libraries you are using: it's a lot easier to go from version v3 to v4 in 2019 and then v4 to v5 in 2021, then directly v3 to v5 in 2021.
PS: Fun fact, when I started working on UXWizz (called userTrack before[3]), I started with the heatmaps and session recordings, it didn't have any stats/graphs for many years. Here's a screenshot of how it looked [4], [5].
He writes all this philosophy and then concludes with using PostgreSQL instead of mongoDB or nodeJS (? I'm not sure how that was in the same category). PostgreSQL is the opposite of boring technology; I've been using it for over 10 years and am still discovering new and surprising features with new and surprising failure modes; PostgreSQL today is very different from PostgreSQL 10 years ago, but setting it up for true master-master replication is still a clusterfuck and you still have zillions of moving parts in real world use.
I'm lead inevitably to the conclusion that philosophising about tech choices and principles is pointless. Everyone will nod and agree with the principles and tradeoffs and then pick their personal pet technology anyway.
You're kind of missing the point, unless you're saying that regular PostgreSQL also has interesting failure modes. PostgreSQL clustering may not be boring technology, but that just means you scale up instead of out. If you run out of headroom for scaling up, that probably means you're successful enough that you can take a look at non-boring technology.
There are many aspects of PostgreSQL which are not solved problems e.g. clustering, replication, high-availability. And will remain unsolved whilst they are not part of the core products. Because everyone comes up with different solutions which change over time.
Citus Data which people often recommended didn't exist prior to 2010 and may not exist next year now they've been acquired by Microsoft and conflict with their Azure business.
Clustering, replication and high availability may not be easy, but there are thousands of production PostgreSQL instances out there have solved them. That's what makes it boring.
Compare solving those problems to solving them with a brand new database engine where you might be one of the first organizations to run at that scale.
OK, you've attracted my interest. What are some examples of official database documentation pages that do a great job of covering these advanced deployment topics?
It's important to note that "boring technology" doesn't mean the official documentation will answer all of your questions: it means that there is enough experience out there in the user community that you can find the information if you go looking for it.
How is it an "advanced" topic? Having multiple instances so that you don't have a SPOF is table stakes for any service you care about, and something any half-serious datastore like Cassandra, Kafka or even MongoDB (for all of which "clustering, replication and high availability" are boring things that you would naturally set up without making a fuss about it) will do out of the box. I'm constantly baffled that when it comes to RDBMSes people suddenly decide that single points of failure are fine now actually.
The essay was written in early 2015 and you can further interpret the author's idea of "boring" versus "innovative" technologies through the lens of what they were using at Etsy from 2007-2014 (NodeJS was initially released in 2009).
All of that said, today's tech landscape is far less edgy than the early days of cloud, NoSQL, and NodeJS. I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI.