Reliably Delivering Software

The concept of design Patterns was brought to the software community by the so called Gang of Four in their seminal work Design Patterns. There are a number of different definitions of the term Pattern, but loosely, its a problem coupled with a solution. For a long time before I'd read this book, I'd considered programming more art then science. That is, I considered programming to be a craft, something learned through experience and example rather then something taught in school. There's the old joke that "real" sciences don't need to have "Science" in the name. Everyone knows that Physics is a Science, people don't need to call it "Physics Science".

With Computer "Science" there are no codified set of rules for designing software. This book, and the concept of patterns in general will go a long way to fix that. Why? Well for a long time, experienced programmers had no way of passing along hard earned experience to other programmers. Each project seemed to reinvent the wheel, over and over again. There didn't seem to be any "rules of thumb".

In the Pattern movement, when you create a Pattern, you describe the problem you were having, and the solution you came up with, and you give both a name. What makes this technique powerful is that people run into the same problems in programming over and over again. A Pattern captures that knowledge in a format that someone can reuse and adapt for their own project. Not only that, but it creates a common terminology that programmers can use to describe problems and their solution. Strange as it may seem to non-programmers, but most engineering discussions between programmers before the Pattern movement involved a lot of handwaving and writing code on the white board.

For an example of a Pattern, follow this link to one of the patterns we've created: The Model-Facade-View-Controller Pattern. We have a page that lists all the patterns we've created here.

Java is a pretty good alternative to C++. However, it has a ways to go before it will be 100% useable for large software projects. Specifically, the user interface toolkits are awful, its dreadfully slow, and there are one or two obscure technical issues to deal with. That said, its a joy to program in. Its missing some of the things that make C++ powerful, but garbage collection makes up for that.

We've written some cool things in Java, despite all this. Follow this link to see the 3D view of a galaxy we did for an online game, as well as an editor that lets you generate cool textures.

99% of the books on Java are crap. We've only found three that were any decent:

Thinking in Java gets my vote as the best book on the details of programming in Java. The author published his book on the web and solicited criticism long before it was published, and that's reallly what makes this book such a gem. You can still download the PDF file for the book at the author's web site. The author's Thinking in C++ is the best book on C++ out there, which is how I found out about his Java book.

For a reference, Java in a Nutshell is great. It has some introductory chapters on Java, but mostly we have this book by our computer while we're programming as a reference to the 1000's of calls in the Java library.

Database Programming with JDBC and Java is a short book that does just one thing: it talks about how to access databases through the JDBC API. If you need to use JDBC, this is the book to get. Otherwise, don't bother.

OOAD is the rather convoluted name people give the various formal software development processes that people are creating. The most intriguing development in this area to date is the Unified Modeling Language. UML is just a fancy name for the fact that all of the process wonks got together with some of the larger companies (HP, IBM), and came up with a standard set of notation for diagrams. Previously there was Booch Notation, Rumbaugh notation, etc. Before, one person used "clouds" one person used rectangles, one person used circles. This meant that the same diagram would mean different things to different people. It was a pretty silly situation, and consequently object diagrams never really caught on.

UML fixes that, as this is the now the official notation of the Object Management Group. What this really means is that most of the programming books you buy will now use a standard notation for their diagrams.

UML is pretty new as the standard was just finished in the end of 1997. Despite that, a number of tools have come out for creating the different types UML diagrams. As a programmer, I often draw sketches for myself and other programmers to describe how objects relate to each other and so I've found these tools to be great. Even better, most of these tools can output source code so that you can design your objects and their relationships, discuss them with your peers, and then output the result. The best tool for creating these diagrams I've found is a program called ObjectPlant on the Macintosh. The primary creators of the UML have their own tool called Rational Rose, and it runs on Windows.

As for the processes that people are creating, we tend to use the level of process appropriate for a project. You don't need a blueprint to build a tool shed, but you can't build a house without one. So if we're writing a "tool shed" program, then a single meeting and a sketch on the white board might be enough. For a "mansion" program, we'll produce a complete formal design document before we actually begin programming.

We've found that the most important part of all of these processes is the "use-case" process. This is where you sit down and envision how the product will be used, document that, and check with your customer to make sure you're building what they need. No matter what the size of the project, we've always found that to be a valuable step. After all, you might build them a tool shed to find they really needed a doghouse.

There are several books on OOAD, I liked Jesse Liberty's two: Beginning OOAD is a good description of the process for a hypothetical program, while his Clouds To Code describes using the process on a real project. I wasn't thrilled with either book, though I liked Clouds to Code better because of its honesty and the fact that it was an actual day-by-day description of what he did during development. Even better, I found out when I went to his web site to download the last "post-mortem" chapter, that he hadn't finished it because his client was "reorganizing." Now that's a book that realistically describes the development process!

Both describe UML a bit, but I read UML Distilled to learn all the ins and outs of UML. The nice thing about UML Distilled is that its also quite practical, and the author freely admits cutting corners occasionally to save time when diagramming a system.

Software development is the hardest thing to manage. This is mainly because when you're developing software, you're trying to invent on schedule. The best thing you can do with software development, is Underpromise and Overdeliver. Yet time and time again I see others in the industry doing the exact opposite; overpromising and under-delivering. Consequently, this has led to disastrous situations throughout the software industry. Basically, we've found that the best thing to do when managing projects is to rigorously define what you need to do, underpromise when its going to be done by and what features its going to have, and deliver either earlier, or with more then you promised.

An interesting side effect of this philosophy is that I find myself frustrated by people in other industries that don't underpromise and overdeliver. For instance, my auto mechanic has a tendency to say he'll be done at 2, when he really won't be done until 4. Now it doesn't actually make any difference to me if he's done at 2 or 4, but if I get a ride over to his shop at 2, and he's not done, I don't want to have to wait there for 2 hours. Then he hurries and doesn't do a good job. If he'd told me 4 to begin with, we both would have been happy.

The other trick when managing software is to never cut corners, and never "hope for the best". I've never had a project where something unexpected didn't happen, so I always expect at least one unexpected thing to happen, and plan accordingly.

We have a separate page that talks about "runaway" software projects, and how we try to avoid them.