What piece of tech do you regret choosing for a project?

For me, it was a NoSQL database on a website that needed to manage relational data. This was about 5 years ago when these things were trendy and promised really fast performance. The relationships were simple (think users, groups, and memberships), and I thought I could just code my away around the things that an RDBMS would normally handle. It made my code way more complicated than it needed to be. On top of that, the database daemon would just randomly hang about twice a month and no longer respond to requests, effectively bringing the site to a stop until someone notified me that pages were not loading. Eventually, I rewrote it to use nothing other than SQLite. The website has been rock solid ever since. I learned a little about what happens you let hype get the best of your decision making. NoSQL has its place, but RDBMS has been solving a lot of problems for good reason over the past few+ decades.

I felt some pressure to adopt some JavaScript libraries in the ~2013-2015 time when they really were not upgrades over what came before them — just had some hype.

I was a less experienced developer at the time, which let me question some of my own hesitations, and should have trusted my personal evaluation of the developer ergonomics.

I'm not some kind of anti-new-stuff curmudgeon, by any means, but learned a lot about how to make choices which have carried me forward well.

PHP for a configuration app, ended up really being better off with a React/Node SPA for the use case in hand and I wasn't good enough at PHP (plus at the time PHP wasn't as good as it is now).

It seemed from reading documentation and a running a small PoC that it would be fine, but really wasn't a great fit. I should learn to interpret other people's use cases as interesting, but make sure that they really are a close fit for my requirements and I should opt for incremental learning for my own skills rather than diving into something else and expecting me to be as good a software architect with new things as I can be on things I'm experienced with.

Final lesson: you need to build things with the tools you know the best so long as they are good enough for the use case in hand. If the tools you know aren't a good fit, properly learn the new stack with PoCs that have real world complexity and also test the "assumptions" you have from other stacks.

I chose to start a new admin panel app as a sister application to the public web app and went with Quasar V2, Vue 3, Vuex v4 with modules and Typescript.
Just too much cognitive load and poor documentation around getting Vuex4 to validate Typescript property with the module loader.

• PHP, anything done in PHP or related to PHP
  • Symfony was such a waste of my time back in 2010, I came back to life after discovering Django
  • WooCommerce as one of the few e-commerce platforms that clients know about (and thus that you can sell). Won't be using again, it's just impossible to work with a platform that treats orders and payments as blog posts.
  • Laravel has such an annoying DB migrations system. Didn't stray long from Django.
• Vuetify. Like all those frameworks it's extremely hard to customize and then they decide to change the CSS pre-processor and suddenly all your work goes to shit. On top of that, it's heavy like crazy and creates render-blocking infinite loops in some conditions.
• A had lots of hopes about lots of PaaS, hosting platforms or services like that. In the end they all crumble because of very basic stuff like secrets management or Git-flow-like process compatibility. Big ups to the DigitalOcean Apps platform that is finally where I need a PaaS to be (almost but I can emulate the rest).

No offense for the people creating those techs of course, I know how hard it is to tinker with something and end up with some high-profile piece of software.

Although interestingly in most cases it's not that those tools are bad "for the job at hand" but rather bad "for the job advised as the project's reason to be" which is kind of unsettling.

Like some others, I chose to use Mongo once and later realized I probably should have gone with an RDBMS. But it's a minor regret, because using Mongo mostly went okay.

Another time, I was creating a project and using MySQL. This was for an internal tool, where uptime wasn't necessarily critical, but data integrity and safety was. I wanted to use Amazon RDS because I felt confident in their replication and backup capabilities. But the IT guys insisted that we use the company's own data center and OS volume snapshotting for backups. I objected a bit, but ultimately threw my hands up and said "okay whatever".

Shortly after I left the company, I got called up because the disk failed and the backups weren't restoring and they were in complete panic. Fortunately they were able to fix a backup image and recover from it, and then they migrated to RDS. So it wasn't really my decision but it stands out to me as a time when I should have stood my ground more firmly on a tech decision.

I usually don't regret the piece of tech, I typically regret either the implementation, poor requirements gathering, or lack of foresight in understanding how that particular stack component evolved over time.

But onto the list:

• Postgres: I have nothing against this DB, in fact it's my go-to when using a relational db, but implementing SQL requires an understanding of not only the syntax, but also how the DB engine operates. I've had teams bitten hard by bottlenecks we've created ourselves.
• MongoDB: Another Database that I personally favorite, we've had regrets here with devs trying to use it as a relational db.
• New Relic: Application Performance Monitoring is a pretty important tool when you're building at scale, but I got swindled by my account rep on cost projections when switching plans, the end result doubled my annual cost for the service. The service is good, but APM spend shouldn't be a comparable cost to cloud hosting or databases on my monthly expense spreadsheet.
• Mailchimp: I pay this company $50k USD a year and receive zero human interaction with reps from the company. I would move off of them to someone else, but it's considered tech debt and gets prioritized as such.
• Pre-Typescript JavaScript: I love JS, it's my bread and butter when it comes to what's driven my success, but it's 2022 and one of the SaaS products I manage is a 10 year old Node.js project. A lot of the foundation is based on outdated patterns (callback hell is an understatement) and APIs that have long since been deprecated. Given that the product is sold to the enterprise, the size of the project is not trivial and the lack of strong types and other pre-compiled safeguards means that it's an absolute pain to work on for anyone who's not intimately familiar with the codebase. Thankfully, we've stopped selling this product to new customers, with any luck we'll be able to off-board the remaining 20k users by the end of this year and turn off the lights.

In hindsight, I regret choosing redux-observables, because a) redux requires more boilerplate than is good for your sanity and b) rx.js makes it simple to handle complexity and thus can trick you into adding unnecessary complexity to your code.

A specific React component library that we were going to use company wide, I will not name it because it doesn't really matter. At first glance the demos looked pretty nice, it supported a lot of things that we needed. But then we started working with it and after a while we just got stuck. So many bugs and broken edge cases, documentation for the more advanced stuff that was completely absent. On top of that, its bundle size is GIGANTIC.

Since documentation was missing, I decided to look at their source and it was an absolute mess. What they did was make a base implementation in vanilla JS and then port it to other frameworks, so they could sell it for those frameworks specifically. Smart, but in the case of React they just made a thin wrapper implementation and didn't use the component lifecycle properly. As you might expect, they applied a lot of ducttape and monkey patches to make the thing work, sort of.

It is a commercial library, so we filed tickets as we had support with the license, but after a while decided to move to Ant Design and never looked back.

What we learned: 😳
Never let management make a push for a certain technology. 🤦‍♂️ They wanted consistency in the UX throughout the company, which is understandable, but devs should have had the final say. As a developer, I should probably have done more proof of concept tests and the issues would have come to light sooner, but management seemed pretty adamant in their preference, so I decided to roll with it and try to make it work.

This might be controversial, but for me it has to be using React for a little project at work a few years back. I had recently started learning react and thought to use it at work, even though we hand't used it before and the project was really small and simple.

In retrospect I should've used something simpler, for example Svelte or even just plain html/js instead. Adding react made the project quite a bit more complex than it should've been. As the project is small we don't work on it often so whenever I work on it I have to refresh on react and it takes a bit of time to get stuff done.