The Tip of the Software Developer Iceberg🧊

We have a problem in software engineering, and this is represented by the programming meme at the top of this article. 

That problem? It’s the illusion of simplicity.

The Problem

As software engineers we have an acronym “KISS” — Keep It Simple Stupid.

We are all aiming to create clean code that is simple to understand, quick to create features and easy to maintain.

To say such things feels rather easy and is a stick that we can beat junior developers with, but unfortunately, things are not quite that simple.

What looks like clean and elegant code rests upon an iceberg of setup, config, boilerplate code, error handling, knowledge, testing and hard-won experience.

Photo by Tita @esutita on Unsplash

This is that old idea of a duck gliding along on a pond, hiding the frantic paddling going on beneath the surface of the water.

Since we are hiding the complexity of our work, we are giving the impression anybody can code, and anyone can produce that feature required by your product owner. This is now producing business owners who think that code can be produced by generative AI and why can’t you make that code work faster? We’re starting to miss the opportunities that coding brings.

Forgotten Foundations

The beginning of any product is all about optimism and the impact you might be able to make on that clean state.

We often think that things will be different, but soon enough realisty sets in. The hacks and shortcuts pile up and before you know it is the codebase that everyone fears to touch.

We need to get real. Under the surface of every codebase lies tech debt. There are always mountains of it. Even the best developers leave tech debt and fail to go back to fix those issues they created in a rush. If we all went back and added those unit tests into the code the world would be a better place but face it it doesn’t happen.

In my last project at [redacted company], we had a feature that was supposed to take a week. One week turned into three months, and by the end, the initial feature was about as recognizable as Frankenstein’s monster. The project manager saw the four lines of code and called it a success. Meanwhile, the dev team was left maintaining an unholy beast of spaghetti code and duct-taped solutions. For my part, I left the company for a pay hike and left the issues to someone else. 

This was a company that preached clean code (a noble goal, but an aspirational state). In reality, we are all working to get code into production by the next deadline without causing too many issues. We should communicate that so the business knows what is happening at the sharp end of software development.

Conclusion

We should be embracing the iceberg.

Every elegant solution has an iceberg of complexity sitting below it, and we should communicate this to all concerned. We work in a combination of sweat, blood, tears and ramen. Instead of making out that this work is easy, I think we should be drawing attention to those unseen 40,000 lines of code that made the feature possible.

Maybe they’ll give us enough time to refactor a few classes while we are at it. Just a thought.