I see dead features

The long journey of Power Platform evolving into what it is today means we have a lot of layers in the product. For the newcomers that have only ever worked with Power Apps, those layers may remain invisible. They only manifest themselves as strange behavior and unintuitive design in the product. At the extreme, the result can seem like paranormal activity that produces unexplainable results in low-code solutions and tooling.

Seasoned XRM veterans can help in unraveling these mysteries. Knowing the origin story behind different parts of the platform provides the perspective needed in understanding why things are the way they are. It also helps in knowing which dead features are better left untouched when building your solutions. These may be lurking around any corner, and even hiding in plain sight. As an example: reports in Power Apps.

“Let’s create a report for this app”

When you are within a solution in the Power Apps maker portal, clicking on the “New” button to add a solution component will give you this kind of a menu today:

Out of the 8 options directly visible, 6th is “Report”. Great, sounds like something every app maker should get familiar with. So, you click on it, and suddenly you find yourself in a UI that looks very different from the standard Power Apps experience:

“Umm, okay, I guess this is fine…” you think to yourself. Clicking on the Report Wizard button is the only option that makes sense, since you don’t have an “existing file” or a “link to webpage” to give to the UI.

As you click further, the menus just start to become more and more confusing. The “Lay Out Fields” page has some sort of column management options to work with. Yet there doesn’t seem to be an obvious way to define how you would want the data to be visualized. This is a report we’re talking about, after all, so where could all the chart options be hiding?

Clicking on the Help icon takes you to a warning about expired SSL certificate. You’re pretty desperate at this point so you choose to ignore the browser’s warnings, only to discover that the domain (www.dynamics365cedocs.com) points to an Azure website that’s no longer there:

“What on earth is going on here?!?” You open up your favorite search engine and discover the current MS Docs page for Create a report using the Report Wizard. It goes on carefully illustrating the usage of the wizard that just confused the hell out of you, with the kind of neutral language that implies everything is perfectly normal.

“Use the Report Wizard to create reports with charts and tables that allow you to easily analyze your data. All reports that are created using the Report Wizard are Fetch-based reports. All reports generated with the Report Wizard print in landscape mode.”

You have no clue what “Fetch” means and you have no patience left to explore this strange land further. You reach out to either a more experienced colleague, or maybe post a question on the forums. If you’re lucky, an old CRM geek like me will give you the answer:

The walking dead

Those who have been with the product since early XRM days can spot features that haven't been touched for ages. Similar to how in the classic movie The Sixth Sense the little boy was able to see something others weren’t:

It’s a skill that you can only learn through several years of experience in working with the Microsoft products and observing how they evolve. Or more precisely, paying attention to the parts that don’t evolve. Understandably these parts aren’t the ones we see the product marketing team draw your attention to. It’s all about reading between the lines and spotting what is not being addressed in the product release plans.

Capabilities once launched with big fanfare can quickly turn into dead features as the vendor strategy and product portfolio shifts. The aforementioned Report Wizard based on SSRS (SQL Server Reporting Services) was abandoned when CRM 2011 introduced dashboards and charts within the app. Then, years rolled by and not much changed in how they behaved. Once Power BI was introduced there’s been no future for dashboards in model-driven Power Apps, aside from minimal technical maintenance. Microsoft’s in-app data summarization features have long since degraded to a state where you as the app maker/consultant just try to avoid them. At the same time, dashboard functionality on Salesforce side is on a whole different level - because they didn’t have Power BI as an internal competing/complimentary product to affect the CRM features.

The symptoms of a zombie feature aren’t always as easy to detect. The deeper you go into the specifics of the platform, the more subtle the signs get. In the realm of data modeling, there are attractive looking features in the Maker portal that most seasoned XRM professionals would avoid touching if at all possible. Connections sound great for ad-hoc relationships, yet have a terrible UX. Many-to-many table relationships would make sense for many business scenarios. In practice, developers have been burnt by their limitations and prefer to create custom intersect tables instead. Choices (formerly multi-select option sets) is not only the most awkwardly named feature. It also includes so many functional gaps compared to single select choice columns that it’s incredible how much a single letter “s” can complicate things.

