Let's start off by coining a term: feature visibility. You can infer meaning from the component words. I'm not getting overly creative here. Feature visibility is simply the idea that anyone in your organization can have immediate and clear information about the state of a particular feature in your software. So why am I talking about this word as if I'd just coined the initial use of "agile" or "DevOps" or something? Well, because while the concept of feature visibility might be simple, the realization of it isn't. In fact, this is something that has completely eluded the IT world over the years, by and large. To understand why, let's take a stroll through feature visibility (or the lack thereof) throughout the history of software.
Shipping CDs and Disks: The Feature Visibility Dark Ages
When I started my career, I worked for a company that manufactured mail sorters. These sorters were extremely large machines, and we'd ship them to customers and then assemble them onsite. Of course, software powered the sorters and presented interfaces for the operators. We would take our official builds, create CDs and ship those CDs to customers containing new versions, updates, and patches. I forget the exact cadence, but barring an emergency, we weren't issuing new versions more than once every few months. It sounds crazy today, but this was the early 2000s, and that's just kind of how things went. Now, imagine my confusion if someone had asked me about the state of a feature, a day or two after we'd shipped a new version of the software. "How many users are using the new expedited operator login, and do they like it?" I would have looked at you as if you'd asked me the chemical composition of Jupiter's core. "Uh, nobody has called to complain, so I guess maybe some of them are using and maybe they like it alright," I'd have said. But the truth was, we really have no way to know this. It was surprisingly common to ship some configurable feature and learn much later that nobody had turned it on or used it. As a development organization, our view into actual field usage was nonexistent. Absent support calls, we relied on field techs and account managers to furnish completely anecdotal accounts of customers' opinions of features.
The Web Created New Opportunities and New Confusion
Over the interceding years, the world would migrate toward web applications, and later mobile and distributed ones. This created a lot of opportunity to improve on the situation that I just described above. Shipping (literally) desktop applications to disconnected clients made capturing any kind of usage statistics a real challenge. But with web applications, that sort of thing became easier. Extensive logging and application instrumentation could furnish a good bit more insight, which drove a lot of advancement in user experience. And the web deployment model enabled companies to push software into production much more frequently, a significant factor in the explosive growth of agile methodologies. But this improvement did not necessarily create a proportionate amount of additional feature visibility and clarity. I can still recall facepalm-inspiring miscommunications in the late 2000s and early 2010s. The sales team would tout some new feature, shipped with the latest version of the software, only to have a prospect point out that the feature didn't seem to exist. "Oh, we rolled that back because it was buggy. Didn't you see our latest release notes," a harried dev manager would ask. Or perhaps it'd be a CIO bragging internally about the team's hard work creating a feature and shipping it on time. And then someone in account management points out that almost nobody actually uses it, and they've actually been advising customers to turn it off in their settings until the next release. An increasingly distributed and web-based world did not necessarily fix the chaos. Feature visibility remained abysmal in most organizations.
New Opportunity Comes From the Lean Startup Mentality and the Rise of Experimentation
If I had to distill the agile movement into one core premise, I would say that it encouraged organizations to figure out how to ship early and often. And if I had to do the same for the DevOps movement, I'd say that it encouraged the removal of organizational silos in support of fast shipping. And with these two core concepts, an interesting trend emerges: the modern enterprise emulating a startup. Think about it. Startups ship early and often, with a sense of urgency. And they also have neither the time nor personnel to create complex organizational systems and silos. Everyone scrambles to do what needs to be done in order to live to fight another day. Increasingly in the last few years, established organizations have sought to capture the startup magic. The lean startup movement has exploded in popularity and society has seen the emergence of a new term: intrapreneurship. Intrapreneurship certainly involves cross-functional teams and fast shipping. But it also involves the idea of experimentation and validated learning. Instead of convening focus groups to research which checkout page yields the best purchase rate, launch two of them, A/B test, and pick the best one. Instead of speculation, run experiments and act with data and intelligence. This mentality has seen our conception of software become much more granular. Long gone are the days of going a year between releases. But now, we hardly think anymore of releases at all. Instead, we're deploying features, migrating between services, and running experiments. And with this change, we've gone from regarding feature visibility as a pipe dream to a complex configuration management issue.
The Modern Configuration Management Challenge
Imagine yourself running a software department, and that you've grasped the strategic concepts at play. You're an agile shop, you embrace the DevOps movement, and you want to adopt a granular, feature-based deployment strategy. You want to ship software more like Facebook and less like my mail sorting company did in 2003. Get this in your head, and you might find your team re-inventing a lot of wheels. You want to do some A/B testing on the new shopping cart, so you add conditional logic around it and a setting to some config file. That goes well, so you do it again, and again. This mushrooms from a manageable handful of Boolean features to a sweeping configuration nightmare that requires full-time staff to manage. The feature visibility problem has not evolved yet again. It started with impossibility, moved to opacity, and now becomes one of complexity. Teams with homegrown feature flag management have the capability and data, but it becomes a signal to noise problem. If a sales team member or an exec asks for info about the state of the new cart feature, and the response is, "I'll have to go through our config settings and get back to you in a couple of days," do you really have visibility?
Feature Visibility Via Sophisticated Feature Flag Management
That sort of thing just isn't going to cut it these days, if you want to be a truly agile organization. Imagine that you lack this visibility and that your competitors have it. When their sales people or CIO ask how the rollout of Instagram support is going, support staff can simply send them a clear screenshot of a dashboard like the one below. Or better yet, those folks can just log into an easy-to-use system and see for themselves.
Your software doesn't come on CDs these days. And it's (hopefully) not a sequence of yearly or quarterly releases. More and more, it's a fluid and continuous push of changes to features. It grows more like an organism these days, with a lot of complex interrelated subsystems, all of which have their own disposition and health. Feature visibility is your key to managing that successfully. It combines significantly more granular control with significantly reduced complexity of management, allowing truly fast and cross-functional decision-making. So when you think about evaluating your team's capabilities, ask yourself a different question. Instead of asking if you're agile or lean or if you're doing DevOps properly, ask yourself what degree of feature visibility you have at your disposal. And if the answering isn't "high," then you should be figuring out how to fix that.