DEV Community

Doug Elkin
Doug Elkin

Posted on

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

We all try to choose the best tools for the job, but occasionally we may fall short. When did you choose unwisely? What have you learned in retrospect?

Discussion (26)

Collapse
duhdugg profile image
Doug Elkin Author

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.

Collapse
abhinav1217 profile image
Abhinav Kulshreshtha

Oh I remember this pain, many years ago, I was consulting a startup and they wanted all the latest buzz words in their stack. I tried to convince them to use rdbms but they insisted on using mongo because no-sql is the latest buzz. no-sql has its place but nothing can be more assuring than a data where relationships can be visualized. The amount of code I had to write just to make sure data being accessed is proper, The amount of cpu wasted by nodejs just to process data that could have been processed by a simple stored procedures or views.

Collapse
miketalbot profile image
Mike Talbot

Oh yes, built a side project with GCP FireStore and then looked how much it would cost to even try an aggregation for a bit of high level reporting. Ended up having to code around it at additional expense in terms of time, and a real reduction in functionality over what I planned.

Collapse
ben profile image
Ben Halpern

I think a lot of people found themselves in this kind of situation with NoSQL.

Collapse
ahmad_butt_faa7e5cc876ea7 profile image
Ahmad

amen!!

Collapse
ben profile image
Ben Halpern

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.

Collapse
xowap profile image
Rémy 🤖

Oh gawd all that stuff confusingly trying to fix browser compat and provide data bindings to the DOM but in a completely clumsy and unordered way. I'd say it's what gives JS such a bad rap about getting a new framework every day.

Collapse
ben profile image
Ben Halpern

it's what gives JS such a bad rap

I think our puny human brains have a hard time understanding how quickly things shift and change in the computer world while keeping the same name.

Like, if you don't like spaghetti in 2012, you probably won't like it in 2020 unless your tastes changed.

Not that JS has clearly changed for the better, but it has definitely changed in many ways — I think we have a really hard time being objective about these things over time.

Thread Thread
xowap profile image
Rémy 🤖

Well, JS was always a way to transform DB data into an interactive display and it's getting really easy to do so. I remember spending hours creating DOM elements by hand and binding events manually, there is nothing I regret :) [except maybe a few hours too many spent configuring Webpack]

Collapse
miketalbot profile image
Mike Talbot

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.

Collapse
aarone4 profile image
Aaron Reese

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.

Collapse
fyapy profile image
aabdullin

Pinia is official state-manager for vue 3 now😁

Collapse
aarone4 profile image
Aaron Reese

Yup!
:)

Collapse
xowap profile image
Rémy 🤖 • Edited on
  • 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.

Collapse
mistval profile image
Randall

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.

Collapse
theaccordance profile image
Joe Mainwaring • Edited on

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.
Collapse
lexlohr profile image
Alex Lohr • Edited on

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.

Collapse
ekeijl profile image
Edwin • Edited on

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.

Collapse
miketalbot profile image
Mike Talbot

I think I know the one you mean, or at least one very like it. Also used such a library but fortunately managed to abandon before too much was predicated on it.

Collapse
nombrekeff profile image
Keff

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.

Collapse
luccaprado profile image
Lucca Prado

Modelmapper (modelmapper.org/getting-started/) It was before I knew about Mapstruct, and I had several runtime problems with modelmapper (I assume part of the guilt, as my models were totally insane).

Collapse
shriji profile image
Shriji

Choosing angular over svelte.

Collapse
eljayadobe profile image
Eljay-Adobe

I can't think of any tech that I've used in a project that I've regretted.

I have had projects where the tech we're using probably would have been better off if we had selected a different tech (e.g., if we had chosen F# instead of C#, or if we had chosen D instead of C++). But by the time those sour grapes came to light, it was not practical to switch languages midway through the project — and maybe it would have turned out to be be worse.

As I like to say, "If we switch from Windows to Macintosh, we wouldn't have all these problems. We'd have all new problems."

Collapse
pandademic profile image
Pandademic

People are gonna hate for this:

I chose react. For building a simple 4 page website. Worst mistake ever , it was super overcomplicated. Maybe I did something wrong? 🤷

Collapse
ahmad_butt_faa7e5cc876ea7 profile image
Ahmad

I tried using twillio and that kinda turned me off due to the pricing... well now most languages have opensource built in frameworks for stuff like websockets

3rd party apis seem easy to implement at first but then can turn into a pain if you dont have a solid enough design + time for refactoring

Collapse
adamwdennis profile image
Adam Dennis

Not choosing NX for a monorepo, while instead spending weeks trying to bootstrap my project with internal libraries using yarn workspaces… glad I found NX shortly thereafter.

Collapse
makar2 profile image
Makar

AG Grid in React