This post is the third in a series on writing software.
The first introduced the most fundamental of the principles of concern in creating software. That of purpose.
The second took that idea further. It spoke of turning a problem into a vision for a solution.
With a vision in place, we’ve moved through the first and most fundamental of the questions we need to answer regarding any undertaking: Why?
One must crawl before one can walk. Getting clear on why we’re doing what we’re doing is the foundation of everything else. With that in place, though, we can turn our attention to the question of what we’ll do to address the problem and move into the next level in the hierarchy of questions: What?
Before deciding on the how, we have to think about what to build. Sometimes, this means building custom software. Often, software that solves the problem already exists and can just be used and/or software is not the best solution to the problem. Dan North, on .NET Rocks! articulated the idea that has stuck with me of the years (starting around the 48:18 mark) of software developers behaving like “the surgeon who tells you you don’t need surgery.” This is something of which we should always be mindful.
You don’t need to deliver software to your customer/business/stakeholder/etc., but rather results. You need to give them something that solves their problem. That could mean paper and pencil is the best solution.
If custom software is the answer to the question, though - if it is the solution to the problem, then - and only then - should your attention turn to what it is that you will build.
What you will build is not a question of programming language or where to deploy. It’s not a debate on architecture. It’s not a decision point on user interface look and feel or design.
At this stage, we’re thinking about the software in the hands of users and what type of experience it should deliver. Having an idea of what the interface will present to the user is relevant, but it’s only an idea.
All of the questions of technology and layout and posting forms and single page applications and distributed systems and datastores are answers to the question of how to build it.
They are not relevant to what. The answers to what to build will inform the decisions you’ll make on how to build.
Why leads to what. What preceeds how.
It’s only after having decided what to build that we can start on the exercise of starting to design software.