We see three broad trends in the enterprise computing world that have a profound impact on bug-tracking:

1. The establishment of client-server architecture as the norm, which has spawned the advent of huge development teams.
2. The rising prominence of Microsoft in the enterprise.
3. The advent of the Internet and the World Wide Web as business technologies.

Our design for Visual Intercept is almost entirely driven by these three evolutions in the enterprise. We designed Visual Intercept to be more than just a bug-tracker, but to address the broader underlying issues of managing large groups of developers through the entire development process. We adopted a three-tier architecture, which would give us the technological muscle to scale up to support large groups, while maintaining the flexibility to adapt to emerging trends in the enterprise, such as metrics, data mining, and the Internet. Since the client-server model has brought enterprise computing downto the desktop, and Microsoft’s product line has moved up into the enterprise, we foresee Microsoft as the dominant player in enterprise development, and we designed Visual Intercept to fit in with Microsoft’s enterprise strategy.

All of these factors blend into one another, so forgive me if I blur the distinction from here out.

Competition is always a concern, especially if a clear market leader had already emerged and set the standard. But that hasn’t happened with defect management - the market is still very fragmented, with nobody holding more than 12% of the market. And that’s just for those who are currently using some sort of bug-tracking system, which is a minuscule fraction of the potential market. A study by Adams, Harkness, and Hill is predicting a growth rate of 40% or more in the software quality assurance market, getting well over $2 billion by the year 2000.

The market has been like that for some time, with the need for bug-tracking growing at phenomenal rate, but nobody (as yet) coming forward to dominate. Some of our competitors have been out in the market for five, maybe eight years, and they still have yet to solve the bug-tracking puzzle.

So no, I don’t see the competition as being the biggest obstacle to our success. The field is wide open.

Largely, it’s because for the last ten years they’ve been trying to hit a moving target. Business computing has been changing so rapidly that today’s typical development environment looks nothing like it did when the first bug-tracking systems were coming out.

The client-server revolution brought along with it an enormous increase in the size of development teams. Integrated development environments like Visual Basic^TM made it much easier for people to program. Instead of relying on a handful of rare, costly software engineers, companies could use legions of readily-trainable VB programmers to tackle their computing problems. Now development teams of 50 or 100 people are the norm, and developers’ tools like bug-tracking are struggling to support the added load and the added complexity. The biggest complaint I’ve heard about most existing bug-trackers is that they don’t scale. They simply were not designed to handle big teams - their proprietary desktop databases couldn’t handle the sheer volume of data, and their methods for handling the data were too inefficient to support the traffic.

Now the industry is facing another big shake-up: the explosion of the Internet. Many companies have development teams spread out geographically, and they are looking to the Internet to help coordinate their efforts. So once again many existing bug-trackers are going through the painful process of trying to graft new technologies onto their old frameworks.

Absolutely. We have the benefit of 20/20 hindsight. We can build from the ground up using the most current technologies, rather than completely revamping an old product to fit the current enterprise needs.

Actually, the whole reason we created Visual Intercept was to address the short-comings of the existing bug-tracking products. Raleigh Group International, a reseller of developer’s tools, had been trying to find a bug-tracking solution for their customers for years, but they were completely frustrated because none of the tools currently on the market were meeting the customers’ needs. They finally decided that if the right bug-tracking didn’t exist, they’d have to make it themselves. RGI brought me all their accumulated wisdom on the bug-tracking market, and I started Elsinore.

It was from RGI’s market data and marketing strategy that we derived our strategy for Visual Intercept. That was what prompted us to focus on integration with Microsoft, and scaleability, and so on.

Because Microsoft is positioned to dominate in the enterprise. Sales of Microsoft's Windows NT^TM operating system shot up this year, outpacing sales of UNIX-based servers and workstations. Wintel machines are now rivaling UNIX boxes in raw power, and they are perfectly capable of handling most of the enterprise market, networking 50 users at a fraction of the cost for an equivalent Sun/UNIX solution. UNIX servers running Oracle^TM databases may hang on to the high end of enterprise computing for the time being, but Microsoft will scoop up everything else.

The key to Microsoft’s enterprise strategy is integration. In addition to having a strong operating system, they have an incredibly broad line of products: back-end databases, development languages, version control, Internet tools, Internet servers, everything. And it all works together. Microsoft offers one-stop shopping, a complete, integrated solution, and that synergy of products is exceedingly attractive to business. Just go to the Microsoft web site and see the enormous spread of products - everyone else seems narrowly focused compared to Microsoft.

