This chapter expresses my personal opinions based on my experiences writing software in a variety of organizations with a wide variety of team sizes and organizations. I started writing after the ”dot-com bust”. In my personal experience the ”dot com” era helps to demarcate three eras of software development:

• The pre-dot-com era was characterized by moderate spending for software development and a real interest in doing software development ”right” using the software development methodology that was in current vogue.
• The dot-com period era was characterized by large and enthusiastic spending for software development and less emphasis on proper software development. I witnessed more of a frenzy to get products to market while that market was hot.
• The post-dot-com era is characterized by conservative spending for software development, uncertainty in the future of IT spending, and pressure to reduce IT salaries in developed countries caused by highly skilled workers in countries with very low cost of living. The key strategy in this new era is increased productivity in all areas of software development.

Sadly, I would argue that we have made negative progress! We need to get back to the values we used before the dot-com era while realizing that IT expenditures in today’s economy must be made efficiently.

I have been programming since high school (for me, that is the mid 1960’s) and professionally programming since 1973. Roughly, my experience working on medium and large software projects falls in three categories:

• Under designed either because of a rush to get something working or general short sightedness, little time was spent on design, a quick hack got something working, and everyone was happy except for the people who had to maintain the system.
• Good balance between design time and implementation time the ”just right combination”!
• Over design attempt to write the ”perfect” design, not realizing that a good design methodology depends on staged prototypes that affect the design process.

As you might guess, I prefer category 2.

It is difficult to know how to plan software development. If, for example, you need to convert a structured text data source into a form that can be imported into a relational database, then it is not likely that the code to do this conversion will be reused. If we know that the results of a small project will not be reused (i.e., a ”one-shot” project), there are obvious economies that we can make use of. For example:

• Do not bother documenting the software.
• Do not bother commenting the software for the benefit of future programmers who must maintain it.
• Worry about code correctness, not efficiency (i.e., memory footprint, runtime efficiency).

This book is really not about ”one-shot” coding projects, but we need to define the margins of our discussion of planning software development and using the correct design process. At the other end of the spectrum of software development, we might consider systems for which software failure would endanger lives (e.g., embedded medical equipment, aircraft control software, etc.) This book is also not about designing and implementing this class of software.

This book tries to take a Buddhist ”middle of the road” approach: we want to create and use software development planning and design habits for small, medium and large size projects that will be reused and must be efficiently maintained.

So what is wrong with current design and software development methodologies?

I think that to some extent, fault lies with industry leaders like Sun and Microsoft.

Sun’s Java platform certainly has a lot going for it, especially developer loyalty. However, instead of placing resources to solve problems like too large of a memory footprint, runtime efficiency, and poor looking GUI applications, Sun seems too caught up in developing and releasing too many new APIs. One of the best additions to the Java platform has been the Hotspot just-in-time compiler, but that technology was purchased from a Smalltalk vendor (yes, it had been originally developed for a different platform!).

Java is an incredible platform for developing server side or web based applications. Still, many in the developer community are disappointed by the overall design and complexity of Enterprise Java Beans (EJBs). We will spend time discussing alternatives to using EJBs in this book.

Microsoft, of course, is not without their problems. Most of these problems are tied to legacy support for COM, so-called ”DLL hell” (i.e., earlier versions of Windows that allowed developers to add DLLs to the system instead of ”green installs” where all DLLs coexisted with specific applications. As a programmer, I have always disliked automatically generated code that is unreadable to most human beings. I do not like so called ”wizards” that generate unreadable code.

I spent a fair amount of time with VisualStudio.net before I started writing my published book which covered Java J2EE technologies. I wanted to ”scope out the competition”. Microsoft’s .Net does have a lot going for it. It makes generating web applications easy and provides a uniform way to make both GUI and web based user interfaces for applications. Time will tell how .Net does in the market place and how it is viewed on technical merits.

Both Sun and Microsoft are corporations that have a legal obligation to their shareholders to make every attempt to be profitable. It is regrettable, but understandable that public companies need to worry more about the ”bottom line” than uniformly creating software tools to support lean/mean/economical software development.

Still, for many of the types of problems that we need to design and code for can be effectively solved with inexpensive or free software tools that certainly meet my lean/mean/economical criteria. For example:

• Java on the server, using JSP, JavaBeans, and JDBC database connections.
• Microsoft .Net for both Windows forms and web forms applications.
• Ruby on Rails applications.
• Python for writing utility scripts and server side web programming.
• Smalltalk for server side Smalltalk servlet programming and general application development.

These five ”platforms” are inexpensive or free but do have a cost for training: the Java, .Net, and Smalltalk class libraries all have a long learning curve. Knowing the syntax and general use patterns for an object oriented language is of limited use if you have not also mastered the standard class libraries for that language.

So, in this book, we will look at my own approach to solving current software development problems. My approach involves using simple tools that are well understood by you the developer, and use ”just the right mix” of up front design followed by staged implementations that positively affect the design process. When we build our software projects, we should strive to write code that works, is easily maintained, and is economical to develop and maintain.