eyt*
Sep 08, 2004

Completely Different Worlds...

Have Integrated Development Environments changed the way that software is built? For many developers, it has; yes, still some prefer vi (or have slightly modernized with vim), xemacs, or their favourite editor, but there is no argument to me that many people use and swear by IDEs. Has it always been like this? No.

In The Big Bang Theory of IDEs, Caspar Boekhoudt does a wonderful job at describing how IDEs have advanced throughout the years, since their invention in 1964, but he also points out a short coming of IDE's. While they do pack more bang for the buck, they do not necessarily make developers' lives easier, more productive, and make our products more solid. He argues that IDEs are presently packed with interfaces to external tools and make everything look easy to use, but in reality, you still need to know how to use those tools.

Even with Caspar's arguments, IDEs still have improved the development to some extent for many developers. In many cases, this is habit and preference, and so long that a developer is able to produce, the issue of what they use to produce is not as important (so long that it is legal).

It is interesting to see the parallels between IDE's and modeling, especially in light of Microsoft-base Modeling, scheduled for Visual Studio 2005. As Matthew Schmidt mentions in a recent JavaLobby newsletter, like it or not, some developers like models. In his case, he is referring to JDocs.com, a repository of JavaDocs for various APIs that, amongst other things, features a wiki-like comment system, allowing developers to share their experience with the API.

As I have mentioned many times before, a huge problem with models is keeping their in sync with the source code. A recent survey that I partook in asked if modeling was used, and if so, how were bugs in the system fixed; where the bugs fixed in the model then exported into the code, fixed in the code and imported into the model, or was the model only the starting point. This genre of question really highlights the problem with current generation modeling tools, since they are separate from the source code.

This separation of models and source code, coupled with the painful experience of reverse engineering source code has created a stigma in many developers against models. A portion of these developers believe that models are only useful for design or communication, such as Craig Larman suggests, and this vision is really based on the lack of tool integration. Some modeling vendors have attempted to integration portions of their tools into IDEs, and in most of the cases that I have seen, this integration was still separate tools bounded in a single user interface, similar to Caspar's comments above. Such tools have not really kept in mind the goals of a software developer.

Unfortunately, many developers are so stigmatized from this experience that they cannot see the actual benefit from the models, stating that the models are great for designing a feature, but once designed, they argue, what is the use of the model? Artifacts such as models are great elements for the Project Workbook, as prescribed by Frederick Brooks' classic The Mythical Man Month (or a plog by modern terms).

The problem with the assumption that the model is only good for designing software is that it assumes that the software never evolves in any way. For most projects, this is simply not the case. While it is true that many developers can remember the basic structure of something they developed sometime ago, it still takes a little time to get back into it and to understand exactly what the proper fix is. A model is an excellent way to quickly see the classes involved, the interaction of classes, states of a class, software deployment, etc.

But this last paragraph assumes that the author of the package is actually the maintainer. This is also not always a valid assumption, and in light of this, the new developer must quickly understand your design. Again, a model is ideal for this purpose, as the saying goes, a picture is worth a thousand words. Without a model, developers will tend to think that segments of code are wrong, inefficient, and require rewriting. This can also be the truth with the model, as Craig states, the ability to create a model should not be confused with the ability to create solid software and Caspar also states the experience is required to use these tools effectively.

Of course, the present problem with this is that the tools are not intuitive to keep the source code and models synchronized. Microsoft Visual Studio 2005 aims to keep the model and source code seamlessly synchronized, and there are ample other vendors out there also working towards this.

When programming in assembly became too complex, languages were created to minimize the complexity, and this has repeated a number of times, but we are again at a point where the complexity of software is far too great for humans to complex understand inside out, and a higher level of abstraction is required, and models are a great way to handle complexity, since they can be partitioned just to the right amount of detail you need. It is an excellent way to dig down into a project, and when a product can keep the code and model synchronized, modeling will not seem so separate and disconnected.

Filed In

Navigation

eyt*