What does ‘always-on’ mean for software development?
Guest author James Wilson is Customer Success Director at Diffblue with over 15 years of experience in testing, QA, and product development in organizations ranging from startups to global companies.
5 MINUTE READ
Access to work has never been easier. Wind back the clock a decade or so and the big companies of their time tried (subtly) to keep their employees on their campus as much as possible to get the most work out of them. Adding gyms, nice restaurants, hairdressers, etc. to the campus meant employees barely had to go home.
Then the Blackberry came along to change everything. Give your employee one and they could access their email or be available for calls whenever you want. In the present day, this has gone even further. I have my work email, slack, and zoom all installed on my personal phone.
My colleagues can contact me pretty much whenever they want (thank you, Apple, for ‘Do Not Disturb’ mode). You might be fooled into thinking this is another blog post about the effect of always-on work culture for employees. But you’d be wrong. I’m going to talk about the impact of always-on for IT teams and technology companies.
The evolution of always-on
When considering how the always-on culture has evolved, the simple act of doing expenses serves as a revealing case study. When I started my career I had to fill in a Microsoft Excel file, print it out, get it signed, and hand it to the finance team (with receipts attached). About six years ago, I worked at a company that had an internal online system: fill in the details, scan the receipts, and all the approvals are done online. Now with systems like Expensify, I can submit the expense for coffee quicker than the barista can make it.
Why does this matter to Developers?
So what does this mean for the developers who produce the systems that support our always-on culture? Well, for a start, it means no more large downtimes at weekends to allow for system rollouts. But it has also ushered in the ever-present expectation to respond to incidents when they occur, whatever the time of day. In fact, as I sit and write this blog post, my wife is shouting from the study that she can’t check in for a flight because the website down. As if I’m going to be able to go and fix it!
How has Development changed to cope?
Of course, many companies have reacted to this. For example, SaaS solutions within corporate environments help remove the burden on IT teams and provide more availability. Agile development practices have replaced more traditional approaches to ensure releases have a shorter turnaround. New features now tend to be delivered every two to four weeks rather than annually.
There’s also been an increase in technologies to support Continuous Integration and Continuous Delivery (CI/CD). Just think about the number of CI companies (e.g. TravisCI and CircleCI) that are available these days. These tools allow teams to know the quality of their build and code base for every merge.
Finally, cloud technologies allow smaller businesses to leverage the experience and capabilities of much larger companies. SMEs can now guarantee the uptime of the platforms their systems run on, at a fraction of the cost of hosting your own data centers.
Is this enough?
The changes listed above have had a significant impact. But the pressure for systems to be available 24/7 is only continuing to increase. Last year O2 suffered a major data outage which caused problems for people right across the UK. Take a moment to consider the number of taxi drivers (think Uber) and delivery drivers (think Deliveroo) that couldn’t work because the are completely reliant on their phone’s data connection to do their jobs.
Having mentioned Uber and Deliveroo, we also need to consider the novel threat to established companies. Even if you have implemented all the latest best practices, there is still always the possibility for a disruptor to come along and steal your share of the market.
What’s the next big change?
In a relentless environment of new products and features coming onto the market, how can you keep up? Well, development teams simply need to either work harder or work smarter. Working harder is not sustainable in the long run; it leads to burnout, high turnover, and knowledge loss in the team.
Therefore, there really is only one answer. So how do we work smarter? All of the changes to date have been about providing quicker feedback to developers and beginning testing much earlier in the process. But we are now beginning to see a new trend emerge – using AI and machine learning to do some of the work that developers would traditionally do.
For example, at Diffblue we’re using AI for Code to automate tasks developers don’t want to do. As a result, this leads to more productive development teams. If you’d like to see it in action, take a look at Diffblue’s Playground and see how AI for Code can write unit tests for you with no input other than your Java code.