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