Enterprise computing is already exceedingly complicated - the last thing IT departments want is the hassle and risk of integrating systems from different vendors. Information professionals want to concentrate on their own business problems, rather than be continually distracted by systems integration issues. No other company in the Wintel tools business has a line-up to rival Microsoft's, so we expect that more and more companies are going to be standardizing on using Microsoft tools.

Absolutely. So many people forget how critical integration is to a buying decision. You might think that you would evaluate a bug-tracking system for its features, what it can do when you pull it out of the box. That’s a valid thing to do, but evaluating just based on raw feature-set is a very limited perspective; it assumes that a product is a stand-alone item, something used in isolation. The reality is that no tool is an island - especially in software development, everything is used together. That’s why integrated development environments are so popular - it’s so much easier to have your editor, your compiler, your debugger, your version control, all in one place and working together. And you want to be sure they will always work together, even as new versions come out. So you can’t even settle for current integration, you have to shop for future integration as well.

We think defect management is no different. Yes, users want all sorts of features in their bug-tracker, but most of all they want it to work with everything else they’re using. If it doesn’t fit, it doesn’t fit; all other features are moot.

Microsoft does not have a bug-tracking system in its product lineup. That means hundreds of thousands of Microsoft tool-users are looking for a bug-tracking solution, something that will plug seamlessly into their current system. We designed Visual Intercept to fill that specific need. We literally asked ourselves, “What kind of bug-tracking system would Microsoft have built?” -and then we went and built it ourselves. We made integration into their environment a mainstay of our vision, and implemented all the technologies (like ODBC and ActiveX) that would let us continue to integrate in the future.

Over time, we expect that Microsoft will start bundling all of its development tools together in a single product, similar to the Microsoft Office^TM suite of tools. We want to be a part of that suite - that’s how closely we want to integrate with Microsoft (continued below).

Windows 95

SQL Server

Visual FoxPro

Visual C++

Frontpage

ActiveX

Normandy servers

Exchange

Team Manager

At the product level, we focused on integrating with Visual SourceSafe, Microsoft's version control package. Bug-tracking and version control are such closely associated processes, we knew that that integration would be the most critical. We can proudly say that we now have the best integration with Visual SourceSafe™ of any product on the market. We went well beyond the usual command-line interface that some of our competitors offer; we gave the user complete access to Visual SourceSafe functions from within Visual Intercept. Rather than just handing the user a generic SourceSafe API interface, we created an integration that was specifically tailored to meet the needs of bug-tracking.

Other Microsoft products also were integrated: MAPI mail systems like MS Mail^TM and Exchange^TM, and Visual Basic. Visual Intercept is true ODBC, and we ship with MS Access^TM, SQL Server^TM, and Oracle^TM drivers. In addition, the Enterprise Edition of Visual Intercept features integration with the following products:

• Outlook
• DevStudio
• Visual Studio
• Visual Basic 5
• Visual Basic 6
• InterDev
• Word 2000
• Excel 2000
• PowerPoint 2000
• Project 2000
• FrontPage 2000

On a more global level, we emulated the Microsoft look & feel in the GUI interface. Integration isn’t much good unless the user feels at home in the interface, so we did everything possible to make it behave as you’d expect a Microsoft product to behave. (This is another place where my background in the Macintosh world pays off. I’m quite sold on the virtues of standardizing user interfaces.) The browser’s hierarchical tree structure will be quite familiar-looking to Visual SourceSafe users. If you evaluate our product against anybody else’s, you’ll see that in look and feel ours is closest to Microsoft, while all the others reflect a less attractive, pre-Windows 95^TM aesthetic.

We also threw the door open to many current and future integrations by producing a Visual Intercept software developer’s kit. Visual Intercept is a three-tier client-server application in its design, with the engine’s functionality completely separate from the GUI or the back-end database. That makes it remarkably easy for us to takeall of the Engine’s functionality and bundle it into an API into which anybody can plug their applications. For instance, you could easily make your testing scripts from Visual Test^TM dump output straight into Visual Intercept. We’ll be using the API ourselves to bring more and more integrations on-line, as the market calls for them.

Lastly, we had the forsight to prepare Visual Intercept for ActiveX^TM

