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.

decision-making
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.

 

Research1. OBSERVATION | RESEARCH

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.

 

2.  HYPOTHESIS | DESIGNHypothesis

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.

 

Experiment3. EXPERIMENT | BUILD & TEST

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.

 

Analysis4. ANALYSIS | MEASURE SUCCESS

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.

 

Conclusion5. CONCLUSION | ITERATE

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

 

Adapting to Change

Working in tech has many challenges, one of those is the rate of change and how we respond and adapt to those changes. New languages and tools are constantly introduced and for some this can be a fearful time. I once heard that we don’t fear change as much as we fear loss and I personally believe that to be true. The phrase ‘people don’t like change’ is a misnomer for me as it doesn’t fit with my view of the world or reflect the progress (rate of change) we’ve seen in the past 150 years. Some change is born out of necessity however some is out of curiosity, frustration, pleasure or by accident.

Lately my world has been a veritable epic centre of change and this has forced me to apply introspection and really think about what is happening both externally and internally. This thinking also follows on from my last post about expectations and how these too can have an impact on how we perceive the world around us.

Compromised Values

We all have a set of internal guides that help us to make decisions and sense of the world. These are often referred to as a values, the emotive elements of life that we place a varying degree of importance on. For example, Integrity is one of my highest rated values whereas safety is something I value much less. This can be seen in my frustration with people I would consider unreliable and my ease at which I can pack up and move to another country without first securing a job. These are some of the things that make me, me. Everyone has their own set of values and their own ranking of these. If I propose the idea of packing up and moving overseas without a job and somewhere to live to someone that does value safety highly, I’m likely to meet quite a lot of resistance to this idea and probably a lot of questions.

When our values feel compromised in any way it’s likely that we will start to feel anxious, uncertain, frustrated and other things that make us feel a little uncomfortable with what’s happening around us. By knowing what our values are and taking the time to identify how something is making us feel, whether our values are being compromised or fulfilled, we can start to understand our own behaviours. This can help us to rationalise change and is a technique I find particularly useful when I feel as though the change is out of my control.

Fear of Loss

Loss can be an incredibly powerful emotion and I know that times in which I’ve been most troubled has been when I’ve lost someone or something that I had a strong connection to. When we’re first confronted with losing something it can be a difficult time. A role change can stir up many varied emotions, such as being excited about new responsibilities or opportunities but it can also be a difficult time as we come to terms with perhaps losing team relationships that we had built up over time. With almost every state transition we take as people we are usually gaining something but in the process, also removing or losing something.

In times of change where a feeling of loss has been involved I have found it helpful to focus on what I have gained. Being able to come to a place of accepting that things won’t be the same as they were can be difficult and it’s important that we are honest about ourselves as been accepting of a loss or not accepting. Some losses can feel bigger than others so I also like to use a scale system to put things in perspective.

  1. On a scale of 1 to 10, how much of an impact is this loss going to be on my life?
  2. What would be a 10?
  3. What other options do I have still have in my life?
  4. Is it still ‘X’ on the scale?

This exercise helps me to think of events more critically and I usually end up downgrading the impact of the loss by the end of this.

Unmet Expectations

Most of us have an expectation about what is going to happen to us in the next day, the next week or for those of us who really love to think ahead, perhaps longer than that. If we’re the type of person who likes to think about the future and what that might bring given our current set of circumstances, when one of those circumstances change, this can throw things in to disarray. There is thinking that if you change your expectation, you change your perception.  When people don’t met our expectations, even when we haven’t communicated what those expectations are, it’s easy to feel disappointed or frustrated that someone else hasn’t done what you think they should. Talking with people who have leadership positions about people who report to them, one of the common complaints is ‘Why did they / didn’t they do what I thought they would?’

The answer to this question lies in the conversation about what is or isn’t expected, not what you perceive the expectation to be. My perception is that most people want to be kind to other people and want to do well. Once a conversation takes place about what both parties expected, the source of frustration is usually clear. Having a growth mind set also helps with this as it allows us to be more open to other possibilities. This isn’t a case of ‘lowering expectations’ rather than ‘understanding expectations’ so that an outcome which is shared by both parties can be reached. Having the courage to talk about what we expect with others is a skill which I am continuing to place more importance on. It can be a good tool in diffusing a frustrating or difficult situation.

Underlying a lot of this is ‘the unknown’ which, if not understood can sometimes cause paralysis of change. These are some of the types of change I commonly experience and how I try to adapt to the undulation of emotions that come with these events. The more practice I do with these tools, the quicker I am able to get back to a place of comfort where I feel empowered to act.

Are there any tools you use for adapting to change to either these types or another type of change?

The Evolution of UAT

User Acceptance Testing. It’s a phase of testing that’s bothered me for a while. Not because I think it’s a waste of time, in fact, quite the opposite. It’s bothered me because I think it hasn’t been given the care, attention and expertise it deserves.

The intent of UAT has always been a noble one. We wanted our users to accept our product and accept what we had built. The way we went about proving that acceptance though was deeply flawed. The process looked a little like this:

Step 1: Find some users or, if users aren’t available, you can do it yourself

Step 2: Write a script for the user which outlines exactly how they should test the system step by step in predefined workflows

Step 3: Get the user to complete each step putting a ‘Pass’ mark next to each one

Step 4: Write any questions or confusion from the users down as ‘training issues’ (If you’re testing it yourself, you probably won’t have any questions because you’ve already tested it in the system and integration test phases and you know it works. Besides, you’re not the one who has to use it on a daily basis anyway)

The problem with this approach is that it seeks to validate the product even if it invalidates the experience of the person using it. At this point it’s not really about your user accepting your product, it’s about your product functionally working when put in front of an end user.

How do we solve this problem?

Firstly we need to understand our users. We need to understand their needs, their activities and the context in which they are performing those activities. By doing this we change the meaning of UAT into a list of things our users will accept, things that will delight our customers once we’re done. Once the feature goes live, User Confirmation Testing can commence. Confirmation testing allows us to measure the degree to which we were successful against our initial assumptions, hypotheses and insights. Both qualitative measures such as customer feedback and quantitative measures through the use of data analytics can help us to identify what our users have accepted and what they have rejected. This gives us the opportunity to research, build, monitor, iterate and improve.  

UAT done in accordance with this new meaning is hard. It involves a lot of effort, time, understanding and empathy. Not all of the “defects” we find during the first UAT phase will be ironed out so confirmation testing shows us where we’ve been successful and where we need to iterate and improve. This pushes testing to the start of the development lifecycle and helps to prevent usability flaws in our finished product. Perhaps, most importantly, it provides the opportunity to test before the code is written, as the code is being written and after the code has been deployed adding value at each of these stages.

At a time where people have so much choice and greater expectations that software should be engaging and intuitive, understanding who we are building software for can help us to meet those expectations. It is no longer good enough to be happy with “work arounds” or “at least they can still <insert anything unrelated to the thing they can’t, but really want to do>” attitudes towards software development. Focusing on what our customers value and delivering the things that will really make a difference give us a head start on any competitors in our market.

Every time a new idea for a feature comes into a team we can all strive to understand who we are building it for and what problems this change will solve. If we can’t answer these two questions, it’s time to put the deerstalker on and seek out the answers!