Software Mistakes and Tradeoffs: Choosing your tech stack

What are the biggest mistakes programmers make when choosing a tech stack for their application? Thanks.

In my experience the main problem is jumping to a technology shopping excercise before fully understanding the problem.

I am trying to share my experience around that topic in the "Third-party libraries: Libraries you use become your code" and "Keeping up to date with trends vs. cost of maintenance of your code" chapters.
The first part is about owning things - understanding that everything you import to your software is effectively becoming your responsibility. If your software fails, and the 3rd party library causes that failure, your clients don't care if it is your code or not. So due diligence when picking 3rd party libraries (or not picking a library at all and re-implementing a small part that you need would be a solution for that).
The second problem that is covered in the "Keeping up to date with trends vs. cost of maintenance of your code" chapter focuses on the issue of jumping into "trendy" new technology. Doing so may be problematic for your application because the new framework may not be mature and may not fit your context.

That is rather like the eBay problem: if a seller despatches the goods promptly but uses a delivery company who take a long time, the buyer receives the purchase late. And sellers should know who delivers on time and who doesn't. In eBay's case, not sure, but I think you can't give negative feedback if the delivery company delays the purchase.

How much do you say about companies using older versions of programs, for example sticking with Java8, because they have been better tried and tested?

And following on from Campbell's question, what about the continual pressure to "upgrade" to a different library, framework, or even programming language?

I had an interesting conversation with a friend today about a project he was managing. There was a desire within the team to use Kubernetes, and there was some debate about whether that was a good choice or not. The conclusion was that even though it might not have been a perfect fit in terms of technology for the presented problem, it was the technology the team were most familiar with when it came to supporting and resolving production issues. It was an interesting take, and certainly some validity in it, that the "right" technology choice should be considered not only for development, but for support and maintenance too.

Frank Carver wrote:And following on from Campbell's question, what about the continual pressure to "upgrade" to a different library, framework, or even programming language?

I suspect our team is somewhat unusual but we run a regularly-scheduled job to check for outdated dependencies and we generally update everything as a matter of course (after carefully checking the release notes!). We have a few libraries that are "old" -- where there's a breaking change across versions and we haven't scheduled the time to adapt to that -- but in general, we keep everything on the latest versions as much as we can.

The upside to this is that library updates are generally "easy" because we're only updating a few at a time and they're nearly all patch-level changes. It also means we often avoid CVEs that get discovered in older versions of libraries.

Of course, every now and then, a patch-level update contains a breaking change -- I'm looking at you netty-socketio!