The Pragmatic Programmer / Tip 7

Eliminate Effects between Unrelated Things
Design components that are self-contained, independent, and have a single, well-defined purpose.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 6

DRY - Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 5

Critically Analyze what You Read and Hear
Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 4

Make Quality a Requirements Issue
Involve your users in determining the project's real quality requirements.

More at the pragmatic programmer list of tips.

Origins Of The Spring Framework

The Spring Framework has gained a lot of momentum in the last one or two years. When I first heard about it back in 2004, I hastily appraised it as just another J2EE framework. The J2EE stack in general had been quite OK for me, and while I did not necessarily like EJBs, I kind of accepted them the way they were (after all, not worse than COM+ components ;-) ). So I was reluctant to jump on what looked like the next bandwagon of technology hype. Some comments from luminaries such as Don Box and Ted Neward seemed to support my ad-hoc assumption (see Rod Johnson's reply).

But when I finally found the time to dig a little bit more into Spring, I noticed it included several very appealing approaches. To sum it up in two sentences, Spring is a non-invasive Java infrastructure framework complementing J2EE (but not necessarily bound to J2EE exclusively). Architecturally based on the Inversion-Of-Control pattern (AKA Dependency Injection), it provides developers with an easy-to-understand programming model (based on POJOs, as opposed to EJBs for example). Dependency injection opens a whole range of possibilities, such a lose coupling, unit testing, declarative transactions and AOP in general. For more details, you might want to have a look at the article "Introduction to the Spring Framework".

Rod Johnson of course is the original creator of Spring, and what I didn't know before is that all of this dates back to some web framework components he introduced in his 2002 book "Expert One-on-One J2EE Design and Development". Several readers then convinced him to open-source his framework, and went to work on it under its new label "Spring Framework". I actually had "Expert One-on-One J2EE Design and Development" at home for a year or so not knowing that it already described back then what Spring is all about today.

As another side note, one of Spring's main contributors, namely Juergen Hoeller, used to study computer science at the University of Linz, Austria at the same time as I did. He is Spring lead developer today, and co-founded Interface21, a Spring consulting company, together with Rod Johnson. Congratulations guys, great job!

Scott McNealy Resigns, Jonathan Schwartz New Sun CEO

Top news of the day: Scott McNealy resigned as Sun Microsystem's CEO after spending 22 years at the company's top position. Sun's board of directors chose Jonathan Schwartz as his successor.

The Pragmatic Programmer / Tip 3

Be a Catalyst for Change
You can't force change on people. Instead, show them how the future might be and help them participate in creating it.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 2

Provide Options, Don't Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done; explain what can be done.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 1

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

More at the pragmatic programmer list of tips.

Software Development Podcasts

I must be subscribed to 50+ podcasts right now, so I am kind of losing track, but what I can say for sure is that the following podcasts on software development resp. computer science are of excellent quality. For my part, I try not to miss a single episode of those.

• The Java Posse


• .NET Rocks


• IT Conversations - Programming


• Channel 9 ARCast


• The Polymorphic Podcast


• Berkeley Webcast - CS 162 Operating Systems and System Programming (introductorily but nevertheless interesting - and there are more Berkeley CompSci webcasts available)


• The Software Engineering Radio
  

Generics In Java 5 And .NET 2.0

Two days ago I attended a presentation of .NET CLR lead architect Jim Miller from Microsoft. During his talk he told the story of how generics made their way into .NET 2.0 in great detail. Surprisingly there was an original design goal to keep the bytecode compatible, so that older .NET runtimes would be able to handle generics-comprised code as well. As we all know today, they had to give up that objective. Java 5 on the other hand stayed bytecode-compatible with older versions due to its approach of type erasure - generic classes don't contain type information, so a List is represented as a List of objects in bytecode. This of course introduces some drawbacks as well, e.g. there is no way to find out the underlying generic type at runtime using reflection (a feature important for RAD tools and others), or the need for casting resp. boxing/unboxing in case of primitive types.

It's interesting to note that in .NET's case, work on generics started as a research project back in 1999, long before the first .NET 1.0 beta had even been published. On the Java frontier, JSR 14 "Adding Generics to the JavaTM Programming Language" was initiated in 1999 as well (actually Java generics are based on the even older project Pizza/GJ). Six years in the making, in both cases. Amazing.

More on generics in Java 5 and .NET 2.0 can be found in this transcript of an interview with Anders Hejlsberg (talking with Bill Venners and Bruce Eckel) and Gilad Bracha's Java generics tutorial.

Web Applications Vs. Desktop Applications

Clearly for software and service vendors responsible for distributing applications to several thousand clients, web applications must have seemed like a gift from heaven. No more installation wizards crashing, no COM registration, no DLL hell, no reboot, no desperate customer calls on the service hotline. And the same is true for regular software patches - updating a web application happens once on the server and that's it. Many CTOs even favor web applications for intranet scenarios just because of this single reason. When they have to decide between a thin and a rich client approach, it's quite clear which direction new projects tend to go...

The thing is, those folks succumb a fatal misconception. They are just so accustomed to the way traditional client software deployment has looked like for the last 15 years, that they lost track of what is possible today. There is absolutely no technical reason why a desktop application couldn't be installed and updated in a completely transparent manner as well. Off-the-shelf solutions like Sun's Java Web Start or Microsoft's ClickOnce (formerly known as NoTouch-Deployment) have been around for several years, and even if they weren't, there is no obstacle to a proprietary approach - just let your application check it's version number against a central service, and trigger an update if needed.

Now I am not proposing that eBay or Amazon should go for a rich client ;-) But I have watched a lot of intranet systems fail when it comes to usability, just because they were forced to go the HTML way (Ajax and Web 2.0 might improve the situation here, but the base principle still stands). Desktop applications can offer a much more sophisticated user experience, as well as taking advantage of the local machine's CPU power and offline capabilities. And on the intranet it's perfectly appropriate to communicate with an application server using DCOM or IIOP. When HTTP is a must, we still have webservices.

In my experience, developing a certain featureset for a thin client also tends to take more time than for a rich client and is associated with larger technical risks due to increased complexity (caused by the statelessness of HTTP or issues like server scalability).

Don't get me wrong, I like using and developing web applications - I worked on an internet banking solution for about four years, and enjoyed every minute of it. At the same time we implemented an enterprise banking system for corporate customers, where we went with a rich client. Both approaches were well-suited for each task and each particular end user group.

I am just afraid that unless decision makers learn about the real pros and cons of rich and thin clients, we will continue to see corporate intranet web applications spring up like mushrooms when desktop applications would have been much more appropriate.