New Barriers to faster growing Software Development

Software delivery speed continues to accelerate. Toward that end, software teams have adopted Agile, DevOps and continuous integration/continuous delivery (CI/CD) to speed release cycles. Meanwhile, tools throughout the software development lifecycle (SDLC) have been enabling more automation and providing more intelligence.

Piece by piece, each phase of the SDLC is being optimized, albeit at different rates in different organizations. However, as specific bottlenecks are solved, new ones take their place. A couple of development-related issues that may be holding software delivery up are traditional feature flagging and hand-coding.

Traditional feature flagging vs. feature experimentation

The purpose of feature flagging and feature experimentation platforms is roughly the same: speed the delivery of value. Feature flagging allows features to be turned on and off. For example, a developer can deploy code and turn a feature flag on or off to test it with a user base, such as alpha and beta testers or some other subset of users. Daniel Spoonhower

Feature experimentation platforms include feature flagging as well as some combination of A/B testing, canary releases, and blue-green releases. Feature experimentation platforms also enable organizations to do more targeted testing than traditional feature flagging, down to individual users.

"Some form of feature flagging is absolutely necessary for modern development: You need to be able to decouple pushing out new software from adding new features to the user experience. This is critical to letting individual teams move quickly and lowering the coordination required among teams," said Daniel Spoonhower, CTO and cofounder of app performance monitoring solution provider LightStep in an interview. "Sometimes the ability to roll out features to a subset of users is touted as a benefit of feature flags, and it is, but I think that’s less important than its impact on developer velocity." 

One of the reasons why traditional feature flagging can slow development compared to feature experimentation platforms is that traditional feature flagging can be an occasional practice, such as for risk mitigation, which limits its usefulness. Feature experimentation platforms promote the use of feature flags as a continuous process.Jay Jamison

"Traditional feature flagging is a blunt tool. Either a customer sees the new feature or she doesn’t because it’s behind a feature switch. New feature experimentation platforms are much finer grained and conditional," said Jay Jamison, Chief Product & Technology Officer at low-code platform provider Quick Base. "Both approaches can be effective depending on user requirements, but you need to have a window into the newer approach, as gaining richer customer insight faster is the name of the game. You may still need traditional feature flagging for good reasons, but you’ll want to be adopting the new experimentation platforms to accelerate innovation in your company."RJ Jainendra

Feature experimentation platforms also target a broader base of users than developers, which isn't necessarily a time saver if sound processes haven't been put in place. While the inclusion of product managers tends to be viewed as a good thing, the inclusion of others such as salespeople tends to be viewed as dubious.

Hand-coding vs. low-code

Hand-coding isn't going anywhere anytime soon because there are times when it's the only way to get what one needs, whether it's custom functionality or a connector to an application that doesn't already exist. However, not everything needs to be hand coded.Mike Guggermos

The realization of that fact has resulted in numerous waves over the past several decades including object-oriented programming, libraries, components, and microservices, all of which stress reusability so organizations don't have to handwrite code unnecessarily.

"GCP, AWS and Azure or even Box, Dropbox and [others], have these software libraries, these modules, they have these programs that you can plug into whatever it is that you're doing. So why write [the same thing]?" said Mike Guggermos, CIO at smart email platform provider Black Pearl Mail. "And there's a generational shift that's starting to occur where the pride of ownership is more around the assemblage of the building blocks and then wrapping it in something unique, versus having to go in and write a section of code that's going to allow you to do an auto connect into Slack."

Although developers tend to dismiss low-code tools as toys, they're not a one-size-fits-all proposition. There are no-code tools aimed at business users, and low-code tools aimed at web developers and traditional developers, respectively. At the present time, Gartner is tracking 200 low-code/no-code vendors.

The low-code tools and even some of the no-code tools provide easy access to a command line window because as applications built with these tools mature, they inevitably require custom functionality or integration that exceeds the capability of the platform or the person who wrote the initial application.Mark Runyon

Despite the stigma among traditional developers generally, companies in many different industries are using low-code to achieve an order of magnitude gain in speed, building core enterprise-class applications in months versus years, turning simple application updates in a matter of minutes, using low-code to build a minimally viable product (MVP) as fast as possible, and everything in between.

Most established software providers aren't using low-code tools. However there are some startups basing their entire business, at least initially, on a low-code platform.

Even low-code can hit speed bumps, however, particularly if an application has to be rewritten.

"Low code projects are best for those with constrained requirements that you know aren't going to need additional development after completion. [It] does give you a solution faster than traditional hand coding, but it does present significant roadblocks when you have to do something custom," said Mark Runyon, principle consulting for software development firm Improving.com.

Some platforms allow a seamless handoff from the initial application to its later, more customized or complex state so the initial time spent on developing or prototyping isn't lost. To do that effectively, though, the platform should be enterprise-class to begin with since low-code/no-code platforms are not exactly interoperable with each other.

Bottom line

As organizations continue to accelerate their software release schedules, they need to continually identify obstacles that slow the process. Development is as ripe for transformation as any of the other functions in the SDLC, so it's up to organizations to figure out how its efficiency can best be improved without sacrificing user experience and quality along the way. Feature experimentation and low-code platforms can help.