Presented by Raygun
I’d assume, like me, you grew up in a very different world than we live in today when it comes to technology. Today software touches our lives constantly from the moment we wake up, go to work, and then hit the hay and the end of the day.
But as software eats the world, it also eats into the time of software development teams. They need to fix any problems in their codebase that inevitably crop up, regardless of how much testing they put in before releasing into production.
That comes with a cost. The Systems Sciences Institute at IBM has reported that “the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.”
in the earlier days of windows and home computing, when things went wrong and didn’t work as expected, we’d be prompted with the question:
“Do you want to send this error report to the developer?”
This clunky and somewhat backwards way of gaining feedback from users is still present in some software applications today.
Why do companies make their users do all the work?
Users are well aware they are sending such reports down a black hole, never knowing if anyone received it, looked at the information and applied a fix. Only 1 percent of users will actively report the issues they encounter, so developers who put the onus on the users to report bugs are likely unaware of the large majority of issues their users are facing.
You can’t fix what you can’t see.
Teams want to deploy code more quickly
Teams with traditional set-up who rely on users to report issues before any action is taken can spend hundreds of hours a week in lost development time — much of it just looking for root causes of bugs and performance issues.
This cost is not only financial though. The opportunity cost of not shipping code quickly and efficiently means features take longer to ship, customers don’t see any rapid innovations, and managers get impatient.
According to a recent survey, more teams are deploying faster, with 14 percent reporting they deploy hourly, up from only 10 percent last year. At the other end of the spectrum, few teams are deploying weekly (21 percent, down from 23 percent last year) or even less frequently (31 percent, down from 33 percent last year).
However, this isn’t the end of the story. On the flip side, we also see an increase in the desires of development teams to deploy even more quickly.
When asked a similar question about their ideal deployment times, 28 percent reported that they would like to deploy hourly, a sizable increase over the 18 percent that reported the same in the past year.
Boosting the ROI of software development teams
The days of the developer saying “I can’t replicate it” are quickly coming to an end now that they have dedicated software intelligence tools available.
Dedicated error and crash reporting software can pull in full stacktraces, environment information, and even automatically identify which specific users experienced the problem, making error replication and debugging far quicker than traditional methods of digging through log files.
Companies slow to adopt such innovations stand to lose considerably when users run into issues that development teams aren’t aware of. And shipping of new features and updates is hampered by time-intensive exploration into what happened and why.
Source: Raygun ROI Calculator
A developer could spend half their time fixing problems with code that’s already written. This is the maintenance aspect of any software development lifecycle and fixing problems in colleagues code can only lead to increased detection and resolution time.
So what’s next?
The way we build, maintain, and deploy software is much different in today’s environment from the one of ten years ago. So what will the next stage of software development look like?
Continuous deployment and integration is being adopted by more and more teams and is necessary for developers to deploy features, alterations, and bug fixes at a fast pace. Tools now exist to give developers real-time feedback on how their code is being received by end users in production. With insights into why users are having poor user experiences delivered to the team directly there is little need for users to be the ones finding and reporting problems themselves.
Software development teams who don’t adopt modern-day release cycles and real-time diagnostics on production code stand to lose significantly when their faster-paced competitors overtake them.
Sponsored posts are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. Content produced by our editorial team is never influenced by advertisers or sponsors in any way. For more information, contact sales@venturebeat.com.
