We all have our way of doing things, but there are still some general mistakes that we can avoid.
Here are the ones I've encountered most frequently:
1. Using over-complicated tech stacks
You can build an app that handles millions of users, using a simple tech stack.
Let's take a look at what HEY is using:
That tweet belongs to David Heinemeier Hansson, the creator of Ruby on Rails and the founder of Basecamp and HEY.
As you would expect, there are lots of opinions in the comments:
If you're skeptical about MySQL, you should know that Uber switched from Postgres to MySQL in 2016.
And sometimes, it's perfectly fine to use vanilla JavaScript.
The idea behind technologies like React and Angular is to use them for large web applications where you need to have states synchronized across many different UI elements.
In many cases, something lightweight can be more appropriate.
If you're not working on an application used by millions of people, you probably shouldn't focus on separating your app into microservices just yet.
You can take care of that later, when your application starts getting millions of users.
Surprisingly, a monolithic architecture can still handle 6-8 million users if you scale it and optimize it correctly.
We should focus our energy on delivering a better experience to our users, not to ourselves.
2. Ignoring Accessibility
We should only build websites that are inclusive and accessible to everyone.
There are six main key areas of disability:
• Visual
• Hearing
• Mobility
• Cognition
• Speech
• Neural
I learned a lot about Accessibility from this article written by Addy Osmani.
Accessibility legislation for websites is still in a gray area, but this might change in the near future and companies that do not comply might face large fines, similar to GDPR.
3. Ignoring cross-browser compatibility
Let's have a look at this chart from Stat Counter:
Google Chrome has a 63.6% market share.
Checking your website only on Chrome means you're leaving out 36.4% of your users.
The new version of Microsoft Edge is using Chromium, but it doesn't mean that your website will behave exactly the same in Chrome and Microsoft Edge.
Safari has a market share of 17.7% and it's using WebKit as a rendering engine.
And Internet Explorer is still here and the Service Manual from the UK Government still expects you to test your application in Internet Explorer 11 in 2021.
There is no silver bullet or magical solution for cross-browser compatibility, you still have to test.
Some testing tools might impair your cross-browser testing efforts from the start.
For example, Cypress doesn't work on Safari and Internet Explorer and there is no sign that it will ever offer support for them.
Since I work at Endtest, I'm very familiar with cross-browser testing, since our platform is used by thousands of developers to build and execute automated tests.
The best web developers I know always make sure that their applications work on all major browsers.
4. Working in a bubble
Developers can build an app for the Financial sector without knowing or learning anything about that particular domain.
It's easy to get away with this because everything is broken down into small tasks and the business logic is handled by a Product Team.
Taking the time to learn more about the domain and the users can help you deliver a better experience to them.
Start by discussing more with the Product and Sales teams, you can learn a lot from them.
5. Blind trust in open source
Open source is by far the best thing that has ever happened in the software industry.
The problem is that some companies are now using the term as a Marketing technique.
Some companies noticed that developers have a low tolerance for proprietary solutions, so they just rebranded themselves as open source.
This tends to give them a free pass to promote their brand on open source communities, to avoid security assessments and to fly under the radar of developers who might not realize that there is a for-profit corporation behind that solution.
Some of your favorite open source solutions are owned by for-profit corporations:
npm, Inc. is the for-profit company behind npm.
They raised over $10M and got acquired by GitHub in 2020.Nginx Software, Inc. is the for-profit company behind Nginx.
They raised over $84M.Gatsby, Inc. is the for-profit company behind GatsbyJS.
They raised over $46M.
A large number of open source solutions are actually developed and maintained only by employees, with no active community behind them.
And some for-profit corporations go to great lengths to give the impression that there is an active community behind their solution.
Remember how Kevin from Home Alone created the illusion that there were people in the house to scare off the burglars?
There are plenty of unethical techniques used in that space, such as hiring people to sit on public Slack and Gitter channels to defend that solution and dismiss alternative approaches, or offering small financial incentives to tweet about that open source solution.
Dual licensing isn't the issue here, that's a solid and ethical business model.
The real issue is misleading users into thinking that the open source solution is built by a community and its popularity is not artificially inflated.
It's always a good idea to investigate an open source solution before using it, as most of the hype might be the result of an obscene Marketing budget.
Top comments (5)
The problem isn't that someone is making money from that open source solution, the problem is that they might be spreading misinformation and it might affect your work in a negative way if you use it.
Let's take a look at two open source examples from the testing world.
1. Selenium.
It's open source and free to use.
There is no for-profit corporation behind it, it's literally built and maintained by a community of developers.
There are no limitations, you can use it in any way you want.
All the popularity that it has gained is due to it being effective.
2. A Selenium competitor, I won't mention their name, but let's call them "Cupressus"
It's open source and free.
But there is a for-profit corporation behind it.
It's built and maintained by employees of the Cupressus company.
It has limitations and in order to bypass them you have to purchase a paid service from them called "Cupressus Dashboard Service".
A large part of the popularity that it has gained is due to paid advertising and paying developer advocates to promote it.
The approach taken by Cupressus is unethical.
Because if you do not read the fine print and use it in your project, your team will discover later that they can't add your Cupressus tests to a CI/CD pipeline and they need to purchase the paid service in order to do that. And you've basically locked yourself into paying a subscription for something that you thought was completely free.
The other problem is with the concealing of the severity of issues and limitations.
For example, if Selenium has a limitation that would be a deal-breaker, you would find details about it, no person or corporation would have any interest in making you think that the issue is not a big problem.
As for Cupressus, it's a different story.
Let's look at an example.
One of the many limitations is that it does not work on Internet Explorer and Safari.
You can try an experiment, go to the public Cupressus Gitter channel and mention something that you're not sure if you're supposed to use Cupressus due to those limitations.
In less than 3 minutes, you will see one of their paid "henchmen" jump and say something like "There is no need to test your application in IE and Safari in 2020, everyone is using polyfills".
Because they have a financial stake in the game.
You will also see blog articles by writers paid by Cupressus to bash Selenium and call it "old", "flaky", "unstable", "unreliable", etc. Which is not true. In this case, it seems that they are spreading misinformation.
As developers, we tend to trust what we see on open source communities.
So, if you're not careful, you might end up using Cupressus because you read a few articles where they said it was the bomb.
And after a few weeks, your company realizes that they need to pay money so you can add your Cupressus tests in a CI/CD pipeline.
And after a few months, you notice that your website is not working correctly in Internet Explorer and Safari and your employer is losing money because of that.
Notice the difference between real open source and honeypot open source?
I didn't say that all or most open source solutions are promoted through unethical practices, I'm just saying that we should always investigate an open source solution before we use it.
Thank you for this write-up I never looked at open source projects from that angle.
You're welcome. Glad you enjoyed it.
I'm glad you liked it.