By incorporating Split Software’s capabilities into its platform, Harness will be able to offer a software release platform where developers can not only release software, but run A/B tests and measure adoption of specific features. 

With the acquisition, Harness said it will deliver a feature management solution that combines core feature flagging capabilities, experimentation, feature flag workflows, governance, and the ability to
manage/archive stale feature flags. All of these capabilities will be integrated into the Harness
Software Delivery platform to help customers build, deploy, and release software while running
A/B tests to experiment and measure feature adoption, the company told SD Times.

Yet for all the advantages of feature experimentation, it has remained under-discussed and under-utilized widely in the software industry. “It’s an overlooked competitive advantage among companies looking to experiment often and iterate quickly,” said Jyoti Bansal, co-founder and CEO of Harness. “Based on how fast digital-native players are innovating, I believe feature experimentation will soon be table stakes in the standard developer lifecycle as customers become more vocal about having their feedback and needs quickly incorporated.”

Bansal noted one thing that has held this technology back from being so widespread is that it has historically only been available in point solutions that are not integrated deeply into the developer tool
stack. “This is what makes our acquisition and integration with Split so unique—we’re unlocking a seamless, end-to-end experience for developers to work solely from a single platform,” Bansal said.

Bansal called Split “the obvious choice for us as an established feature management platform… The market demand for a solution that’s integrated directly into the Software Development Lifecycle is massive. The timing couldn’t be better for our two companies to come together to deliver tremendous value for our customers.”

Brian Bell, CEO of Split, added: “The moment of feature release is a critical touchpoint between the developer and user. Our mission at Split has been to give development teams the confidence to accelerate with control and the freedom to innovate with ease. To further this mission, I couldn’t think of a better partner than Harness. Harness is automating and integrating every stage of software development. Together, we will have the most comprehensive software delivery platform on the market.”

Harness indicated that Split will be rolled into the Harness brand once it is fully integrated into the company’s platform. Financial terms of the transaction were not disclosed.

— With David Rubinstein

The post Harness announces plans to acquire feature management company Split Software appeared first on SD Times.

Progressive delivery uses experimentation techniques such as feature flags, blue-green rollouts and canary releases to show new features or bug fixes to a small cohort of users, and takes feedback from those experiments to make a decision to go big with it or roll it back to its original state for more work. These experiments enable organizations to decouple deployment from release.

In a recent conversation I had with Dave Karow, evangelist at feature flag platform provider Split Software, he discussed something he called layered progressive delivery.

This approach, he explained, begins with finding consensus with developers and SREs. “There’s nobody that’s not going to want better cycle time, shorter cycles. There’s nobody that’s not going to want automating the ability to detect when things go awry that you didn’t expect,” he said. “There’s probably — hopefully — not too many people that aren’t going to want to know whether the thing they just did had an effect.” 

He went on to say that this new approach to progressive delivery builds layer upon layer of richness to get more out of the experiments, and strongly debunked the notion that experimentation is both hardcode rigorous and that it requires building two versions of the code.

Savvy experimenters, Karow said, do dynamic config, which he explained allows development teams to send data along with a flag that sets different parameters for different users. He said the parameters of a recommendation engine, for example, “could dictate, do I want to give David a lot of answers, or just a handful of answers? And if you’re deciding whether you’re going to expose people to this new thing, you could also create two or three cohorts that each have different parameters. Now you’ve got people on your legacy engine, and you’re got two or three cohorts in the new one, and you’re trying different things — like lots of answers, not very many answers, ranked by popularity versus ranked by relevance.” The key point he made is that you can change the value in the flags and what those parameters are without having to create new versions of the code. 

“So now David is in cohort three that gets this, but we’ve just changed that he’s going to see results ranked by popularity instead of ranked by relevance in the engine. And we’re going to run that for a week and see what happens. That’s not three copies of code.”

When Karow talks about a layered approach, it simply describes a way to implement progressive delivery in progressively more value-rich ways, starting with the one that’s least threatening and not a point of debate with a developer.

A hidden benefit of using a feature flag platform to deliver the variations is that it also is capturing telemetry from each of those cohorts separately and processing the data separately, to quickly compare how each cohort behaves.

Karow gave an example from LinkedIn, which he said has been doing experimentation for a long time. They had an experiment on which version of an application would cause people to do more job listings. The developers didn’t monitor the application for speed, but got an alert from the platform that said the changes made the application slower. Automating guardrails, such as always monitoring for speed, can provide insights you might not have expected.  “When the thing that’s rolling it out also is the thing that’s keeping track of how it’s going, it becomes really easy to know what’s happening,” he said.

The next layer is measuring release impact. “If you achieve shorter lead times, and you’re shipping a lot, you might be like a hamster on a wheel, like you’re in a feature factory, and it sucks,” Karow said. “It’s demotivating. But if you have direct evidence of your efforts, it leads to pride of ownership.”

The top layer is test to learn, an area Karow said can help organizations take bigger risks but in a safe way. He gave the example of a food delivery service that wanted to ask customers questions about their eating and shopping habits to fine-tune their service, but didn’t want to ask too many questions for fear of turning off their users. So, he said, they did a status quo, a modest release, and a “go for it” release — which also increased onboarding time by two or three minutes. And right away, he said, they saw more money from every customer.

