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?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Undetectable Backdoors in Outsourced Machine Learning Models: A Theoretical Vulnerability
Mike Young -
2563. Count the Number of Fair Pairs
MD ARIFUL HAQUE -
A beginner's guide to the Stable-Diffusion-V1-4 model by Compvis on Huggingface
Mike Young -
How does WebAssembly enhance web application performance?
Techcreator USA -
Top comments (27)
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.
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.
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.
I think a lot of people found themselves in this kind of situation with NoSQL.
amen!!
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.
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.
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.
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]
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.
Pinia is official state-manager for vue 3 now😁
Yup!
:)
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:
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.
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.
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.