Speed of our software applications is rarely considered until it becomes a problem. In this episode I talk about why speed it important in all of our software application - not just the consumer facing ones.
Or listen at:
Published: Wed, 30 Jun 2021 15:53:19 GMT
Transcript
Hello and welcome back to The Better ROI from Software Development podcast.
In this and the upcoming episodes, I want to talk about speed. I want to talk about the speed of our software and why it's important.
In this episode, I introduce the why. Why we need to think about it, why we need to look at it. And in subsequent episodes, I'll be looking at potential ways of improving that. Potential techniques, potential changes, that can be used to make software faster.
Let's start with why is the speed of our software important?
All of our users now are consumers, whether that be internal users, whether they be users of a website, whether it be users of our mobile applications, whether it be partner companies that we work with using our software - all of them are consumers in their own right.
I'm a consumer, you're a consumer, everybody today is a consumer of high class software applications. We're all using software in our daily activities, whether it be for work or for home or both - and we expect things to operate and behave well.
If you open up your email application on your mobile phone or you try to watch Netflix or you try to order something on Amazon, you're expecting a certain level of service, both in terms of how well it works and its availability, but also how quickly it operates, how quickly you get to use it, how quickly it finds the things that you want to do, how quick it is to actually navigate - to get the job done that you want to do.
And everybody is getting that same experience of wanting to get things faster. Its that consumerisation of software.
Now, you might be thinking, but we're only developing software for our own internal staff to use. We are only may be developing software for our business partners to use. It's not really a consumer product.
And you could be forgiven for thinking that, but it's the same people that, when they're not working for you, are consumers of software elsewhere. Thus they will come to it with a level of expectation. They will expect a level of speed and responsiveness that they get from applications that you use every day.
And it's not just about the experience of those users.
Yes, if it's slow, it's going to feel frustrating. You only need to think about when the last time you used a piece of software that was slow. How frustrated were you? And this is happening to everybody, whether it be our customer, our users or our partners, if our software is like.
But if it's our actual users, we also need to think about their productivity. If we've built them a slow experience, we can't just turn around and say what we're paying them the money, it's up to them to just get on with it.
We also need to think about our own productivity within our own organisations.
If you've got a team working with a piece of software that is so slow, it is impeding their ability to do their daily work; What's the productivity level of that team?
Is that team holding you back because they haven't got the necessary tools to be able to be as productive as they could be?
And of course, you do have the danger of your customers and your staff voting with their feet if they reach a level of frustration with the service you provide for your software.
If your customer facing website is too slow to load, are customer is going to wait for it?
If the search on the website is too slow to return a response. are the customers going to keep using it?
If your users, your staff, have to wait five minutes for a response from the system, are they going to get frustrated? Are they going to lose productivity because they're struggling to actually get the job done? And that can hurt you both ways, both from the productivity point of view and ultimately your staff actually moving on because it's not a fulfilling role.
There have been countless studies on speed.
Amazon apparently have said that for every 100 milliseconds of latency, it cost them one percent of sales. Let me repeat that, 100 milliseconds slower - in being able to get the website to load or to provide them details is costing them one percent of sales. That's quite a startling figure.
Google found that an extra half a second in search page generation will drop their traffic by 20 percent. I can only assume that 20 percent have got bored - they aren't prepared to wait that extra period of time, they've gone off to do something else.
And this is the level of consumerism that we need to think about. People are expecting these level of responses, this level of interactivity that even perceivably small drops can have a material impact on the bottom line.
And even business to business communication can suffer, a broker reported losing four million dollars in revenue per millisecond if their electronic trading platform was five milliseconds behind the competition. Now, trading platforms will always be the extreme case, but it's not going to be the only place where business to business transactions, where speed is important.
For customer facing websites, the speed of your website also has an impact on search engine optimisation. Google have made clear that the speed of your website will have an impact on where you appear in your search engine optimisation rankings. For Google, their users will want to find their answers quickly and shows data that they really care about, thus speed is a factor. They will look at how quickly your page loads, how quickly your page is usable, how quickly a customer can actually use it to get the job done.
OK, so I've talked about the impact of speed and why speed is important. In future episodes, I'll talk about potential improvements. Some of those improvements may be business decisions that you need to be aware of and you need to make an active choice, some of those improvements may be cost related where you may need to spend and your team may be coming to you asking for that investment. We'll go through them as we go episode by episode.
Regardless of the improvement, however, there will always be a dark side. There's a dark side to over optimisation. There is the danger of simply spending too much time and resources on speed and not actually getting any perceivable benefit for it. And this is largely a technology problem where developers or technical people will want to put more and more effort to make it faster and faster and faster.
But there is a balancing act here. You have to look at the effort versus the reward.
Basically, are you getting the return on investment you expect. The faster you get, the more you have to invest to move the needle just a little bit further. It becomes exponential the more refined that you get, the more effort you have to get into to eke those small changes out.
Which is why any of the improvements I talk about in the upcoming episode, you need to remember to look at them through that experimental mindset lens. That same mindset I've talked about over and over and over again. Where you start with a hypothesis, you make a change, you monitor it, then you review and you repeat. You make small, incremental changes so that what you're not doing is over optimising.
But in the same respect, you can see that you're gaining benefit from the investment you're making.
Again, we always should be working in very quick, short increments in anything we do have in software. Every single change we make, every single piece of work we do, we should be thinking, what is it we're trying to achieve? What's our hypothesis? What do we believe this piece of work will do? We then need to make the change. We then need to monitor it to see where it has actually made the change we've expected. And then we need to decide what we do next.
Maybe our monitoring has proved, actually no that didn't work, that actually has had a negative effect - let's try something different.
Or maybe its had a positive effect, maybe there's further we could go with that.
Again, without that rapid feedback cycle of looking at what you've done and whether or not it's had the desired effect, there's a real danger here that you could go off and over optimise. You could invest poorly by putting lots of money in optimisation that's just even not moving the needle or there's no further need to move that needle.
In this episode, I've given you a brief introduction to why speed is important in our software, in all our software, not just consumer facing software, but within our staff's software, within our partners software.
And I've talked about why it's important for things like search engine optimisation.
In future episodes, I'll be talking about possible improvements that you can look at, things that the team may be bringing to. And we've all changes are tied that back again to that experimental mindset, making sure that we're doing what is right for us and that we are achieving good ROI for our business, creating great outcomes from software.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.