Software-as-a-service (SaaS) has offered the software development community new ways to create quality products—but have we missed a potential disaster in the euphoria of iterative and agile development methods? Could we have inadvertently forced ourselves into a dangerous corner by ignoring the ramifications of permanent beta culture?
Getting SaaS-y
Let’s get something out of the way right off the bat: SaaS is big. Really big. A study from BetterCloud back in 2017 found that the average company is using up to 16 SaaS apps, and that the vast majority (>90 per cent) said nearly all their apps would be SaaS by 2020.
Everybody is on the SaaS train:
- IT professionals love online apps because they’re more secure, have great integration and, in many cases, have awesome customer support.
- Employees love them because they’re often intuitive to use and can be accessed anywhere—great for those of us who have to travel and still need access to our files.
- Businesses love them because frankly, they’re more cost-effective and improve productivity. That same BetterCloud survey found that SaaS-heavy workplaces even end up having fewer emails and fewer meetings because of their apps.
There’s a lot to like, and the SaaS revolution has a lot of benefits for the business world in general.
But…
The problems with the permanent beta
It hasn’t all been sunshine and roses for SaaS; there have been challenges along the way, especially for those closest to the software: IT professionals.
A lot of these issues will be familiar to those reading: managing users, dealing with external access, delegating admin privileges—issues that have plagued the IT profession since the dawn of time; or at least the dawn of the computer age.
The average company is using up to 16 SaaS apps, and that the vast majority (>90 per cent) said nearly all their apps would be SaaS by 2020.
But one problem is unique to SaaS and far more insidious. In fact, this issue is lauded as a feature: the iterative process of development, the constant improvements and feature upgrades, or, as it becomes in some cases, the status of permanent beta.
“What’s the issue?” you might ask. “The iterative process is just a given in the SaaS framework—it’s how we get our software out faster to the end users, and they get newer, better features more quickly. They even get to influence the direction of the software with their feedback!”
You’re absolutely correct: there are a lot of benefits to SaaS. But the constant, rolling-on nature of the permanent beta creates issues as well.
Some of them are technical, like problems around building upon increasingly rigid successive steps. Others are cultural, such as the ever-constant issue of building technical debt and the even more dangerous chance of creating a culture of shoddy work with the “it’s just a beta” excuse at its heart. This last one is especially dangerous, as it fundamentally damages your ability to create good software.
And all of that is without mentioning the potential for the poor customer experience that results from previous features being rendered unusable or unintuitive by experimental changes.
There are a lot of benefits to SaaS. But the constant, rolling-on nature of the permanent beta creates issues as well.
Take, for example, HubSpot. Perceptive uses HubSpot for our CRM, marketing automation, website design, the works—we like it a lot, is what I’m saying, and we have put a lot of trust in their team. However, it still falls into a lot of the permanent beta traps: there are new features filtered in and out without much warning, established tools moving to completely different parts of the workspace, some of them being phased out entirely. It’s exhausting sometimes.
A lot of HubSpot’s changes end up creating fantastic tools that our strategists and salespeople find incredibly useful—but considering some of the groans and moans I hear from across the office (usually involving some variation of “where is the…?”), getting to that point is like pulling teeth.
This is the danger that every SaaS dev and every team lead has to navigate: a rolling stone may gather no moss, but it can still crush everything in its path if it gets out of control. Relying too much on the permanent beta culture of SaaS can damage your software, your team and, ultimately, your performance as a developer.
Considering the part as the whole
At Perceptive, we’ve adopted development methods that let us capitalise on iterative development while still maintaining quality control. Recently, we’ve focused on testing and increased user feedback, but the most important thing for us has been the move to “security first” development.
This mindset forces us to think through the entire context of the application as part of any changes—a broken part of the code could result in serious security breaches and/or the shutdown of the entire application.
From the outside, this can look like our work moves slower but the benefit (aside from the obvious increases in security) are that we consider the entire system—not just the single element at hand.
We’ve adopted development methods that let us capitalise on iterative development while still maintaining quality control.
As a result, we don’t allow ourselves to excuse a potential problem through a permanent beta. We don’t have the luxury of beta-testing our security, after all. It has to be as near-perfect as we can get it as soon as we roll it out, and because the security consideration is holistic, that same perspective applies to every application update we make as a whole.
It has been extremely effective at creating a culture of quality, not of beta-testing, and I would highly recommend doing something similar to any other development team lead in the SaaS space: find a way to ensure your team considers any single part as a whole and you’ll avoid the pitfalls of permanent beta while still retaining the benefits.
In short, don’t allow the iterative to dictate your culture or your conduct as a coder. Development and the SaaS industry is more competitive now than ever, and failing your users by failing to combat permanent beta culture is, simply put, going to leave your software in the dust. Consider every part just as important as you consider the whole, and, as we say in New Zealand, “she’ll be right”.
