Science and Software

Lately I’ve been thinking more about the approaches and methodologies we use to develop software. With the introduction of terms such as TDD (Test Driven Development), ATDD (Acceptance Test Driven Development), BDD (Behaviour Driven Development), Specification by Example, User Stories, User Journeys, etc, etc, it’s easy to see why teams may be struggling with understanding and using these approaches. The introduction of these terms can sometimes see people getting hung up on definitions and forgetting that these approaches all have one thing in common. The intent is to build a common understanding between team members and stakeholders of different disciplines and knowledge or skill levels. All of the above approaches have a purpose and if understood and implemented well can be of real benefit to a team.

Overarching these approaches, we also have the two software methodology juggernauts of Agile and Waterfall. Agile is often seen as the new kid on the block and Waterfall as an outdated relic of the past but these views can also just be a common perception. Agile has, as people will tell you, ‘been around since the 70’s’ (depending on who you talk to) and Waterfall is still an approach being used today with success. I’ve worked on software under both of these methodologies along with hybrids of ‘Watergile’, ‘Water-scrum-fall’ and other such terms. I’ve seen a good percentage of time that should be spent developing software spent on clarifying definitions of terminology. At times, this can feel a little bit dogmatic. Jared Spool studied the habits of highly effective teams and noted that those who were more effective favoured tricks and techniques over methodology and dogma. In his transcript of ‘Anatomy of a design decision‘ he uses the analogy of a recipe as an artefact of a process not something that is exclusively needed or required to cook.

Anatomy of a design decision – Jared Spool


Thinking about the things I’ve experienced and researched, I kept coming back to a process (or method) I learnt in school and one that has been around for hundreds of years, the scientific method. Regardless of the approaches, tools, techniques, tips or mindsets used in software development, the scientific method can be applied to the software development life cycle (SDLC) as an aid to understand the purpose of each stage. I’m not using explicit definitions of known SDLC models, more phases I’ve seen teams go through (or strive to go through) during product and feature delivery. I aim to be methodology agnostic.



Before starting any project we need to know ‘What problem are we trying to solve’ and ‘Who are we solving it for’. Once we know the answers to these questions, we are then able to observe and collect information about the problem or our intended users. Our research can include things such as data analysis, market or competitor research, customer feedback or user interviews. At this stage it’s important to make sure we have both quantitative and qualitative data as well as using multiple sources to help negate the impact of bias and assumption. If we collect information from multiple sources we can make better hypotheses. At this stage we may also observe that our initial thoughts about the problem or user needs to be modified for greater impact or success.



If we have a balanced mix of research, observation and information, it puts us in a really good place to make a hypothesis about what we’re building and how to build it. This can be thought of as design. Making a hypothesis about software is thinking about ‘If I change X, then I expect Y to happen’. X is the visible change, and Y is the consequence of that change. For example, ‘If I change this link to a button, then I expect more users to interact with it’. From this point, I then have something to measure in order to know how successful that change has been. Design could be thought of as the visual representation of my hypothesis whether that be UI, code, architecture or infrastructure.



During the experimentation phase, we start to build and test the change we are intending to make. Testing also allows us to modify our build as we discover more information about the change that we didn’t know before. We may also choose to build more than one experiment if we are wanting to measure the success of an A/B test.  This phase is not to be underestimated in terms of the amount of information it can provide us and should also be considered dynamic, rather than static. The more rigorous and defined our observation (research) and hypothesis (design), the clearer the purpose of the experiment (building and testing) should be.



After the development or product team has done all their hard work, it’s then time for the push to production. It’s at this point, most teams stop and move onto the next thing with the only measure of success being that the code has made it into a production environment and is alive. But what about our hypothesis? We now need to see if what we thought would happen, happened or if we need to make further changes. Measuring the success of a change is critical to knowing what to do next and also provides us with more information about what went well and where we went wrong. This analysis of what happens when we put our software in front of either part of or our entire user base can not only provide us information about what to do in the immediate future but can also gives us insight into what to focus on longer term.



By this stage we have a lot of information and because of our initial observation, hypothesis, experimentation and analysis, the conclusion about what to do next should be relatively clear. Do we need to perform any modifications or are further experiments required? Were we successful enough to leave this area of focus for now and move onto another one?  Like any good life cycle, once we have reached our conclusion it’s time to start on the next iteration armed with more information and insights than we had before.

By treating software development in a more scientific way I find it easier to understand both what needs to be done and why.

Science Based SDLC
The scientific method in software development – Stephanie Wilson


Interesting User Stories

I recently held a coaching session with one of my colleagues around the topic of User Stories. There are a lot of articles and books written on the subject, each with the basic structure of:

As a…

I want…


User stories are something that I’ve seen myself and others struggle with. In the past I’ve often put ‘get better at writing user stories’ on my personal development board as I’ve always felt they could be better. I’ve also read a lot on the subject in an attempt to get better but for one reason or another it hasn’t stuck with me.

During this coaching session, I asked for an example of a user story that we could potentially improve on. The story followed a familiar format:

As a user

I want a search field

So I can find a report

At this point I realised we didn’t have enough context or information to jump straight into improving this story. We had to take a step back and look at what we were trying to achieve with the story first. I’ve recently been thinking a lot about the ‘why’. Why we do things, why we believe, why we change and many more.

I often like to take the ideas of software and apply it to something more tangible. For this session we came up with the idea of ‘Clothes’. This became the context or domain in which our character (person, user) was set. This became our product.

Our next step was to identify the ‘Why’. Why might this character need our product? For example:

  • To not be naked
  • To keep warm
  • To be fashionable
  • To feel good

Once we had this information, we then thought about the type of person our character might be. Who are they? What is their context? We then began experimenting with how we might structure a user story using this information:

As a person who wants to leave the house

I want something to cover my body

So I won’t be naked in public


As a person who lives in a cold climate

I want something that will prevent me from becoming too cold

So I can keep warm

These were ok, but we could do better. By changing the person’s context and their why, our stories could become more specific..

As a person who is travelling to Antarctica

I want protection from the cold

So that I can survive -20 degree Celsius temperatures

None of these stories gave a solution. The ‘How’ could come later. By structuring our stories in this way, we allowed room for multiple solutions to a problem rather than narrowing our thoughts into one area. If we take the last user story above and provide a solution, all of a sudden our options for how is significantly narrowed:

As a person who is travelling to Antarctica

I want a survival coat

So that I can survive – 20 degree Celsius temperatures

This seemingly innocent structure is limiting our ability to innovate.

Going back to our original story, we thought about how we could make it better by following a new structure

(Who) As a <character> who…

(What) I want <need>

(Why) So <my need can be satisfied>

Our original story rewritten looked like:

As an accountant who wants to file my client’s GST report at the end of the financial year

I want to find clients who have outstanding GST reports

So I don’t miss the deadline for GST returns and I avoid any penalties

This poses the question, if user stories are supposed to tell a story, do you want to tell a boring story with ambiguity or an interesting story with meaning?