There are three questions that face any software development project regardless of whether it is being developed by an individual, a small startup or a large enterprise. Answering these questions will often lay the foundations for the project’s success or failure.
The questions are pretty simple: Can we think of a solution, can we build that solution and finally, can we live with the solution that we’ve built? Their simplicity belies the complexity behind each one.
Can We Think of a Solution, Can We Build That Solution, Can We Live With the Solution We’ve Built?
The Three Questions of Systems Development
Despite the relative simplicity, and arguably the logic of these three questions, many projects are following development processes that skim on the first question and often ignore the last. In this post I’m going to outline these questions and why they are the most important questions in software development.
Can We Think of a Solution?
Think back to the most recent projects with which you’ve been involved. Consider two things: first, how was the problem defined, and second, how many options were considered to solve the problem before settling on the one that was pursued?
Despite the efforts of the design thinking community (amongst others), the first issue – defining the problem – is either assumed, or given cursory attention in many software projects. Bringing a greater discipline to the exploration of the problem before committing to a solution would, in my opinion, substantially improve the outcomes in many software development projects (and beyond that arguably). How many projects apply any level of rigour to defining the problem? Arguably far fewer than those that jumped directly to designing and building a solution.
If we don’t first define the problem, then it seems reasonable (if not rational) to expect problems further down the line.
I’ve always admired the Double Diamond model, which offers a strong conceptual approach for working towards building a focused problem definition and a similarly focussed approach to a solution.
Start by exploring the problem, applying some open thinking to consider the widest range of factors that it comprises. The factors are then reviewed, analysed until ultimately we converge on a definition of the problem that should be solved. It is at this stage we can begin to document requirements for that problem.
For many projects that I’ve looked at, the development process jumps far too quickly into requirements gathering rather than establishing what problem is being solved. Whether it’s as formal requirement definitions, use cases, or user stories many projects leap to a phase that can anchor an implementation to a solution before they’ve defined the problem, or before they’ve explored a range of possible solutions.
As a quick bit of homework, review of some recent requirements for a project you’ve been part of. Do those requirements appropriately capture the needs, or do they subtly suggest a specific type of solution? The way requirements are defined can establish limits on the implementation often before the actual solution has been agreed. For example, is there a user story for uploading a document / image / file to the web site? When was it decided that the delivery mechanism would be a web site rather than an App or some other mechanism? When in the process did these user stories start to appear, how many assumptions are baked in, and what decisions are implied in their definition?
The second step in the model applies the same open thinking to the range of solutions to the problem before converging on the actual solution that will be pursued. This phase is typified by rapid iterations, where the edges of the proposed solution can be tested, the side effects evaluated and some of the cost and resourcing requirements identified.
Time for a bit more honest reflection. How many approaches to building the solution were considered before starting development?
The chances of a solution being both correct, and best suited to solving the problem is a function of how many alternatives were considered. If only one solution is considered, then the project’s success is entirely contingent on having discovered exactly the right solution first time.
When this first question is actually answered, the result is an understanding of the problem being solved that is shared between the commercial and technical sides of the business, and importantly why this is the problem being solved. Armed with that understanding, the set of capabilities and requirements can be defined that sets the context for the solution. A high level solution design follows with a supporting architecture that closely aligns to the problem being solved.
Can We Build the Solution?
The first question clarified why this project was being developed, what is going to be needed, and, at a high level, how it will be developed, so what’s left to consider?
Quite a bit as it turns out.
The emphasis in this question changes depending on how much effort was expended in answering the first question. Where little time has been spent on exploring the possible approaches to the solution, then the emphasis is really on ‘can‘ – can a solution be built at all? I’m constantly surprised at the number of projects that I encounter where, under the umbrella of an ‘agile’ process, a development team has started working against a short backlog of work; somehow the architecture is expected to emerge. John Ousterhout, in his excellent book ‘A Philosophy of Software Design’ discusses this, discussing ‘Tactical Programming’ in contrast to ‘Strategic Programming’. More on this in a separate post but simply put, if developers have started coding and you don’t have either an architecture or a scope, you simply don’t know if you can build the solution.
The earlier that a problem can be identified and managed in a project, the less expensive it will be to fix. We’ve known this since the 1970’s, and yet there are still an extraordinary number of software projects that rely on an emerging architecture rather than an intentional architecture.
If on the other hand, if the project dealt with the first question reasonably well, then the emphasis for the second question shifts to ‘can we build the solution’.
A high level architecture will establish how the solution should work from the perspective of code (for want of a better description). But not how that code will actually be developed. To put it in more concrete terms (pun intended) an architect will tell you how your building will come together, but won’t decide how the construction teams should operate.
To fully answer the question of whether ‘we’ can build the solution as described, some thought needs to be given to the overall model of development that has been adopted. This includes staff, skills, processes, how your teams are structured, and how that structure relates to architecture. How comprehensive, and how stable are the requirements? Finally is there sufficient budget to support the development effort, including recruitment, training, and technology and operations costs. Finally what are the anticipated (or sometimes necessary) timelines, and how well do they marry to the expected capabilities. Each of these considerations introduces factors that increase the risk that can impact the successful delivery of the project.
Do we have the staff in place, and do they have the skills necessary to build the solution as designed? Can we be sure that they are going to be dedicated to delivering this solution, or are they going to be pulled in to other priorities, such as fixing other systems. If we don’t have the staff in place, how much time is going to be dedicated to the hiring and onboarding process, all of which will draw on the existing people. Then we need to make sure that the staff we’ve assembled are familiar with the technologies that have been selected for the solution. Finally we need to ensure that they are structured in such a way to minimise the introduction of bottlenecks to progress.
Agile, and perhaps more specifically Lean software development approaches have done more damage to the stability of requirements than any other factor. Agile methodologies were specifically conceived to deal with projects where the requirements are unclear or ill defined. Lean, similarly advocates an iterative approach that evolves the solution over time to ultimately deliver the desired outcome. Over time, this has mutated to an approach where the bare minimum set of requirements are produced to allow development teams to start coding, falling into the demo, review, backlog update cycle to gradually get closer a desired outcome. Requirements volatility in more traditional project management circles can add a risk weighting of up to 25% to the project schedule.
Finally are the financial resource in place to pay for the development of the project, keeping in mind that the timeline for the project is impacted by all of the previously identified risk factors. Depending on those risk factors, and again how much work was undertaken to answer the first question, the estimated time to completion may be out by 400 – 500%.
The friction that emerges between the commercial and technical teams in the development of a project is often as a result of a lack of visibility into these risk factors. Each factor can impact the team’s ability to make progress on the project, but many of these factors remain invisible not only to the stakeholders, but to the team themselves. Building a comprehensive model that represents what is really going on in development teams is key outcome of the work I undertake with clients.
Can We Live With the Solution We’ve Built
The solution produced is not finished from the moment it is released. If we’re developing under an agile methodology, a release is likely to be the first of many.
Every development project is a series of compromises. Those compromises may be in relation to the capabilities of the solution, they may be in relation to the systems on which the solution is running, they may be technical compromises resulting in technical debt that will have to be dealt with, or they may be in relation to budget, timelines or some other factor.
Keep in mind just how long this solution might remain in operation. I’ve worked with more than one client who are running systems that initially went into operation over 30 years ago (the oldest is over 50 years old).
Living with a solution is a matter of cost and resources. Can we afford to run the solution, can we afford to maintain it, and how much do the compromises made during the development impact any future enhancements to the system.
There are numerous instances of systems that were so poor that their stakeholders simply could not live with them, or had to spend vast sums of money to bring them up to a standard where they would be lived with.
Here in Ireland we had the PPARS system, initially budgeted at €9m, but ultimately being cancelled having burnt through €220m and still only completing a fraction of its intended functionality (this was back in 2009 when that kind of money was really significant). This was a personnel and payroll system, not exactly rocket science. In a similar timeframe, Heathrow Airport Terminal 5 opened in 2008 with a buggy baggage handling system that meant that you were more likely to lose your bag when travelling through the airport rather than it arriving with you at your destination.
Something a little more recent? In 2023 an FAA system in the United States known as NOTAM crashed due to an engineer ‘replacing one file with another’ causing the system to become corrupted. The result? A ‘ground stop’ event that halted all aircraft takeoffs.
But those are just failures. More common is the situation where the system is live, and quickly heading towards becoming a legacy system. It needs to be managed, have bugs fixed, enhancements need to be made and in larger enterprises it may need to integrate with a wider range of systems. The solution and design established when answering the first question will determine the extent of time, resources and of course money will be required to live with the solution.
Often, this is the hidden cost of the solution. The full extent to which living with the solution draws on our existing resources is often not fully captured in any one place, leaving guesswork and opinion the only source of information.
Our new Modelling Needs
Much of the work Xorcon takes on is to help companies build the models that comprehensively represent their technical activities. These models look to provide the visibility companies need to determine the health of their technical operations, and as a result the health of their technical projects.
The root cause of many of the issues identified in these models can be traced back to how well these three questions have been addressed in the project. Answering these questions is simply returning to a stronger engineering discipline, which will logically result in better outcomes than if they are ignored. There are many other factors that can affect the final outcome of a project, but at a minimum, the foundations will be strong.
Support Ukraine
The invasion of Ukraine is an act of aggression that we should all oppose and speak out against. I will continue to Stand with Ukraine and its people until peace is restored.
Photo by Startup Stock Photos: https://www.pexels.com/photo/blue-printer-paper-7376/
Bows and Arrows 
Leave a comment