Sponsored Link •
This final installment of Design Techniques gives a brief history of the column, tracing its development and maturation, a topical index of the column's back issues, links to related discussion forum topics, and a hint of what's to come.
After 14 months of writing the Design Techniques column, the time has come for me to bring the column to a close. I'm saying farewell -- for a while.
In this final installment of Design Techniques, I discuss what I aimed to accomplish with this column and with my upcoming book based on this material, Flexible Java. I discuss the software development process, software quality, and what role the guidelines and idioms presented in this column can play in helping achieve quality. I give links to all of the previous articles that made up this column, as well as to related discussion-forum topics. Finally, I look ahead to the future.
How 'Design Techniques' got started
In the fall of 1997, having finished my book Inside the Java Virtual Machine, I brought my first JavaWorld column -- Under the Hood -- to a close. I had spent a year and a half immersed in the Java virtual machine, and wanted to turn my attention to a new writing project. For my new project, I decided to combine what I knew about Java with what I knew about good software development practices in general. I wanted to try and capture whatever it is that makes software "good" from the programmer's perspective, apply it to Java, and put it all down in a book.
Although my goal was to help programmers be successful in their Java-based software projects, I didn't want to try and invent a methodology -- a complete theory of how best to manage a software project. Methodologies are difficult to define, in my opinion, because the "best" way to manage a project depends so much on the particular project and the people involved in it. It is hard to generalize, to define a methodology that is universally useful. Sometimes, if you are working by yourself and the project is small, a quick hack is the best way to go. You start coding and can effectively design as you code. The more people who become involved in the project, however, the more important it is to have a formal methodology or process to follow. Nevertheless, I had no interest in attempting to add another methodology to the many that already existed. I wanted to aim my writing project at a smaller target.
My area of interest, and my area of expertise, was writing "good" code and developing "good" designs. I wanted to write a Java book somewhat akin to Kent Beck's Smalltalk Best Practice Patterns and Scott Meyer's Effective C++ -- in other words, a book of guidelines and idioms that could help programmers to make "good" Java-based software.
In addition, I wanted to write a bit about what "good" means in the context of software. Programmers generally can recognize good code or a good design when they see it, but what quality or qualities must a piece of code or a design have to be "good"? I hoped to address this question in my writing project as well.
The Design Techniques column arose from my desire to get the material out in the light of day so that I could get feedback from the Java community as I wrote. Feedback was important to me because I felt that programming guidelines, rather than being chipped into stone by some so-called guru working alone on a mountaintop, should fall out of a discussion among the people who actually have to work with one another's code. Through the Design Techniques column, I wanted to lead a discussion about Java design; to facilitate the discussion, I created a discussion forum on my Web site. (See the section Flexible Java Forum for links to all the discussion forum topics.)
Although a few relevant topics remain that I haven't yet covered in the Design Techniques column, the time has come for me to turn my attention to actually writing the book, Flexible Java. I'll be publishing the text of the book-in-progress on my Web site, artima.com, so you can follow along as I go. I'll also keep the discussion forum open, and I encourage any feedback you may have to offer. If you want to receive periodic updates of my progress, you can join my mailing list. (See Resources for links to all of these things.)