The common theme for almost all such scenarios is that the V1 feature has been brought to market, then abandoned. Especially in the bygone era of on-premises versions it was all too typical that a feature never saw a V2 once the next software release arrived three years later. Even justifying V1.1 enhancements seemed too difficult to get them prioritized in the backlog, which meant a lot of the early capabilities in the platform were shipped only once as “good enough”. They ticked the box for requirements analysis against competing software. Making the feature more pleasant to use wouldn’t have increased the size of that box, so the commercial incentives for polishing enterprise software weren’t exactly aligned with the needs of end users.

Did the arrival of cloud based software and agile release processes fix this? Well, the ability to ship new solution versions every week into Microsoft hosted cloud environments certainly lowered the technical barrier to improve existing features. Now, the other side of the coin is the eternal preview phase. When MS software doesn’t have to be Generally Available to be… broadly available, that leads to incomplete and unpolished features appearing in customer environments. Features may still die as they fall out of the product team’s radar, but now we get to also the immature stage before they reach V1.

Graveyard shift

Once a zombie feature is being officially eliminated by MS, there will usually be an entry in the documentation page for deprecations. There’s no single site for MS BizApps, instead today there’s at least 11 different pages where a feature may be laid to rest. Compared to the list of new features included in the release plans published every six months, the list of deprecated features is quite short. This means there isn’t a great wave of legacy features that get the official EOL stamp (end of life), even in this day and age of the evergreen cloud products.

Google is legendary for its low barrier to pull the trigger and kill its products. While there is a similar virtual graveyard for Microsoft products and features across the whole corporation, I think the cultural difference between the two organizations is still clear. MS is often more cautious about not angering their enterprise customers with sudden end-of-life notifications. Upgrade paths and backward compatibility can sometimes be taken to the extreme, as has been demonstrated in the case of Windows and this legendary video of upgrading through every version ever released:

Note: this does not in any way mean that Microsoft would stick to the very same product names. The software may continue to live for years and years, but it’s fairly likely to get “reimagined” at some point and either combined with a separate piece of software or just rebranded for the fun of it.

Killing zombie features is hard

Why aren’t the technology vendors ensuring that the bodies of dead features are properly taken care of, to stop these zombies from emerging? After all, most software products that have been around for years are suffering from feature overload that increases the cognitive load of users. Wouldn’t it be in everyone’s interest to keep a balance between new features to add and old features to remove?

Unfortunately the real world doesn’t work like that. Most organizations have clear incentives in place for adding new features. Removal of features, on the other hand, seems to happen only when the mess gets unbearable and someone does something about it. Such as the cost of running parallel server resources to support both old and new UI or API. An example of this would be Microsoft’s multi-year efforts in shutting down legacy web client interfaces for model-driven Power Apps and replace them with the Unified Interface (I first blogged about that in 2017).

Often it’s not at all as clear to the software vendor how much they could save by formally removing a feature. An inconvenient truth about software product management is that the costs involved with a feature don’t end at GA deployment time. In addition to ongoing support, the eventual decommissioning requires resources. Dependencies to other platform features, let alone providing migration paths for existing customers, are not an insignificant effort to deal with. All this while you have ongoing pressure to deliver new features appearing on your backlog.

As the maker, consultant or end customer of these global cloud platforms that keep rolling out shiny new features, you may often feel overwhelmed with the constant changes. At times like these, it’s comforting to remember that much of this new technology will never grow up to be useful for you. Some features will already get dropped/cancelled in preview stage, others reach a V1 level that isn’t practical for adopting it into your own toolkit yet.

It’s relatively easy to assess feature maturity by checking how long has it been since the first announcement. The other direction, meaning knowing when an older feature has likely been left to die - that’s a bit trickier. The most practical way is to observe the community around you and see what they are saying about it. If you find yourself to be the only one asking about a certain product or feature in online channels and can’t locate mentions of others experiencing the issues you’ve encountered - chances are you are working with a zombie.