|
The complexity of information increases faster than our ability to organize and use it to increase efficiency and profit. We have lived through the dot-com hype and crash and most developers now have a more realistic view of the benefits versus costs of software systems. As the complexity of information increases so does the software required to automate information processing.
In today’s economy, the savvy software developer asked herself ”how can I earn money for my company”, not ”what technology toys do I want to play with today”. There must be a reasonable balance between a focus on technology and a focus on business processes and problem solving.
Although this book is about Software Development, it is also about working in the IT field, dealing with competition from very low cost knowledge workers in countries with very low cost of livings, etc. Increasingly, ”just coding in Java” is not enough: this book is based on my own experiences in moving ”up the food chain” by both developing skills as a software architect and developing a passion for niche technologies (small market but little competition) like artificial intelligence.
In the last few decades there have been many software design and development methods that have all promised the reduction of software costs. Most software developers have been involved with projects that used (in historical order) the waterfall method, structured programming, object oriented programming, various object modeling languages, Unified Modeling Language (UML), extreme programming, and test driven programming. Most developers will tell you that ”their mileage varied” when discussing the utility and cost effectiveness of various software development methodologies.
A common complaint with methodologies that promote formal up front design is that the design process and documents are not kept up to date during software development. Modern design tools do promote ”round trip” engineering to keep model design documents and code in sync but many projects still ignore the maintenance of design documents in the rush to get projects complete.
One of the great success stories in software engineering has been the series of design patterns books. These books codify and describe the designs for common programming problems. Developers reuse a proven design without having had to go through the ”normal” process of making mistakes and then learning from these mistakes.
In this book we will look briefly at patterns that make sense in the reality of today’s economy. You should search for ”design patterns” or purchase one of the design patterns books for more information. These patterns deal with and answer such questions:
This book is a hybrid, combining new ideas for a lightweight approach to using UML for design and discussing in cookbook fashion design recipes for a few problems that modern developers face.
The goal of this book is to encourage the reader to step back and reevaluate how they design and write software systems. The great computer scientist Edsger Dijkstra, who died recently, once said ”Computer science is as much about computers as astronomy is about telescopes.” That is not simply a glib remark! Talk to successful software designers and developers and they will probably tell you that they do their best work in design and problem solving away from their computer, often taking a walk with colleagues or sitting outside with a pad of paper.
So, the reader is expected to think about the entire software design and implementation process in the first part of this book and reevaluate how they do their work. The second part of the book contains case studies for six design problems.
The computer industry in the U.S. and in other countries has seen a reduction of jobs and in the start of new projects in the last few years. No one can predict the future economy (well, economists do try) but there is one certain thing: computer scientists must continually educate themselves as new technologies capture the interest of the industry and the business world. I want to help you, the reader, not by concentrating on the details of the newest technologies but by reevaluating how you work and the meaning and means to productivity gains.
This book is for (mostly) Java software developers who worry about the economy and their careers and want to proactively do something about their fears by improving the way they design and write software.
The only assumption that I make regarding the reader’s preferred programming language is that it is object oriented. That said this book is written primarily for Java developers but it will also hopefully also useful for developers using different languages and platforms.
Using UML is a key part of this book. For Java, I recommend the Poseidon UML editor. A free community edition is available, with professional editions also available with added features. You can download Poseidon at www.gentleware.com. In addition to using a specific UML tool, I also like to use OmniGraffle running under Mac OS X to create UML diagrams.
I believe that selecting a programming language for a project is important, but less important than proper design. I use a wide range of programming languages (in order of decreasing use): Java, Common Lisp, Python, Smalltalk, C++, C#, PHP, and Perl. For me, the selection of a programming language is driven by cost considerations: which language allows me to design and implement a system that will be maintainable, for the lowest cost. We will see later in the book that choosing the right infrastructure tools is a similar and related process to programming language selection. For most server side development project, I find that the Java platform makes the most sense because of the wealth of available platform tools (e.g., Tomcat and JBoss) and available libraries.
For my own work, I develop in Java, Common Lisp, and Ruby - choosing the best language for any given task.
I would like to thank the following readers who have provided ideas for design in this book: ¡none so far¿.
I would also like to thank the following people who pointed out typographical errors in the manuscript: Karsten Voges