In my 20+ year career as a coder I have seen, many times, cases where someone thought they had found a way to make things easier and simpler, and, this is the crucial bit, more powerful.

I did a maths degree at Uni, and I intrinsically understood the problems here. It’s the law of diminishing returns. Let’s get concrete with some examples.

The no code lego-esque dream that never dies⌗

The first time I thought about it was in my first job out of uni in 2002. The company I was working for, which you will have never heard of, was looking at XML as the go-to buzzword moneyspinner du-jour, and had designed some XML concept around building websites using XML.

Some ahead of the game engineer had understood the W3C wanted to move everyone from HTML via xhtml to XML, and use XML as the future of hupertext documentation. And this engineer thought to themselves, hang on, perhaps we should make the back end XML as well, and that way, the whole thing is XML? Extra buzz word bonus points and trebles all round!. Not quite.

Maybe the dream was not shared after the engineer left, but what we ended up with was if statements inside XML elements. And switch-case statements. The idea was that these XML documents would be understandable by a computer program and a simple no-code gui could be created to plug these things together. Eventually a GUI was built and then to create an if statement you had to choose it from a drop down. I guess you can see the issue. The non coder still had to approach their problem as a piece of programming. Just because there were if statements.

The dream was that we will have things like a “product” component, and then a “container” component and then a “payment” component and somehow these will all work together to make an ecommerce site, or a brochure, or perhaps you could combine the “product” component with a “news” component and get something that shows news items with adverts for products in them.

The belief at the management is that these components would all just connect together. They didn’t understand that to make components like that, each new component would require thought and consideration and potentially extra information to connect to each and every other component.

The fundamental belief was that normal people would be able to do complex things without considering complex things. And in doing so they created an XML based programming that was always changing and never documented.

The idea has been refined, and is now called No-code. But it’s similarly constrained, whenever you want to do something that their system can’t do you need a programmer who not only understands what you want but how it fits in this new system.

Amazon RDS vs self-hosted PostgreSQL⌗

Another example of failing to hide complexity, I would say, is Amazon RDS. Amazon RDS provides a Postgresql backend and so, if you have a database you can either run postgresql yourself, or you could use a hosted service like Amazon RDS.

The sell is that Amazon will manage the server for you. But you still get exposed to various bits of complexity that you need to understand. What version of Postgres are you migrating from, how much will it cost, what extensions are available. This may sound complicated, but it’s not as complicated as the queries an experienced dev will write.

Perhaps they will manage the backups for you. But I refer you to the adage “A backup that isn’t tested doesn’t exist”. Where are the backups stored? What if Amazon’s lost them. How would you know? You can’t just hide these questions away. How often are the backups run, how do they impact our response times? Do they cause lockups? Moving to RDS doesn’t take these issues away, you still have to consider these complex issues.

When it works⌗

You can make complicated things easier only by compromising power and going with some kind of middle of the road solution. This may be fine in many cases. If you are testing an idea. If you need something quickly. If you are learning.

Hidden cost of ignoring complexity.⌗

But in some cases, it’s the fine details that make the difference between profitability and failure. In my work in ecommerce, the ability to correctly understand complex pricing structures of delivery companies made a massive difference to how we boxed items, and the delivery charges that were saved. That allowed for lower pricing which helped win the bulk of orders, because something costing > £100 was <£5 cheaper, because we packed better. At the complex edge of the problem.

So sometimes a middle of the road solution is great for your purpose, but sometimes it’s completely insufficient. And if you don’t engage with the complexity you might not even realise that this kind of stuff is going on.

So guys, watch out for products that do things for you and you don’t understand what’s going on, you might be missing out on some good stuff. Embrace complexity on important stuff.