Definitely. ActiveX is the holy grail of integration for Microsoft. Rather than negotiating each integration, ActiveX allows everybody in the Microsoft neighborhood to integrate using a single common technology. That technology exists right now, and is already being implemented throughout the Windows development community. It’s safe to say that ActiveX is now the lingua franca in the Microsoft world. That’s why we designed Visual, Intercept from the very beginning, to use ActiveX; we used the basic tools and technologies, like MFC and C++, that make development of ActiveX controls easy. We had to give a lot of forethought to our basic design, like supporting all the OLE server issues, to make it ActiveX-ready, but all that that extra planning has paid off.

Practical, useful ActiveX applications are coming on-line faster than even Java^TM apps, so we’re reassured that our basic assumptions are correct. Once the hype over Java cools down, you’ll see ActiveX technology blossom and become a standard part of program design.

Java is a fine language, really it has 20/20 hindsight on programming, just like we had 20/20 hindsight on bug-tracking. It's an object-oriented scripting language like Visual Basic, but it doesn't have to please hundreds of millions of users with backwards-compatibility. It makes a clean break from the past, and as a result can do some exciting things with the dynamic distribution of software. But as a language, Java doesn't threaten Microsoft at a practical level. After all, Microsoft has produced their own implementation of Java in Visual J++™.

Even if Java could change the way users consume software, it doesn't address the issues of how programmers develop software. Even in the creation of Java apps, developers will still need a consistent, well-known set of tools in an integrated environment, and Microsoft can give that to them. Why should I go to the trouble of learning a whole new language, with completely unknown tools, to create Internet applications when I get the exact same functionality out of ActiveX, right now, using the C++ development environment I own and understand, right now? You just don't get enough bang out of Java to justify a sea change in how development occurs.

Visual Intercept is an incident management system. Rather than narrowly defining itself as just a programmer's tool, Visual Intercept is designed to make information about the process available to everyone within the enterprise.

Incident management spans different levels of the organization as well as different phases of the development process. A programmer might be using the incident management system to get information on a particular bug. Above him, his manager is monitoring which bugs various programmers are working on, and how fast they are resolving them. Meanwhile, above the manager, the CIO is monitoring the incident database with metrics software, trying to determine whether a new testing tools have improved the overall efficiency of the IT department and thus lowered operating costs. And on the other end of the spectrum, end users are checking up on the database to see if the bug they reported is being dealt with. (continued below)

Software development is especially difficult to manage, because every line of code can have a profound impact on the final product. Every programmer, every tester, can potentially make or break the project. That means strong leadership is essential; everyone in the development process needs to know the global priorities of the project, and make sure their work is meshing with everyone else's. Getting that kind of coordination is almost impossible with 50 or 100 people, all doing different jobs, unless you have a way to automatically track what everyone is doing and what they've done.

When I was consulting with Fortune 500 companies, I ran into this all the time. I was usually called in to solve a technical problem, but I wound up helping them manage their own development process. Usually, the problem was that they didn't have a development procedure–there was no system to make sure everybody was communicating. Well, there was a system, but software development happens way too fast for weekly meetings to keep up. You had half a dozen teams running around, with no idea what everyone else was doing. Enterprise efforts were so large and involved so many people that nobody could possibly keep up. Accountability was blurred, with teams squabbling over who owned a particular problem.

We saw the need for a unifying system, a central repository that lets everybody know what everyone else is doing. None of the other current tools can fill the need. Email systems are just a flurry of messages; they don't capture the activity in any organized fashion. Version control is good at managing code, but not projects. Work-flow management, requirements packages and the like are very good at determining what everyone ought to be doing, but don't tell what people actually are doing. There is no one place to go to find what's going on. Instead, everyone is living in their own universe–programmers are living in their compilers, managers are living in MS Project™, Q/A is living in their testing tools, and so on.

These situations are not rare exceptions; every big company I dealt with was struggling with these same issues. It was clear to me that the limiting factor on software development was not technical knowledge or human resources, but management of information. A study by the Standish Group showed that only 16% of software projects are completed on time and on budget, and that a third of all projects are never completed. Industry-wide, billions of dollars go down the tubes because of lack of coordination in development efforts. Even though the individuals within the project are all good at their individual jobs, the complexity of coordinating all their efforts dooms them to inefficiency.

Businesses keep thinking they can solve their development problems by buying more quality assurance software: more testing tools, more requirements packages. Those tools are all good things, but if you don't have the glue, a system to bind all the different elements together, then you'll still wind up with an expensive muddle.

