Solving the problem

What is the problem?

Outside academia and games, software is usually built to provide a solution to a business problem. We don't do it just because we enjoy building it; we do it to fill a need or provide a solution to a problem (although admittedly sometimes the problem is "the CEO does not have All The Money yet").

Of course, developers would like to build software that's elegant and beautiful and works flawlessly, and ideally never has to interact with an actual user, and spend as much time as they like getting the architecture and technical design exactly right (although usually the answer to "what is the right architecture" for a given system is "it depends") but inevitably trying to do that runs into The Budget.

So, the first stage to building a line of business application is to identify the business problem that you're solving, or find somebody with a business problem that can be solved by software and offer to solve it for them.

There is an issue though; if you talk to a developer about how clients define requirements, you'll find that we can be a bit...touchy about it. Clients are legendarily bad at explaining what they actually need, because often it's not well defined and needs to be properly analysed and thought through; this is why most developers aren't scared of clients replacing them with generative AI, because AI code generation needs very accurate instructions and descriptions of requirements, which most clients simply can't do because they haven't thought about it in the sort of detail required.

Solving the problem

So, most commercial software is written to solve a problem that a business has. Developers would like to build elegant, well-architected, fully-tested systems and "the business" usually wants them to do that in about half of the time it would take to do it properly.

Since the business has the money, and developers need to be paid to survive, we have to write software that solves business problems rather than just writing things for the fun of it, and we usually have to suck it up and do the best we can with the time the business is willing to pay us for.

This is why business analysts exist; developers are impatient, cranky, and need to be precise because we have to tell computers what to do, and those things are incredibly pedantic. Much better to have somebody that is willing to sift through requirements, analyse them and convert them into actionable tasks (or user stories, these days) that a developer can actually work on.

Of course, some developers are good at identifying business issues and applying technology to solve them. I'd like to think I'm one of them, but a business analyst is still a valuable resource on a project because they save a lot of (expensive) developer time; it's hard to go from gathering requirements to writing code, and that context switching takes time and effort that could be better spent on designing and building systems.

Conclusions:

1. Get a business analyst. You'll be glad you did.

2. Make sure that your developers are solving the actual business problem.