Outsystems blog

Dr. Strangecode, Or How I Learned to Stop Worrying and Love Low-Code

Let me tell you about my strange love affair with low-code, even though it ruined my career as a programmer and hardcore coder.

The most unreadable, unintelligible, unmanagable, but legal C program in 1998. Image reference adapted from IOCCC Flight Simulator

When I was growing up, I had a life-changing experience: my dad bought a ZX Spectrum. That was the one event that blew my mind and forever changed my worry-free childhood (and life).

My destiny was set; I was on the road to becoming a hardcore coder.

Becoming a Hardcore Coder: Baby Steps

Not long after I’d gotten acquainted with the ZX and become a whiz at those fun Speccy games, my dad and I started copying code from books and magazines. This is where I first learned BASIC and Assembly. Little by little, the painstaking process of copying the code by hand from print allowed me to understand it. I’d work all the code in and then pray that it would work: RUN, ENTER... and sometimes it didn’t work. It was time for debugging.

A revisited game of Life in a popular Spectrum magazine with some hexadecimal code for good measure.

In high school, a group of friends and I played with a different set of more powerful machines: the Atari 800XE, the Atari ST, the BBC Micro, and the MSX. Many from that original group would eventually end up working in IT.

When I got to university, I learned how to work with Modula-2 (pretty much based on PASCAL), Java, and C++, which was how I first got introduced to this whole new notion called Object-Oriented programming. That was also when I found out I had a strong dislike for databases. To me, they were nothing but exotic filesystems.

How I KISSed and Made Up With Objects

After some night coding jobs, I eventually ended up with my first proper IT and programmer job right as Y2K was coming. So, this was very old school, hardcore, low-level C coding on the MS-DOS RTKernel and RS485 networking with a focus on fixing databases, my favorite (not). Somehow I also became responsible for taking care of the company’s intranet. Then came the day when, as a super user, I managed to use the good old destroyer of worlds command:

rm -rf

Remove. Recursive. Forced. A recipe for disaster.

I panicked. Slightly. The worst part of it all—or just a great opportunity to learn the hardest way — was the fact that the backups did not restore the system to its former state. So, I had to roll up my sleeves and rebuild the intranet. In one night. I got it done, but it was tough.

I remember another project where I had to code a layer on top of the original code because the core was just too rigid and strange. The reason behind it was the fact that they had implemented it the KISS way, but this time it meant Keep It Simple and Stupid.

Everything was an object and I mean everything. Usually one draws the line at integers and strings, but in that project’s code even one letter was an object. This meant debugging through a zillion classes before you ended up with the right method. This was the moment I finally started wondering if object-oriented programming really was the golden nugget everyone was talking about.

Chaos Monkeys

I had conquered major obstacles. I should have been on top of the world. But then, the company I was working for grew rapidly and got sold to an even bigger company. Sadly, most of the people I was working with started leaving, and I began to wonder if I shouldn’t just do the same.

This started a rollercoaster ride of worry and doubt for this hardcore coder. First, I changed jobs and became an employee in a company of three. I quickly got a website project to work on, through a contractor. I was having loads of fun, learning new ways of programming, doing code reviews and making actual architectural decisions when — seemingly out of nowhere — the company went bankrupt.

Through a winding road filled with complications and brimming with chaos, I ended up working for a non-IT company on a temporary contract yet still working on the same project. When the contract ended, I asked the company to employ me directly. They said they would love to have me, but there was a caveat: another company had bought them. Fortunately the other company hired me. And, all the while, I was still working on the same project, mind you! (This is an example of the tragically long lead-times projects had in those days.)

Eventually, I ended up working where I am now. In my early career there, I learned the ways of good old C# and XML. My company was satisfied and so was I until… what I thought was disaster struck.

How Low-Code Ruined My Career

My company wanted to find ways of getting even more out of my work. They wanted to maximize my ability to code; they wanted to help me become more efficient. So, off I went to an OutSystems Bootcamp. They had heard it was all the rage, it was the future of programming, going way beyond your run-of-the-mill object-oriented programming languages.

This instantly triggered all my alarms. Low-code? How could something that hid my handcrafted, precious code be good for me? And I just knew it would probably spit out code that was worse than the stuff Frontpage produced — with 10 times more HTML than was ever necessary.

I was pretty sure my career as a hardcore coder (a badge I wore proudly) was over.

The Bomb

Then during the bootcamp, OutSystems introduced us to Integration Studio, which nuked all my preconceived notions about low-code. I quickly saw that I could use the low-code capability for abstraction and functionality and still extend it with my C# code.

And that erased my big concern: what would happen when I reached the limits of what their platform could do? I didn’t know much about low-code, but what I did told me that there was a point where you hit a wall. Wrong.

With OutSystems, I can simply create components with C# or Java, and each will deploy as a DLL or JAR respectively, encapsulated in a reusable extension component. Basically, for low-level integrations, you just code once with Visual Studio or Eclipse, abstract it as an OutSystems component, and keep on using it with their visual IDE.

A Plutonium Award

I think the solution is elegant. And, better than that: it works. I can integrate with my systems, and I can integrate with my nemesis, the evil database. If Integration Studio is a nuke, data modeling is its plutonium. The setup to use my external DBs is done once in Integration Studio, and that’s it.

After I returned from the bootcamp, my company and I ventured into our first proper project with OutSystems, and that got us an award. And we didn’t stop there. We earned our certifications, we created projects, and we had to work around some impediments, too. And that’s when I had my epiphany: when you’re a good developer, low-code will just accelerate your way to the end result.

So yeah, you can say low-code absolutely “ruined” my career as a hardcore coder. Just not the way I thought it would.

A Silver Bullet? Not Quite, But Close

For some reason IT keeps reinventing the wheel every decade or so, but it’s a big step from the past and I cannot wait for the future of low-code and what it’s bringing us.

Like mobile, for instance. Talk about hardcore! Fortunately, one of the great new features of OutSystems 10 is low-code mobile development. All of a sudden I could become a mobile app developer, using the same tool I’d used since it was version 4.2.