The following is a guest post from Nacho Iacovino, developer advocate at Clerk, who recently chatted with us about the findings from our 2021 State of Internal Tools report.
I recently found out that developers spend 30% of their time building internal tools.
As companies get bigger, the problem gets worse. It's crazy to think that for companies with 5000+ employees, developers spend 45% of their time on internal tools.
If the main benefit of internal tools is to improve productivity, it seems developers are wasting a lot of productivity to make it happen. Why?
According to Retool’s survey of 650 developers (report insights here), about 2 in 3 developers default to building fully custom apps from scratch. No surprises there.
One step deeper, the programming languages of choice are JavaScript, HTML/CSS, SQL, TypeScript, and Python. The frameworks of choice are React, Express, jQuery (surprising!), Angular, and Vue.js.
If you ask me, it makes sense. React, Angular, and Vue are the most popular frameworks and if the company is already building its product with it, the logical thing is to also build its internal tools with the same technology.
As I said, it's surprising to me to find jQuery so high on the list, but I also understand there's a lot of old companies with 15-year-old codebases that haven't adopted the newest and shiniest frameworks.
The survey found that low code adopters are still the minority, but those that picked them up are overwhelmingly satisfied with their choice, and want to keep working with these tools in the future.
But many developers are hesitant to try low code tools due to pride. We all want to believe that we can build the best possible solution for our unique problems.
The irony? We have no issue offloading some complexities to pre-built solutions, and abstracting away some pain points through the use of libraries and middleware.
Face it: If you use React to build apps for the web, you've chosen a low(er)-code option, compared with the alternative of vanilla JavaScript which would take many more lines of code to achieve the same results.
Let's look at an example, what would you rather do, copy and paste the same HTML code over and over OR iterate over an array and render the same component with slight modifications? One is easier than the other.
Vanilla JS:
React:
Now, imagine the same thing but for 50 items instead of 3. And we are not counting all the optimizations that are going on in the background without you even realizing!
Some of the tough stuff has been hidden from your immediate view to make your life easier.
That's a good thing!
If you've been coding for a while, you'll remember when we used to minify our own CSS and JavaScript files and then upload them over FTP, and now we have bundlers and our code gets deployed automatically when we push to GitHub. Our lives got easier.
Low code app building makes it even easier.
Think about it: If your team needed to implement a new payment processing system for your company's website, would they be able to build a service from scratch that is as powerful and robust as Stripe?
How long would that take? How many hours, weeks, months, years of work would have to go into building and maintaining that?
Something like this would have a tremendous amount of complexity and would have to be very well written, very well documented, and very well maintained—which costs time, money, and resources.
We all understand that you can just let Stripe do it for you, get it set up by the end of the week, and spend a pittance of the price compared to what it'd cost us to build our own.
And then Stripe's teams of engineers get to worry about maintaining the platform, and the API, and all of the necessary security features, so you don't have to.
You’re already minimizing the code you write. Low code app building is just another step in this direction.
“Internal tools” are primarily being built for information management: dashboards, admin panels, data entry, customer support apps, or general management.
These are what we affectionately refer to as CRUD apps: tools that allow us to Create, Read, Update, and Delete information stored in databases. They're the bread and butter of a developer's work, in that they are ubiquitous and also, well, usually pretty bland.
Not super exciting.
I think it's safe to say most of us would rather be solving more interesting problems. Haven't CRUD apps been done to death already? Would it even be possible to reinvent this wheel in any new shape or size? Why bother?
Most companies have at least one full-time employee dedicated to internal tools. These employees are typically engineers, but they serve a wide spectrum of end users within the company.
Maybe that doesn't seem too significant at first glance, but when you consider that the median salary for a software engineer in the United States sits comfortably in the six-figure range, it's easy to wonder if resources are really being allocated in the best possible way.
Source: Statista
Don't get me wrong: the last thing I want to see is fewer well-compensated developer jobs.
But wouldn't it be a win for everyone involved if that engineer could be relieved of their full-time duties with internal tools, and instead focus their energy on customer-facing solutions?
Sure, you get more pride from spinning up your own solution…even when there are better, easier, and cheaper alternatives available.
I get it. As developers, we want to feel ownership over the things we build and maintain, and when we are given a task involving drag-and-drop tools, we start to feel like maybe we're not "real" programmers anymore.
I've seen it a million times before in discussions about whether WordPress developers who use visual editors are actually "real" developers. (Short answer: yes.)
I consider myself a "real" developer and I wouldn't be able to code if I weren't standing in the shoulders of giants that came before me. Have you ever checked code written by Margaret Hamilton, the woman who led the NASA software team for Apollo 11?
How many us would be capable of doing something similar nowadays?
Does that mean we’re not "real" developers?
I don't think so.
One way that modern low code tools cater to skeptical developers (like me) is by leaving plenty of room for the so-called "IKEA Effect.”
This refers to the idea that we as consumers tend to value things more when there's some assembly required, even if it's as simple as adding a cup of water and a single egg to a box of pre-made cake mix.
For me, the IKEA Effect helps explain why I enjoy building sites with a headless CMS and fancy front-end JS frameworks like Next.js even though I know that WordPress would make my clients just as happy and they wouldn't even notice the difference.
Creating it myself and putting my own touch to it is how I come to appreciate it and take ownership of it.
A platform that champions visual programming needs to respect this and let developers put their own touches to customize the internal tools they build to their liking. I believe this will make a crucial difference for whether developers ultimately decide to adopt and embrace low code.
Low code is here to stay. The better that tools like Retool or Zapier get and the more developers give them a chance, the more we are going to see a big shift on how internal tools are built.
As I explained before, why have five full-time developers maintain an internal tool when you can use a low-code tool, have one maintainer, and have the other four developers building your actual product?
I hope you enjoyed my thoughts, if you want to discuss anything on this article with me, feel free to reach me on Twitter at @nachoiacovino.
Reader
