Fine Tuning the Development Process: An Electronic Notebook

Introduction

This is the thirty-ninth installment in a series of articles about fundamental object-oriented (O-O) concepts and related object-oriented technologies. The material presented in these articles is based on material from the second edition of my book, The Object-Oriented Thought Process, 2nd edition. The Object-Oriented Thought Process is intended for anyone who needs to understand basic object-oriented concepts and technologies before jumping directly into the code. Click here to start at the beginning of the series.

In keeping with the code examples used in the previous articles, Java will be the language used to implement the concepts in code. One of the reasons that I like to use Java is because you can download the Java compiler for personal use at the Sun Microsystems Web site http://java.sun.com/. You can download the standard edition, J2SE 5.0, at http://java.sun.com/j2se/1.5.0/download.jsp to compile and execute these applications. I often reference the Java J2SE 5.0 API documentation and I recommend that you explore the Java API further. Code listings are provided for all examples in this article as well as figures and output (when appropriate). See the first article in this series for detailed descriptions for compiling and running all the code examples (http://www.developer.com/design/article.php/3304881).

The code examples in this series are meant to be a hands-on experience. There are many code listings and figures of the output produced from these code examples. Please boot up your computer and run these exercises as you read through the text.

For the past several months, you have been exploring various issues regarding object integrity, security, and performance. Although many of the issues pertaining to object integrity, security and performance revolve around actual code; one area that is often shortchanged is the process itself.

Although taking shortcuts to circumvent the process is all too evident in the work environment, it is perhaps even more evident in the learning process. When learning new concepts, whether in a professional or academic environment, it is all too easy to ignore the fundamental process in the desire to get right to the hands-on experience—which, in most cases, is more fun.

In this month's article, I change directions a bit and, rather than tackling a new coding concept, you will explore an idea that reinforces sound development practices and is intended to improve the integrity of your code.

Engineering Notebook

It is often interesting, as well as informative, to delve into some of the historical aspects of topics that we use on a daily basis. For example, most people use a calculator on a regular basis. However, some people may not be aware of the specific technologies that were used prior to the more familiar ones that we use today. Whereas many of us may know what a slide rule is, many others have never even held one in their hands.

You can extend this thread to software development. In my programming classes, I often bring 'props' to class for the students to view—such as punch cards, flowchart templates, and so forth. This provides a good historical context for the students who can perhaps better appreciate the advantages of the more recent technological developments. Although newer technologies often supplant older ones, it is often the case that the underlying concepts of older technologies are directly incorporated into the newer ones.

This scenario applies to the learning process as well. Although many programming students, whether in corporate training or in the academic environment, focus primarily on the electronic nature of code and other business information, they often do not realize that they should be organizing their personal information in the same way.

From Hardware to Software

One of the most interesting, as well as most challenging, aspects of being a software developer is that you never really know what type of industry you will be working in from job to job. After spending my entire career writing software, I joined an engineering company that manufactured electronic equipment. Moving from a purely software shop to a mostly hardware environment was, to say the least, an education. I use the term 'mostly hardware shop' because at this time (the early 90s) software was beginning to permeate all industries. The days of hardware and software being totally separate were in the past.

However, for many of the engineers (mechanical, electrical, or software), their careers were often based solely on one of these disciplines. In fact, I was the first software engineer hired into a very large department of mechanical and electrical engineers. I was immediately fascinated by the work culture of my new colleagues.

One of the first things I noticed was that most of the engineers carried around oversized notebooks. In fact, these notebooks were strewn across their desks as well as their lab workspaces. I saw them constantly scribbling in these notebooks while referencing them continuously. The engineers simply called them Engineering Notebooks.

These oversized notebooks were not easy to purchase. In fact, the only way to get one was to order it through a catalog—the Internet was not yet an option. Figure 1 shows what one of these notebooks looks like—this is just one incarnation of the Engineering Notebook; there are, no doubt, many others.