So instead of the usual pre-release hand-wringing — Do it. Don’t do it. We’ll lose everything. We’ll miss our quarter. — they tried these changes out in a safe way that gave them hard data from real customers.

The post Layered progressive delivery appeared first on SD Times.

RedMonk founder James Governor, who coined the term progressive delivery in 2018 to describe a basket of related skills and technologies for gradual releases that reduce risk in application delivery, announced his 2020 research topics recently and at the top of his list was progressive delivery. 

It’s great to experiment to ensure your software works as intended, yet progressive delivery is motivated by business factors — if the company releases software and business metrics go down, it’s better to know that before a wider release. “I want to watch it to limit the blast radius, so as I’m ramping it up, I want to be able to know whether it’s going well or not,” explained Dave Karow, Continuous Delivery evangelist at feature delivery platform provider Split Software. “I want to learn before I get to 100%. You know, one of our senior engineering leaders used to be at a very large file-sharing provider and he admitted that even when they used gradual rollouts, they didn’t tend to learn about [issues] until they were past the 50% mark. That’s painful compared to finding problems earlier in a gradual rollout. You want to set yourself up to learn about unforeseen issues as quickly as possible in production, and it would be nice if you didn’t have to hurt most of your users — if not all of them — before you figured out you had an incident.”

These patterns have been used by the largest e-commerce leaders for years. At Walmart, they use Progressive Delivery for two main purposes: one is called “test to learn,” and the other is “test to launch.” Test to learn is essentially A/B testing; which version of the software yields more of the desired user behaviors, such as buying more items or signing up for premium services. Test to launch, on the other hand, is more like application monitoring, where you’re watching a gradual rollout of the application to see that not only systems metrics, but also business metrics, don’t decline as the software is given to more users.

The ability to effectively roll out software to small cohorts before wide release to assess impact on the business comes with the assumption that business and development people are on the same page. Karow said he’s seeing the greatest success with progressive delivery in Agile and DevOps teams.

“Those who most embrace this and get the most value out of it are already sort of in a two-pizza team,” Karow said, referring to Amazon CEO Jeff Bezos’ belief that if a team is so large that you can’t feed it with two pizzas, if won’t work effectively. “I have everybody related to this project within shouting distance of each other in a room or at least that tight in terms of a remote teaming thing, so that there’s no specification being written by one group and coding being done by another group and testing being done by another group and deployment being done by another group. Everybody knows what we’re building this week, and what we are trying to accomplish.”

These teams, he added, understand they might not get it exactly right the first time, so they’re looking to see how they can iterate quickly to improve it. “We don’t want to mark it ‘done’ because we shipped; we want to mark it ‘done’ because we moved the number.”

Split’s feature delivery management software is the means by which people work together to experiment with and deliver quality software that meets business and user requirements. “If [companies] are still solving fundamental problems to get people talking to each other and get the business and the developers on the same page, we’re not a silver bullet for that. We’re the means by which to actually do work together, not to get people to work together.”

With progressive delivery, there is a natural progression of cohorts you want to expose to new code in production, Karow said. “The first cohort you want to expose in production to the new code is your developers and your testers. This gives them one last chance to be sure everything works as expected in the actual production environment, without any risk to users. Then there’s dogfooding. If I use my own product, then I’m going to go from my developers and testers to my non-developer users. Then I might go out to my friendlies, or my freebies.  Finally, I’ll begin rolling it out to the rest of my general population.”

Learn more at: www.split.io

Content provided by SD Times and Split Software

The post Learning about your software progressively appeared first on SD Times.

According to the company, 82% of respondents commonly uncover bugs in production, 38% have a mean time to resolution of greater than 1 day, and 41% have to roll back or hotfix more than 10% of new features.

RELATED CONTENT: 
CI/CD pipelines are expanding
Getting the most value out of your value streams

“Our survey of the DevOps community has highlighted some troubling issues that directly result from the intense demand to release faster,” said Dave Karow, evangelist for Split. “There are inherent risks that organizations must bear, to speed these releases to market and remain competitive.”

Additionally, the company does not believe organizations are equipped to detect issues or address issues once they are detected, which can take a toll on user experience, finances and reputation. IDC has found that technical downtimes can cost Fortune 500 companies as much as $500,000 per hour.

“Once an issue is found, teams also often have to roll back code or hotfix it in production. Both of these practices can introduce additional risk,” the company wrote in a blog post.

In order to continue to move quickly, without introducing more risk into applications and services, Split recommends using feature flags for gradual rollouts; application, error, and feature monitoring to catch bugs quickly; and experimentation for avoiding unnecessary work.

Other findings of the report included: 87% of respondents release new features more than once a month to keep up with the demand for new features; 88% of DevOps teams need more than an hour to resolve detected issues; and 27% of respondents think features are poorly adopted and utilized.

The report is based on conversations with more than 100 different DevOps organizations in the US.

The post Split Software uncovers DevOps downsides to releasing software faster appeared first on SD Times.