Developer's Toolkit

Blog archive

The Software Business Has Changed

Or perhaps it is just me that has changed over time. That part is certainly true. In addition to hair color trending gradually toward gray, I have just been fitted with my first pair of progressive eyeglasses.

But I've always been interested in the business of software, for at least three reasons:

  1. We, as an industry, build products that we know have defects and limitations, and sell them with a license claiming they have no value for anything.
  2. As we continue maturing the products through subsequent versions, they become increasingly fragile rather than increasingly stable.
  3. We have little understanding of the market in which the software is sold, and sell without understanding the customer's business of the problems we need to solve.
Let me focus on the last of the three. In the latter half of the 1990s, this didn't seem to matter so much. Users of the software development productivity tools I helped purvey were encouraged by the promise of improvements in the quality or quantity of their custom-built software.

But there was a problem. In many cases, it didn't happen. Software became what is commonly called "shelfware," remaining in the box on the shelf, rather than installed and working on developers' systems. There are any number of reasons why this was so. In some cases, development groups lacked the discipline or methodology to incorporate tools beyond an IDE into their daily activities. It may have been incumbent upon us as the developers to devise solutions that made our customers successful, through either better usability or better training. Either way, much of the software sold to developers remained unused or little used.

But today shelfware has become a thing of the past. If you can't immediately put it to productive use, you can't buy the software. This means that vendors have to do more than deliver a high-quality product. They have to understand what developers need that product for, and how they will use it.

This is especially difficult for the software tools business, because of the strange equation surrounding tools. Tools to aid in developing and testing software have in effect no value 95 percent of the time. This is because they are not used. This statement is true of even such basic tools as debuggers. Granted, a debugger tends to get more use than other tools, but it is only used when it is needed.

There was once a time, not that long ago, when developers were willing to pay sometimes a significant amount, for access to these tools 100 percent of the time, in order to actually use them for the five percent when they were really needed. Occasionally we had the odd developer who would request an evaluation copy of the tools, three or four or five times a year. What those developers were doing is getting free use of the products, only when they were needed. We tolerated these developers, because we didn't have any way to refuse the evaluation or make them buy.

Well, money is scarcer today, and paying for occasional use doesn't make a lot of sense. It turns out that those who requested evaluation software only when they needed that capability had the right idea after all. The value was nothing most of the time. During the brief times when the value was high, we were willing to give away the software, at least for brief periods. It turns out that for many developers, those brief periods are all that is needed.

So is it possible to make money from building and selling software quality and productivity tools to developers? That's a good question. If you have any thoughts on the issue, please let me know.

But I won't follow up right away. I'll be leaving on vacation in a couple of days, so I'll be back on these pages in a couple of weeks. See you inHawaii.

Posted by Peter Varhol on 05/19/2005


comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube