Software build process
How I build software
A collaborative, iterative approach to building software.
A summary of the process I use to build software is:
Exploration - discuss and document requirements.
Proposal - produce a proposal and specification that describes what will be built and how the requirements will be met by it.
Implementation - Build and test the system, feature, or process documented by the proposal; this phase includes a rigorous QA process. This uses the overall process in miniature; each feature is built via a process that follows the same 4 phases defined here.
Review & rectification - software development is an imperfect process, and it's important that the software is tested by the people that are going to use it. Any defects found during user testing go into rectification to be fixed, re-tested, and regression tested. Regression testing is the process of making sure no other features got broken by a change.
Each phase is iterative, as is the entire process. Quite often, a single feature will be built at a time (this makes it easier to test each feature as it's built, as well as shortening development time so that new features are available more quickly).
It's also important that all stakeholders are involved at every phase, and that consensus is reached on the important outputs of each phase.
This process aims to involve stakeholders at every phase to ensure that what is delivered is accurate to the requirements as well as reacting to changes as they arrive.
For more details of what each phase entails, please read on.
Our highest priority is satisfying the customer through early and continuous delivery of valuable software.
Exploration
Before any code is written, it's important that we agree on exactly what the code that will be written should do, especially in the age of agentic coding. Code written by agents is only as good as the specification of the task.
Exploration is about ensuring that you get what you want, as well as making sure that I can actually do it, and that you should do it; sometimes the output of an exploration phase is just "no, you don't need to do this". This is an entirely collaborative phase; the output is only as good as the inputs, so it's important that we discuss and agree the requirements up front.
The exact form exploration takes varies by the requirements; for a small system it might be half a day of conversation with a business owner; for a feature being added to a complex existing system it might be a day working with the people that use the software to understand what's needed and why.
The output also varies; exploration for a simple system might produce a full specification in a day, a complex system might require 2 weeks of back-and-forth, but the end result will be a document that details the findings of the exploration.
Before we move forward, we will both agree that what was found during exploration is accurate and describes the current situation correctly.
Business people and developers must work together daily throughout the project.
Proposal
The proposal phase produces detailed documentation explaining what will be done and how. You do not need to understand the how - that is for me - but it's important that you agree on what is being built.
This phase is about ensuring that I have correctly understood your requirements, and that the system or feature that gets built is fit for purpose.
It is vital that at this phase any deviation from what was agreed during exploration is called out and documented. Changes are fine, and even welcomed, but it is important that we agree on scope and what will be produced before the implementation phase starts.
Although changes can still be applied during the implementation phase, we should both agree on the original proposal so that changes in scope during implementation are called out explicitly, and you can decide whether the change is worth the additional effort.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Implementation
Implementation is the development of the system, feature, or process that you need, and it is once again a collaborative and iterative process.
I aim to work in an agile fashion, in a way that fits with how you work. This might be Scrum, or Kanban, or a less formal methodology; these are processes built on top of Agile and are not the thing itself.
The aim of an agile process is simply to deliver working, valuable software as quickly and efficiently as possible. What form that takes is up to you; I have found that the more involvement stakeholders have at every stage of a project, and the more rapid the iteration, the better the outcomes tend to be.
The output of this process is a fully tested, working version of the system, feature, or process that you requested, based on the proposal and specification.
It is expected that more than one iteration may be required to reach the exact required solution; this is not a defect in the process, but a consequence of how software development works. You might have forgotten to tell me something; I might have missed something; testing might reveal that the proposed system's User Experience needs to be improved. These are human things, and agile processes are designed to cope with them.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Review & rectification
Software, and especially complex software - however well engineered, however well built, however carefully tested - has bugs. It's an unfortunate fact of life, and even in the age of agentic coding there is no way around it.
There are a lot of reasons for this; a misunderstanding about a requirement, a poorly written spec, an unfamiliar process, or just plain old human error. That is why this process is vital; having recognised that bugs exist, there must be a way to fix them, and to ensure that fixing them doesn't break anything else (regression testing).
Each bug may have its own mini-cycle of exploration (what happened and why), proposal (how do we fix it), implementation (fixing it), and review (ensuring the updated code works as intended and hasn't broken anything else).
50 - 80%
of the cost of a software solution is maintenance (pegotec.net)
Quotes on this page are taken from Principles behind the Agile Manifesto.