Our initial GUI, the Visual Intercept Manager, was designed to be approachable and useful to a broad range of users: a customer support rep can make sense of it, a manager won't run away from it. So you can start doing incident management now, just with the one GUI. Over time, we can meet the needs of each individual user with new tailored GUIs we can give tech support more help-desk functions, for instance. We can also develop GUIs for people somewhat removed from the development process: executives, for instance, who want to measure the process but who don't care to see particular incident information.

By contrast, products that are positioned as "bug-trackers" are welded to a single GUI. They address the needs of programmers and their managers, but don't cover the whole enterprise. And that's the way it will stay; their design permanently limits their scope of users.

We believe that creating a bug-tracking solution is our problem, not yours. We figure out what the essential, fundamental problems of bug-tracking are, and we give that to you in an immediately usable, plug-and-play shrink-wrapped product. We're going to keep learning about bug-tracking, too; when you buy Visual Intercept, you're buying a system that's continuing to get better and smarter. By contrast, if you buy an "fully customizable" solution, you're stuck with maintaining and making it better.

When we first built the Visual Intercept Professional Edition, we decided that we did not want to go with an “infinitely customizable” strategy. If the customer can radically alter the structure or layout of the bug-tracking database, it becomes incredibly difficult for the software to be upgraded or supported. A user might gain an extra field of two in the short run, but they lose the advantage of having a professional product which continually moves forward with new features and capabilities. As we learn more about bug-tracking, we’ll be adding those same fields you would want to add to the standard product.

Moreover, radical rearranging of the data can undercut the bug-tracker as an enterprise-wide solution. If every department creates unique database structures for every project, then it becomes impossible for upper management to evaluate different software projects using the same queries. If an organization wants to use metrics analysis to get the most value out of their incident data, then standardization - not customization - is what is required.

We believe that some customization is necessary to mesh with a company's existing methods, but we don't think an overhaul of the data structure should be necessary.

With the release of the Visual Intercept Enterprise Edition, we’ve let developers have their cake and eat it, too. VBA-enablement makes Visual Intercept Enterprise infinitely customizable—developers can create code to do anything they want—while maintaining all the convenience and functionality of a shrink-wrapped solution. (continued below)

This flexibility is what allows Visual Intercept to keep up with evolutions in the enterprise. When the World Wide Web exploded onto the scene, we were perfectly prepared for it–there's nothing to stop us from building a Web-based interface to the Visual Intercept data.

We also foresee that metrics, quantitatively measuring processes, is going to be a big thing in the future. More companies are interested in evaluating their development processes, and they're looking for help in doing it. Visual Intercept is perfectly positioned to support metrics; we're already capturing all the process data worth measuring, and because of our three-tier design we can build or integrate with metrics packages to use that data.

Another big development is data-mining. Now that companies have started building big sets of electronic data, they want to start dredging that data for useful trends. Visual Intercept is perfect for data mining: the information we capture is valuable almost by definition, because it tracks problems, things you actually paid someone to solve. It's highly qualified information, well worth dredging. And, because of our three-tier design, we're perfectly prepared for data-mining. Our API and open database makes the information completely accessible and organized for whatever data-mining tools we or others might develop.

So, with the Web, metrics, data mining, you can see the pattern: whatever radical changes might arise in enterprise computing, Visual Intercept is well-positioned for it.

With incident management software, you have large amounts of data and lots of users , but relatively low transaction rates. Incident management is a reading-intensive task; lots of different people are pulling specific information from a database and reading it, but they aren't aggressively updating the database on a minute-by-minute basis. A single incident might take a programmer hours or even days to handle, and he'll be updating the database at a similar rate. This is very different from, say, a financial system, in which blurry-fast updates are happening.

So, we optimized Visual Intercept to be very good at retrieving information. To handle the ever-changing volume of information held in the system, we made Visual Intercept ODBC-accessible, You can scale up your back-end database as your body of data grows. A small group can use an MS Access database. A larger group, 50 or 100 users, can use SQL Server, or even Oracle if they really need the speed. The back-end database should not be the limiting factor on performance.

Speedy retrieval always depends on a certain amount of raw technology. The Visual Intercept engine is a 32-bit app written in C++, which gets us the maximum possible performance. This is significant - many of our competitors are written in high-level interpretive languages or some proprietary 4GL language . We can create complex, efficient data structures like self-expanding arrays, and target our code precisely at the problem. Our 4GL-based competitors have sacrificed that kind of efficiency, so they're stuck with inherent limitations in their performance speed.

