Quite often we talk about architectural concerns on this blog, with topics like application layering or the merits of design patterns. But today I’m going to switch gears a little and talk about your wallet.
Oh, don’t worry. We’re not going too far afield. I’m going to talk about how your developer tools purchases affect your wallet.
When it comes to product support, you probably don’t give this a ton of thought. At least, you’re probably more focused on features, what problems the product solves for you, what the price is, and so on. The support arrangement probably matters somewhat to you, but doesn’t rise to top of mind.
But today, I’m going to ask you to think about it a little bit. And I’m going to suggest that you give a quick consideration during future purchases as to how support works. Simply ask yourself, “does this vendor ask you to pay extra for support?”
If the answer is yes, that’s a smell.
Independent Software Vendors (ISVs) in the Dev Tools Space
NDepend is what’s known as an independent software vendor (ISV). In the broadest terms, this term describes anyone that sells software to third parties (as opposed to, say, in-house software). But for our purposes here, let’s consider the dev tools space.
Microsoft has a rich ISV program, which makes sense since it offers such a wide variety of platforms to the market. NDepend is an ISV that participates in the Windows and Visual Studio ecosystems. As software developers, you deal with a lot of such ISVs because they add on to Visual Studio, .NET, etc. and enrich your experience.
And, as you pick from among them, you have lots of options and lots of decisions to make. Some of these tools are free and open source (though perhaps this stretches the definition of “vendor” slightly). Others are paid, with various models such as one-time or subscription-based. Some offer different renewal options and support plans. You get the idea.
And all of us know all too well how easily you can wind up agonizing over decisions like this. Which developer productivity plugin should you buy? Which unit test runner and mocking tool to use? And what about the build? It can lead to analysis paralysis.
Let’s narrow the focus a little, though, and get back to support policies and how they can help you make a good decision.
The Different ISV Product Support Options
When it comes to customer support, there are, roughly speaking, three options at your disposal.
- No support at all, caveat emptor.
- Support is included in the price of the product.
- Support is extra (or, in some cases, basic support is free and “premium” support is extra).
The first one isn’t really worth talking about at any length. This is just a situation where you buy the product as-is, and good luck with it. This usually happens for pretty small ticket items.
Included support is reasonably self-explanatory. You buy the product and, along with your purchase price, the tool vendor supports you in any issues you might have. This is NDepend’s model, for instance. Included support arrangements also commonly feature a timebox of validity. Meaning, you get support until the current release becomes obsolete or perhaps you always get support because you’re paying annually for continued access to the latest and greatest of the software.
And, finally, you have models where you purchase the product and then you can, optionally, purchase a support plan. As I mentioned, this can be a simple extra transaction, or a “freemium” model. In the latter case, basic support comes with the product, but there are elevated support plans that include quicker access or the ability to make phone calls, for instance.
Let’s look at the incentives created by each such plan.
The Incentives With Paid Support
Let’s be clear about something right up front. No software vendor ever wants to bake bugs into their product. Bugs are a bad look, and they hurt the product’s brand, reputation, and marketing.
So what I’m about to talk about doesn’t have to do with product quality. Rather, it has to do with user experience.
And the simple fact of the matter is that offerings with paid support have a mildly perverse incentive to skimp on user experience.
Whether they follow this incentive or not is another matter, but the incentive definitely exists. Think about it. If support is extra, you have a product ladder where support is a higher tier option, and thus more appealing to the vendor. Any vendor with multiple levels of service would rather all clients move to the top.
So how usable will they want to make the product, exactly? Well, that’s an interesting question. They’d certainly want to make it usable enough that people didn’t hate it. But they’d have every reason not to make it too usable, especially in the beginning, so that people who had already invested in the product would be more likely to invest in the upgrade to get service.
It’s a clever model for making the offering seem less expensive than it winds up being.
The Incentives With Included Support
Contrast this with the incentives for a product that includes support in its price. At the moment you make the purchase, the vendor has realized all of its value from the transaction. Any support it offers comes out of its bottom line.
Because of this, your incentives and theirs align intensely on the subject of user experience. You want a product that is as discoverable and usable as humanly possible so that you can get down to using it to solve your problems. And they want this as well, since minimizing the amount of support needed helps their bottom line.
Now you might wonder if this set of incentives doesn’t encourage the vendor to simply skimp on support. And, back in the days of buying software as CDs in boxes, that would have been true. But today, software has shifted to an episodic, re-purchase model. This means that the vendor has to continually win your business every year (or whatever renewal period they have). And you don’t win repeat business by blowing off customers that are struggling with your product.
Case in Point: How NDepend Promotes UX to Minimize Questions and Frustration
NDepend includes many features: code quality, code rules, quality gates, issues, technical-debt, diffing all results since a baseline, code metrics, dependency exploration, trending, Visual Studio/VSTS/TFS integration, reporting, and CI integration. All these features converge to let users write more maintainable code. It means spending more time offering value instead of fixing problems that could have been caught early on. But if you want a complete toolbelt to address software quality, it comes with a steep learning curve. As a result, we’re relentlessly working on offering a better first-time user experience (FTUE).
In this context, it could be business-savvy to not invest so much in FTUE and instead propose pricy support. But we didn’t go that route. Rather, we include email support in our affordable yearly subscription model. Our business model is to scale on thousands of companies’ clients worldwide. We believe in the scaling model: do a thing well once and sell it to many. We also believe in software that offers value mere minutes after downloading the trial version.
With all these active users, we have a few strategies to cut down on your need for support:
- We relentlessly improve both the product embedded documentation and online documentation. Most support questions lead to documentation improvement.
- We capitalize on the Microsoft UI standards. Our users are also Visual Studio users. Most UI challenges we face are already addressed by VS, and thus NDepend features accessibility is largely inspired from VS standards.
- We treat error reports as features. If something goes wrong, like a file not found or a corrupted installation or integration, we show a complete actionable explanation to the user.
- We avoid regressions and bugs with automation. Eighty-six percent of NDepend’s code is covered by automatic tests, and we stuffed NDepend’s code with assertions that let us know each time something goes wrong.
- We dogfood NDepend on itself. The NDepend code is continuously controlled by more than 250 rules that often warn us way before the issue turns into a real problem.
- We also capitalized on in-house production error loggers that provide us with the necessary knowledge to fix production problems, often before a user decides to go to the help menu and submit feedback.
- When a user asks a complex question, often wanting us to help them write a peculiar code query, we request that the user ask their question on Stack Overflow. This way, we can invest in a complete online answer that will be available to other users through a Google search.
- An NDepend User Voice page lets users automatically submit their feature requests and vote for existing ones. Both the NDepend website and the embedded product start page reference this page.
These strategies are working—we’re saving a lot of resources on support.
Look for ISVs That Include Support
So, in the end, can you necessarily expect better user experience from products that include support in the purchase price? No, nothing is absolute. But you do know that such products have a strong incentive to provide a better user experience.
Unfortunately, you can’t definitively know in advance what your user experience will be like over the life of the product. User reviews and free trials help, but only up to a point. You’re still operating with imperfect knowledge.
But you can help yourself a lot by looking at whether the support will be paid or included. And, if the support is paid, understand that the vendor has every reason to hope you need support. And, if it’s included, understand that the vendor has every reason to make your experience as smooth as humanly possible.