Sep 14, 2004

The Tools of Software Development...

A little while ago, Andrew Koenig and Barbara E. Moo wrote an article in C++ Users Journal discussing some of the parallels between house construction and software engineering, as they were doing some renovations. One of the differences they highlighted and that others have also highlighted is how construction works own their own tools and software developers, well, our tools are different, to an extent.

The major difference is with tool sharing. When a carpenter does not have a particular tool, they can generally borrow the said tool from another craftsman, since the tools are easily portable and shared. When a software developer does not have a particular tool, however, sharing another developer's tool is not always easy. For small tools like scripts, these can generally be copied or shared, and other tools need to be installed, presuming that it can be installed on your workstation workstation. In the latter category, licenses sometimes need to be obtained.

This can be very painful, especially with floating licenses of popular software. Imagine a world where software developers were like carpenters, and went to work with their own tools; could this approach work?

I do not think out tools are mature enough yet to do this, and this is one of the goals behind Eugene Eric Kim's A Manifesto for Collaborative Tools. By this, I mean that the interoperability of the tools is not there yet. Take, for instance, UML tools; the standard interchange format for UML is XMI, and most UML tools available support one version or another of XMI. But even when your applications understand the same versions of XMI, the interoperability of the products really depends on their interpretation of the standards; for example, I saw an XMI file generated by Visual Paradigm for UML's C++ reverse-engineering module that generated a document that was not a valid XML file. Furthermore, for some elements in the XMI, Visual Paradigm had put the visibility attribute to none, however, according to the DTD, the only allowed values for this attribute are private, protected, and public. Only once these issues were resolved was I able to import this model into Poseidon. It is for reasons like these that products like XMI exist, but this is unfortunate.

In addition to inconsistencies such as the examples aforementioned, it is possible for some features of a tool to not directly map into the interchange format. In cases like these, the vendor has two choices: do not export those features, or export them in a non-compatible fashion. Depending on the feature, not exporting the feature may go unnoticed, but it could also be a main reason for using the product. In cases like these, this must be documented clearly. But extending a standard interchange format that prevents other tools from accepting the file is obviously not a good idea. These decisions, coupled with what services the tools provide, directly effect how a piece of work in one tool will look in another tool, therefore, interoperability is rarely guaranteed.

As another example, if we consider IDEs, one thing that IDEs do is generally create some type of project file. When all developers are using the same IDE, it is very easy to stay in sync with the team, since when you update your view, you can immediately use the project file that is in the view. However, if you were using two different IDEs to build the same source code, it is possible that the additions of files, changes of settings, and differences in compiler could go unnoticed, incompatible, or new build issues could occur. Please note, however, that using different tools is different than targeting different environments. More to the point, if you are targeting multiple compilers, then you must build each branch on each compiler prior to merging; but supporting various developer's preferences is a non-problem, as the released software will only be built by one of those configurations, and therefore, must only work on that one configuration.

Another issue with supporting multiple development tools for a single target environment is the question of support. When a problem occurs or a developer is unsure how to use a particular feature, talking with the team members will likely help get an answer, instead of a “why don't you just use my tool.” Also a point in this is purchasing tools. You could not simply purchase X seats of a tool without ensuring that it is compatible with most developer's environments. In the event that it is not, you either have to select another vendor or purchase a few copies of this and a few of that, which will eventually end up with the same problem that it started with.

Sharing a UML tool, for instance, is more complicated than sharing a hammer. In addition to the installation and licensing issues, the time to get comfortable within the tool can be more time consuming than learning how to use another drill. In the instance of having no standard development tools, however, developers will generally procure their own (hopefully legally), and what will generally occur is that many different development environments will be created. But until Eric Eugene Kim's vision is realized, true collaboration will suffer.

Filed In