Software developer’s goals and means

Have you read the book The Goal? It is written like a novel about Alex Rogo, the manager of a production plant which is in severe trouble. While he manages to make the plant profitable and avoid shutdown, the book step by step explains the foundations of the Theory of Constraints. Although basically a management theory, the Theory of Constraints’ principles are so general that they can be applied in almost everything. For example, agile methodologies apply most of these principles (along with a number of other principles such as fast feedback).

One simple, yet very basic statement in the book struck me while I was reading it: “Always keep the goal in mind”. Sounds really obvious, yet it is difficult to do when lost in a debugging session, or have an in-depth discussion about corner cases of a software feature. Thinking about the goal in those cases often makes it easy to sidestep difficulties.

Read more: Software developer’s goals and means

Searching for goals

In the book, Alex Rogo is thinking about the goal of his factory. He has a number of ideas, but he knows there can be only a single ultimate goal that makes all other goals subordinate. Likewise, if you are a software developer, you also should pursue a single goal.

By the way, if you want to know the goal of software engineering, then don’t bother reading job postings or job descriptions. Those are describing the kind of software engineer they’re looking for, like someone who’s able to pick up the latest technology. They also describe the activities, like designing, coding, debugging. Those are not goals, but we still should keep the goal in mind.

Of course, we can also ask Google. But that also won’t help much. Although there are lots of pages about developer goals, those are short term goals or professional development goals, goals for the current year or whatever goals, but not the main goal for any software engineer.

How would we know what the main goal is? Just like the case of Alex Rogo: if you don’t achieve the goal, you’ve lost. Alex Rogo’s factory will shut down if he fails to meet the goal. Likewise, a software developer gets into serious trouble if he cannot live up to the goal.

The main goal

Then what is the goal of a software engineer? I think the main goal of a software engineer should be maximize value by solving actual problems for stakeholders using software solutions. Let’s dissect this one:

• If the developer does not solve an actual problem, then nobody would need the solution. So apparently the developer did not deliver any value
• If the developer solved some problem, but it was only a perceived problem instead of an actual problem, then basically the problem was not solved at all. The stakeholder wasn’t helped all, he still has his actual problem.
• If the developer solved some problem, but not for a stakeholder, then no stakeholder would be using it. This means that the time spent to create a solution was wasted.
• There are cases that a software developer solves a problem not by means of a software solution. I have done this a few times, where it turned out that the user could be helped by changing a setting, instead of a new software feature. Although this happens, these cases are rare. If these happen too often, then it looks like you’re in need for someone different than a software engineer.
• If the software developer only solves small problems for few users, then he is only of little value. The bigger the problems and the more users, the more valuable the software developer is.

Means

Maximizing added value: how can we do that? What tools and techniques can we apply? In the past, I already listed a few. Like: Always keep the user in mind, reducing cycle time, and How to deliver on time.

Other means that we can apply:

• Find out which problems need solving most. In the agile world, there’s often a product owner who prioritizes the backlog. But if your team does not have such a product owner, you’re on your own and you need to decide for yourself. But even if a product owner is around, developers also need to ensure that development problems are solved. After all, the developer is also a stakeholder in the project.
• For other problems, find out what the actual problem is. Often, users state that they want a feature without thorough thinking about the actual problem they run into. They are often not even aware what their actual problem is. I see it as a responsibility of the developer to not just implement what is asked, but always ask what the actual problem is. Talk to users and other stakeholders, find out what they actually need. This is often very different from what they say they need.
• Maximize the amount of work not done: find the simplest solutions that make the user happy. Dare to say “no” if someone insists on a minor fix that takes a lot of time, while you could better spend the time to something more valuable. For each feature, ask yourself whether it is really needed. There are more feature request than there’s ever time to build.
• Build and deliver in small increments. Provide the user with working software as early as possible. This has a lot of positive side-effects, plus the bonus of delivering value as early as possible.
• Make your life easy. This means: make it easy to read the code, and easy to change it.
• Optimizing for value also means that you need to think about the development process as a whole. Which parts of the process are cumbersome? Can things be sped up by doing something differently? Where do you waste time? Work towards improving these processes, so you can spend your time more effectively.