The Sad Truth

The premise of my first book, Developing Applications with Visual Basic and UML, was that most software projects undertaken today don't come close to meeting their original goals or their estimated completion dates. My reasoning was that most project teams have a somewhat cavalier attitude toward project planning and software process. In addition, most projects have little in the way of analysis and design artifacts to show how they got where they are. That is, projects traditionally lack traceability. This holds true for applications built in any language—Java included.

My professional career with computers began after college in 1979, when I began working on large IBM mainframe applications using technologies such as IMS and later DB2, what many people today would call legacy applications. However, I prefer the terms heritage or senior to legacy.

Not only did I get to work with some really great tools and super sharp people, but I also learned the value of planning a project and establishing a clear architecture and design of the target application. I saw this approach pay back in a big way by establishing a clear line of communication for the project team. But more importantly, it set in place the stepping-stones for completing a successful project.

In 1990 I worked on a first-generation client/server application using SmallTalk on the OS/2 platform. This was the start of a new career path for me, and I was shocked by the “process” used to build “production” applications in the client/server environment. The planning was sketchy, as was the delivery of analysis and design artifacts (something that showed why we built what we built).

This pattern of “shooting from the hip” software development continued with my use of PowerBuilder, Visual Basic, and later Java. The applications delivered with these products worked, but they were fragile. Today many applications wear the client/server or distributed moniker when they are just as much a legacy as their mainframe counterparts, if not more so. Even worse, many of these become legacy applications a month or two after they go into production. The fault isn't with the tool or the language, but with the lack of a sound process model and methodology to ensure that what is built is what the users actually want and that what is designed doesn't fall apart the first time it is changed.

Most organizations today ship their staff off to a one-week Java class and expect miracles on the first application. Take this message to heart: The fact that you know Java doesn't mean you will necessarily build sound object-oriented applications. If you don't have a sound process in place and a very firm footing in sound object-oriented design concepts, your application will become a Neanderthal waiting in line for extinction.

Slowly I began to apply my own opinions about process and methodology to the applications built in these environments. This worked quite well. The applications were more resilient and accepted change more easily, and the users typically had smiles on their faces.

This book combines all of my experience building distributed applications with UML, which I feel is the best artifact repository for documenting the analysis and design of an application today. I would also like to think that my approach to this topic is exciting because I use a real example throughout the book utilizing various Java technologies and tools to demonstrate how you might approach solving some of your own problems.