• Hitting ‘Run’ and waiting a few seconds,
• to hitting ‘Run and deploy’ in my IDE and waiting about 20-30 seconds,
• to executing a ant script, restarting the application server and waiting 5 minutes
• to compiling a class file, uploading the class and accompanied libraries using a cumbersome webinterface and then executing a PLSQL script to run that class, wasting in total time amount 15 minutes (yes, that was a a very big and professional company)
  

In my opinion, the programmer is productive when he either codes, or when he tests his codes. Any time spent on waiting or performing some troublesome actions like accessing a web interface is pure waste. In short the above time ranging from a few seconds to 15 minutes is dead time.

Of course all that time wasted not only frustrates developers, it’ll cost quite some time and thus money. Now how can you limit that dead time, that is wasted by developers? One way is your have your developers write perfect code at once. Of course that’s not very realistic. Recently I found a very nice tool to limit that dead time, when you develop Java software: JRebel. What does that mean for you as java-developer:
JRebel runs as a software agent within your virtual machine, that in turn runs your application server. What JRebel does, is taking over the class-loader.
You can specify the output directories of your IDE (target/classes, /bin, etc.). Now whenever you make a change in your code, IDE’s like Eclipse can compile that code into a new class file in the output directory. JRebel will automatically detect the changed class file. Thus no waste! Since JRebel plugs into the VM, it’ll work with virtually any application server.

Every chapter goes on specific part of programming, amongst others: using meaning full names, how to write good, consise and easy-to-understand functions, writing good comments, writing good unit tests, and having a good class design. A lot of content I already knew or was at least aware of, either intuitively through experience or from other sources. However, that didn’t made reading it any less usuful, the book does very well on explaining why and offering good arguments, just to convince other people. The book also questions a lot of common practices, I did not think of before.


I’ll pick some chapters to explain more in detail the content. First chapter goes into importance of good naming. Amongst others, variable should have meaning full names, and one letter variables like j or h should be used only for simple loop iteration. Class names should correspond to domain words like Customer, WikiPage or AddressParser. Postfixes like Info (AccountInfo) or prefixes like I (ICustomer) just clutter up and don’t add anything. Same goes for prefixed variable names like m_dsc or int_ordernum. Function names should be verbs like addAccount or deletePage.
Another chapter goes on a often mis-understood or underestimated subject: writing good comments. One point the auther made is to limit the amount of generated comments. IDE-generated comments containing lots of @param, @return tags, etc., just clutter up your code while not adding information: if you use clear names, you don’t need to explain each parameter. Worse, they increase the change that of introducing ‘lies’: comments that do not corrrespond with the code the’re commenting.

Allthough the title of the book suggests it’s about programming in general, the book is slightly targeted to Java-programming. All code-samples are Java code, and some times the book refers to Java standards (like the Bean standard). C# developers could benefit from the book as well, as well as developers in similar languages, allthough some code samples could be harder to understand. Programmers in languages like Haskell, XSLT, Lisp would benifit less of the book.


I could go on, but I’d just recommend you to read the book if you’re a programmer yourself or have to manage programmers directly!

• Encapsulate database access, using Data Access Objects so we’re not tied to one or another database
• Use Model View Controller pattern, so we can change the view logic easily without having to change the entire software.
• Use Facade beans and Remote Beans so we can separate our application server in a frontend-server and business-logic server.
• Know the book of GoF by heart and use their patterns, so our code is good.

However that’s all wrong! The principles are good, when applied correctly. However the reasons are all wrong resulting mediocre software. If in any project changing database is from for example from MySQL to Oracle or changing view-layer from JSF to GWT is a possibility, then that software-project is very bad managed. The ability to change a product shouldn’t be the reason. And if people think they can have their software be more robust are perform better by setting up an extra business-logic server, they’ll be disappointed.

Because people often use the wrong reasons, a lot of code is overly complicated, badly performing and highly unmaintainable. You known something is wrong if you have to wade to a lot of interfaces, Impl classes, XML-configuration files just to known what a piece of code is doing

Naturally the principles are good, however, the goal is totally different.  The reason for all of the principles should be: program correctly functioning code that can be adapted easily now or in the future.
Design patterns isn’t a bible

Known that any book on design patters shouldn’t be used as a bible. Wrongly applied design patterns produce terrible code. The book of GoF was a great book because they (Gamma et al.) introduced the concept of design patterns and gave a list of good design patterns for C++ and Smalltalk. Many of the design patterns are relevant, but many are also not.

Design Patterns
Erich Gamma & Craig Larman

Most important contribution of the book, is the notion of design patterns. They introduces common words, a name, like Data Access Object, Visitor, Singleton to programming constructs. Because they gave name to certain programmings patterns, people can talk about them and understand each others code. Similar like architects use various patterns to design houses, office buildings, public buildings or monuments. The origin of design patterns was a book about architecture:

The Timeless Way of Building
Christopher Alexander

There are endless design patterns besides the one listed in Design Patterns: Elements of Reusable design. Every programming language, framework and software project and application has its own patterns. Recognize patterns, give them a name if they haven’t got one. Make sure the patterns and the naming are known within the company, organization or all of the users of a framework. That way, the code will be easily to grasp for anyone who has modify or extend the software, because of common naming and usage.

Great coder

Read who a  great hacker is, how to become better programmer read what you can do to be a better coder. The greatest cause why software development is so expensive and costly, is because there’s enough emphasis within many organisations on writing good code.