Software development is more than writing code

Ask someone what software development is and most will say "writing code." It's the visible part, so that's fair enough. But I've spent nine years building ERPs, HR systems, school management software, and a handful of multi-tenant SaaS products, and the same thing keeps proving true on every job: the code is rarely what decides whether a project works out.

Better code helps. A better process is what actually gets the thing shipped.

That process has a name. The Software Development Life Cycle is the set of phases every serious product moves through, whether the team bothers to name them or not. There are seven of them. Skip one and you don't really save time, you just push the cost further down the line where it's more expensive to deal with. Here's what each one is for.

1. Understanding the problem

Every project starts with a sentence that sounds complete and isn't. "We need an inventory system." Okay, but how many warehouses? One branch or several? Do transfers between them need tracking? Barcode scanners, or people typing? And who actually sits in front of this all day, what does the manager want to see on a Monday morning?

The first ask is never the whole requirement, and fairly often it isn't even the real one. I once had a client request about two dozen downloadable reports. A few conversations later it turned out they didn't want reports at all. They wanted one screen with live numbers on it, and reports were just the only way they knew how to ask for that. Finding the actual problem underneath the requested solution is the whole job at this stage. Get it wrong and everything you build afterward is balanced on a guess.

2. Planning

Once you understand the problem, the urge is to start building straight away. The teams I trust wait a little longer.

Planning is just deciding a few things up front. What gets built first. What's deliberately left out. Where the risky parts are, and which risks you can live with. How the work splits across people. It won't make the unknowns disappear, and anyone who promises that hasn't shipped much. What it does is shrink them down to a size you can actually manage.

3. System design

Planning covers what to build. Design is about how. The shape of the database, where you draw the lines between services, the security model, caching, what happens when traffic suddenly triples, how the thing talks to the software the client already runs. Those decisions get made here, before there's much code to undo them with.

A building gets a blueprint before anyone mixes concrete, and software works the same way. Most of this never surfaces for the people using the product. Nobody logs in and admires your indexing strategy. They just notice, every single day, whether the thing is quick, steady, and still standing when a lot of people hit it at once.

4. Development

This is the part everyone pictures. Designs turn into real screens, the business rules get written, features start working. It's genuine work and it takes skill.

But getting code to work is the easy bar to clear. The harder job is writing code that can be changed later, because it will be changed later. Clean code, SOLID, DRY, code review, tests, documentation a human can actually follow: none of that is box-ticking. It's there because the code you write this week gets handed to someone else next year, and that someone is often you, having forgotten how any of it worked. The developers I rate don't just close today's ticket. They leave next month's change less painful than it would have been.

5. Testing

Before real users turn up, you want evidence instead of hope. Testing is how you find the broken bits before a customer finds them for you.

What happens when the payment goes through but the order never gets written? When two people buy the last unit in the same second? When someone pastes in data no reasonable person would type? You almost never hit these in a demo. You hit them in production, constantly. Unit tests, manual QA, load testing, a round of user acceptance: each one exists to catch the failure now, while it's cheap, instead of at two in the morning with an angry customer on the phone.

6. Deployment

Plenty of people still think deployment means copying files onto a server. It stopped meaning that a long time ago.

These days the release usually runs through a pipeline that builds, tests, packages, and ships on its own. Some teams push the moment the tests pass. Others put a human approval in front of production. Both are fine, and which one you want mostly comes down to how much damage a bad release can do. Either way the aim is the same: get it out safely, with as little downtime and as few chances for a human slip as you can manage. It's the moment months of work finally meets someone who'll actually use it.

7. Maintenance

Here's the part that catches people off guard. Shipping isn't the end. It's the start of the longest stretch the software will ever live through.

The minute real users arrive, they start finding things. The logs fill up with cases nobody tested for. Traffic grows. The database that was fast at ten thousand rows starts to crawl at ten million. Libraries need patching, security holes need closing, some third-party API you depend on changes with no warning, and the business itself keeps shifting underneath the product. Maintenance is all of that at once: watching, tuning, securing, fixing, improving, for years. A launch that goes off perfectly is nice. What actually matters is whether the thing is still doing useful work three years later.

The point of all this

None of this is a checklist you run down on the way to a launch. It's closer to a way of thinking about the work. Each phase is there because it takes a particular kind of risk off the table before that risk has a chance to grow into an expensive mess.

And you don't have to write code for any of it to matter to you. If you're a founder, a product owner, a project manager, or just the person signing off on the budget, knowing roughly how the lifecycle hangs together is what lets you see why decent software is a team effort. It starts well before the first line of code and keeps going long after the last one.

The frameworks change every couple of years. The part where you actually understand the problem doesn't.

---

I write about architecture, delivery, and the unglamorous calls that decide whether a project ships. If that's your world too, find me on LinkedIn and let's compare notes.