Choose Boring Technology (2018)
boringtechnology.club
boringtechnology.club
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.
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.
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.
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.
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 call it "StackOverflowability". Pick tech where you'll find all the answers you need on SO.
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.
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.
ORM is a great example of something boring yet bad.
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.
The fact that SQLite supports those is of course great, but maybe there are easier ways of serializing access to it.
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.
You may not get all the way with them, but by the time you have to worry about that you can hire someone else to do so.
That's what I always tell myself.
Guest languages on the JVM and CLR.
Mobile apps with hybrid stuff, instead of the SDK languages.
Also using SPAs for what would be doable in PHP.
Spending a few hundred K on Unnecessary Kubernetes (and the surprises that result) is definitely still a popular thing amongst junior/mid devops people.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
that's why they call it innovating. If you knew already, then it wouldn't be innovating, since it's not the innovation that's new.
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.
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 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.
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.
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.
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.
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)
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.
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.
> flaky third parties
Seems contradictory. What are the third parties used for?
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.
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).
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"
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.
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
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.
367 Comments: https://news.ycombinator.com/item?id=26211721
84 Comments: https://news.ycombinator.com/item?id=31558887
Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=31558887 - May 2022 (83 comments)
Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=30389591 - Feb 2022 (13 comments)
Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 - Feb 2021 (361 comments)
Choose Boring Technology - https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments)
Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments)
Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments)
Choose boring technology - https://news.ycombinator.com/item?id=16677583 - March 2018 (1 comment)
Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)
If that's wrong, we can correct.
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".
I understand the sentiment, but then one should expect criticism of the schism between title and content.
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.
"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.
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.
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?
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'.
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.
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.
Spot instances are the cheapest types of instances you can get.
Auto-scaling the smallest compute instances for your use case is the most efficient architecture you can get.
It doesn't matter what time or place it is. These are facts that you can check for yourself on AWS/GCP etc cost calculators.
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.
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.
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.
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.
"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.
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.
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.
Got a bunch of Kubernetes experts on your team? Then Kubernetes, for all it's complexity, is "boring".
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, reliable, accessible, extendable.
Only reach for JavaScript when it's actually required - which is less often than the modern web would suggest.
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?
yes, that is true but i think that supports the point: use boring tech to solve interesting problems.
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
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've always found the "boring programmer" thing pretentiousness trying to disguise itself as humility.
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].
[0]: https://uxwizz.com
[1]: https://docs.uxwizz.com/about/changelog#usertrack-3.0.0-beta...
[3]: https://www.uxwizz.com/blog/rebrand-usertrack-is-now-uxwizz
[4]: https://i.snipboard.io/B6xhu7.jpg
[5]: https://www.paldesk.com/wp-content/uploads/2020/04/userTrack...
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.
What makes it boring is:
- people have been using it for decades, for all kinds of different things
- this means that any problem you run into, someone else will have seen before - and will have talked about it online
- you're not going to be using it to solve a class of problems that no one else has used it for before
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.
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.
Great. Can you provide the details on exactly how they did that. Ensuring of course that it doesn't rely on anything proprietary e.g. Citus.
Because with every other database I can just go to the officially supported and maintained documentation.
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.