Developer's Toolkit

Blog archive

Needed: A New Approach for Software Tools

Prior to leaving on vacation, I penned the previous entry, in which I noted that the business of building software development tools beyond the fundamental editor, compiler, and debugger was in trouble. Part of the problem is that open source and free software tools tend to be very good, lowering the value of their commercially-developed equivalents. But the same is true of compilers (Gnu C) and debuggers (GDB), yet they still seem to remain commercially viable.

The real problem, I think, is that the tools to which I refer lack the necessity of compilers, editors, and debuggers. Tools such as performance profilers, thread analyzers, and refactoring utilities simply aren't required to write software. They are only needed when they are needed. When they are needed, they are very valuable. That's about five percent of the total development time, depending on the tool and the application being written. The other 95 percent of the time, they are worth little or nothing.

To be honest, there may be a benefit in establishing the use of such software development tools as part of a process: profile daily, refactor regularly, and so on. That benefit has never been well-quantified, however, and most developers focus on producing code rather than defining and following a strict process.

This presents a challenge to commercial tools vendors, including my former employer, Compuware, as well as companies such as Parasoft, Quest, and even Borland. How does a commercial vendor justify making software tools that lack a consistent value? And how does a development group justify spending money on such tools?

In the comments to my previous post, someone suggested a hosted application model for software development tools. In such a model, the profiler or utility runs on the vendor's server, but is accessible to the development groups when they need it. Developers pay for the use, rather than the purchase. Granted, the cost of use will probably be fairly high, but if developers solve an immediate problem, they may believe that the value is well worth the cost.

Would you use a software development tool this way? In my own experience, I think I would strongly prefer to have everything I might need readily accessible, and on my own system. Is having it readily accessible, but on a remote server operated by the tools vendor, good enough?

Posted by Peter Varhol on 06/04/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