An experimental approach to software development
Over the years we have developed an approach to software projects which is based around experimentation and validation. I have spoken before about the fact that science sets you up well for software development because programming is largely based around building up solutions to problems from smaller logical steps.
And if the methodology of solving scientific and software engineering problems are closely related, why should the process be any different?
There is a well defined scientific process for solving problems:
- Hypothesise
- Collect evidence
- Draw conclusions
If we apply this process to software development, it can be a very powerful tool in design and architecture.
Hypotheses
A hypothesis is something which you propose to be true as a basis for further investigation. People often make assumptions when starting software projects, for example that a technology will meet all of the necessary requirements, but don't fully define or record these assumptions. A hypothesis is in some ways one level above an assumption. A hypothesis is an assumption which you do not know to be true. In order to be able to continue with the project under than assumption, it needs to be proved, and this requires evidence.
It is important at this point to define the criteria of proof. If you are about to embark on a proof of concept, you need to define the criteria of success.
For example, if we had a system that needed to process large amounts of data in real time, then (a few of) the success criteria are:
- We can process 2000 messages a second
- We can do this within the budget constraints
- We can catch up should we fall behind in our processing
And our hypothesis is:
"We will be able to meet the success criteria using Azure Functions and .NET"
We then need to collect evidence to prove/disprove our hypothesis.
Proof of Concept
This is quite an overloaded term. But it essentially means to collect evidence to prove/disprove a design. In this stage we build out the minimum useful version of the system which we can use to validate our thinking. This process looks very different depending on what hypothesis you are trying to prove.
The important thing to remember at this point is that you should carry this out with no assumption about whether or not the hypothesis is true. A proof of concept is useful and important irrespective of the outcome. Proving that an approach will not meet the criteria is just as useful as proving that it will.
But with this in mind it's important to quickly prove/disprove an approach. A fast feedback loop between hypothesis, experiment, conclusion is extremely important. This way you can quickly establish the approaches which aren't going to work and continue with a more in depth assessment and subsequently usage of the proved out solution.
Conclusion and write-up
Once a hypothesis has been proved/disproved you can draw your conclusions.
Whether or not the conclusion is that an approach will work, it is important to write these up and fully document any decisions made. This not only forces you to think through and fully consider these decisions, but also is important so that people will later be able to understand the design.
Using this process we can quickly evaluate suggested approaches and minimise the time wasted on exploring dead ends.
The most important take-away is that scientific experimental process is equally applicable to software development and leaves you with not only an design which you are confident in, but also with fully documented reasoning behing every decision made.
