My Software Development Philosophy

5th November 2024

What is the most important thing when engineering a software app? Solving the problem, as simply as possible.

'Solving the problem' - what do I mean by that? Isn't that bit obvious? Yes. But software engineering is hard, and abstract. Building a small app for an arbitrary purpose can take days. Most real apps will take weeks, months and years. The problem needs to be at the heart of development, for all of that time. You can't get distracted by the fancy new technologies and frameworks, the trendy new language or even by other, less important problems. They are not The problem.

This is further exacerbated when working in a team, or company, where everyone has to be trying to solve The problem. If they aren't then the people working on The problem will be working across the ones working on other problems.

On top of this, what even is the problem? The problem is slippery, veiled, a lovecraftian mutating horror. Even if you understand it one day, the next it has escaped and morphed an extra head.

Your main stakeholders might understand The problem but their communication is imperfect. They hold a small battery torch to illuminate a glistening eel hiding in a vast black abyss. They might show it to you, but you catch a fleeting glimpse, and not the full picture before it rushes back into the blackness.

Simply understanding the problem is a huge undertaking, never mind solving it. And how about the second part of my original statement?

Solving the problem, as simply as possible

My outline of the problem, and the impossibility of nailing it down should explain the importance of this part.

You catch a glimpse of The problem - terrifying, dead eyes, fangs and writhing - then it's gone. But you feel that you understand.

You build out a heavy framework for a craft to capture the beast. It will be a deep sea submersible with four decks and the greatest luxury. A games room, two lounges and velvet brocade on every aperture. During building you are alerted by a cry from the stakeholder - The problem has been sighted, but in the sky! It has grown wings and soars in the nightmarish, cloud-boiling sky.

Your heavy-framed submersible cannot and will never fly. Your efforts are wasted.

Perhaps a lighter, simpler design might have been converted to an aircraft? Or better yet, caught The problem before it mutated.

The temptation is real for software engineers. Blogs and social media talk of the new great approaches and technologies. Microservices, vast, interconnected, database architecture webs. Apps so big they must be split into parts and have scaffolding larger than most apps simply to support their leviathan frames.

Don't lay foundations for a cathedral when we don't even know if what we need to build is as large as a house. That way lies madness and failure.

Solve the problem, as simply as possible.

I appreciate that this is vague advice, but it does truly form the core of how I build things. The centre around which all other things orbit and orient.

I hope to give more practical advice in the coming weeks about how to actually do this in more specific situations.