My experience with doing 3-D rendering for Virtus WalkThrough helped a lot in this regard. WalkThrough's strength was efficiency by design; even running it on an average desktop machine, it was usable. Philosophically, I believe in building efficiency into my system, rather than relying on someone else's technology or more powerful hardware or whatever, to power resource-intensive applications.

Beyond the raw speed, though, Visual Intercept is efficient because it minimizes the amount of data to be retrieved by the client program. The GUI segregates incident data into meaningful chunks that are retrieved individually. Rather than dumping all the incident data into a single form, we use a tab-based layout to display the incident data; users have a clear map of the data, but they don't have to look at or retrieve it all at once. The program only has to fetch specific information precisely when you ask for it–if you don't need related source code, for instance, then that information isn't retrieved.

Our project-oriented organization makes it easy for the user to limit his request for information to only those incidents that matter to him. Using Filters, the user can define custom database queries to run on application launch, so he automatically gets a list of those incidents he has to work on, and no more.

By using the fastest retrieval technology, and using that technology to intelligently pull only what's needed, Visual Intercept is optimized for large groups. In a word: it scales.

In actual customer sites, we've seen groups of 50 users on Visual Intercept without a hitch. Some Fortune 500 companies are talking about getting site licenses for over 100 users. Visual Intercept's scaleability has been conclusively established in real-world settings.

Technologically, we are well positioned to port. The Visual Intercept Engine is straight cross-compilable C++ code. The GUI is done in MFC, which also has a port strategy. We used ODBC in relatively simple, straightforward ways, so we wouldn't run into cross-platform issues with it.

If the market demands a cross-platform solution, then we'll do it, or we'll find other companies like Mainsoft or Metrowerks to do it. We're just waiting to see if the demand will warrant the commitment of resources on our part.

Developers are also struggling with how to get geographically dispersed development teams working together in the same incident management system. Many are hoping that the Net will provide an easy way to share incident data long-distance.

So, we don't just want to blindly create the Browser-Base App of the Gods. We want to use the Web for what the Web does best: distribute software for limited, specific tasks to huge numbers of people. Rather than indiscriminately bringing Visual Intercept functions onto the Web, we want to incrementally Web-enable functions one at a time. As an initial step, we are creating a web-based application that lets end-users submit bug-reports, and check up on the status of the reported bugs.

Again, our three-tiered design gives us a tremendous edge. Because Visual Intercept's functionality is contained within an API, independent of the GUI, it's easy to take exactly the feature-set we want to the Web. Gathering up the API classes into an ActiveX object, we then plug straight into a Java-based app. Technologically, Visual Intercept is only two short steps away from Internet enablement.

Still, caution is required when companies start using the Web in this way. Scaleability becomes a much more critical issue when you have potentially thousands of users simultaneously hitting your Visual Intercept database. That's another reason we want to take an incremental approach to the Web, figuring out the issues involved in supporting Web-generated traffic one feature at a time. There's no sense in giving users features that could ultimately overwhelm them.

Another approach is to build database-synching software, letting separate groups use separate databases, and then merge them together on a regular basis. That's something we'd like to do, and the Visual Intercept SDK makes it possible for others to build it as well. Merging incident data is going to take more than just additive merging of databases. To find duplicates and intelligently relate incidents to each other, a human being is going to have to sort through the data. Ultimately, the system administrator needs an intelligent interface to make that task easier and more efficient.

The surprising thing is, everyone is going to like greater accountability. When you're close to finishing a project and there's a million loose ends to tie up, it's a relief to have a to-do list pop up every day and tell you, "Now fix this." It lets the programmer stay on task, instead of fretting about which bug to tackle next. And since end users will be able to plug into the system, the programmer and the manager will know exactly which bugs are of greatest concern to those on the front lines.

Executives, too, will breathe a lot easier when they have more to go on when making release projections. Companies are usually afraid of software projects, and with good reason, because they're hard to understand and they can turn into vast money-pits. Visual Intercept will bring them closer to the process, and take out some of the anxiety.

Incident management is a critical part of client/server's true maturation. The client/server "revolution" is over–now that we've made the switch to three-tiered distributed computing, we are settling into doing the day-to-day implementation. The ability to coordinate large groups of developers makes a very shaky, scary process much more controllable, something businesses will be able to use more confidently and more realistically. Visual Intercept helps the client/server approach push past its shaky beginnings and really get down to work.