The Company

Merant is the company that makes PVCS. During the time I worked there, PVCS was the number one software configuration management (SCM) solution on the market. SCM refers to the collection of tasks that allows development teams to archive versions of source files being developed, automate and manage the "build process" so that product releases can be safely duplicated and tested for deployment and much more. Configuration Management is absoutely critical to succesful software development. That importance grows as the number of developers on a project increases.

The Challenge

Programming, as an activity, has historically been all over the board in terms of best-practices and organization. Development happens in circumstances ranging from the solitary coder alone at his desk, to coordinated teams of hundreds working in remote locations all building a single product that will be released. Both organizations face the challenge of safely and productively buidling software.

The lone developer, without any version control tool, will simply overwrite his work with new changes. A slightly more sophisticated developer, the majority in fact, archive "versions" of their software using zip (or tar or stuffit) archives, floppy disks, tape and so on. For that developer, recreating a release of a package from a year earlier is an enormously tedious, manual process. Using version control software, even the open source CVS package, can handle that very neatly. In projects that I do solo, CVS helps me take more risks, compare attempts and pick best solutions, as I build software.

For software development teams, independent vendors or internal corporate teams, coordinating the development effort is critical just to get the application built! More than anything, teams have a need for tools to keep developers from stomping one anothers code. Configuration Management tools, including PVCS, can play "traffic cop", allowing only one developer to change a given software module, and locking out other developers until that first developer has checked their work back into the tool.

Support Role

When I first came to what was then Intersolv, I had just finished teaching myself C++. I'd just read Grady Booch's Object Oriented Analysis and Design with Applications. I was excited to go to work building code, using these ideas. Leveraging the creation of a product (PVCS) that I already saw as extremely valuable. Indeed, I was a true fan of their "Sage Professional Editor" product.

Unfortunately, I received the same disillusionment many of the excited software development grads were receiving in the early 1990's. Practice was lagging far behind theory. PVCS was built in plain C, function calls, pointers, miles upon miles of endless spaghetti code. I couldn't bring myself to join the development team. I still believed in the product, though, so I joined the support staff.

Support work, at Intersolv, was considerably more interesting than typical software support. The user community for PVCS was, understandably, almost entirely software developers. Real practitioners of this art that I'd been studying so ardently. Many really saw the value of bringing some automation and reliability to their development process. Others had configuration management thrust on them and saw it as some bizarre torture they were forced to endure in order to build the software they loved building. In either case, I enjoyed becoming the expert that could teach them all about installing, configuring and using PVCS to it's utmost capabilities. I documented best practices for configuration management in the enterprise and the small development shop. I wrote articles for several software journals and Intersolv's own newsletter. It was a fun time.

DTK Support Role

Shortly after mastering the product in the Support group, I began to get antsy for more challenges. I've always been fascinated by development languages and the effect that a development tool has on the project being developed. If the developers start out, from concept to design, knowing that Smalltalk would be the implementation language, how will the product, the timeline, the quality, be affected? How would the results differ from an identical project that would be built in VisualBasic?

Intersolv had a product, the PCVS Developers Toolkit (DTK), that was almost completely unsupported at the time. The DTK allowed developers to embed version control functionlity into their applications. This capability was used in two places, primarily:

• adding functionality to a variety of projects like legal document tracking and medical records
• integrating configuration management into development tools like Microsoft's Visual Studio, Borland's Delphi and others.

Borland's Paradox Enterprise and Delphi Enterise Developer featured version control via the PVCS DTK code I helped them write. Along the way I got to build examples in Delphi that got me some familiarity with their implementation of Object Pascal.

Digitalk's Smalltalk/V had an add-on product, Team/V, that was based on the PVCS DTK. I helped them communicate with the Windows DLL using the smalltalk/v dll interface. I built and tested the version control interface for multiple users. This is actually quite a challenge, since Smalltalk development progresses by enhancing and manipulating an 'image', a binary representation, a snapshot of the state of the Smalltalk environment the developer is working in at a give time. Applying file-oriented version control to that kind development tool proved to be a challenge. Applying version control to multi-developer teams working in their images simultaneously was even more so.

That product effort was the best experience I enjoyed at Intersolv. It introduced me to the Smalltalk development concepts which still form some of the stronger themes in my development thinking. The code browser for organizing a class hierarchy. Dynamic compilation and direct manipulation of running code and more. Not to mention the truest implementation of object oriented programming.

Training Role

Those two experiences, supporting development groups in the implementation and use of PVCS for configuration management, and the integration of PVCS into specific development environments for entire communities of developers, led to development organizations seeking me out for training.

Development managers came looking for instruction in how to make the best use of configuration management tools in their organizations. What I found, however, was that in most cases the groundwork for good development had never been laid.

In a medium sized development team, say eight developers and two QA (test) engineers, someone will have been tasked with "architecting" the application. This person may or may not have had any experience with this role, often they're just the senior person in the group. Depending on the design choices made by the selected architect, a project could get hopelessly dead-locked around a few key software modules that, when locked by one developer, locked everyone else out of getting their work done.

In these organizations, I found myself giving more and more design and analysis input, as I tried to help improve the configuration management solution I was there to provide. This experience really bolstered my confidence in my ability to architect solutions for companies. All the more so since my customers during this phase of my time at Intersolv included firms like Lotus, General Motors, Kodak and the CIA. If they made mistakes in their development efforts, and if I could propose effective solutions, I knew I truly could build software.

Much of my over-inflated self-confidence stems from these experiences.