Geek Pride

Whatever the subject of his post entry is, Uncle Bob always ends up hammering the ultimate goal that should drive us, software developers:

"It is not good enough that a program work. A program must also be written well. As a programmer you should take pride in your work and never leave a mess under the hood. Remember, a product that works, but that has a bad internal structure is a bad product."

Thank you Uncle Bob. May you be read at all levels of management.

Software Patents Or Not?

This month issue of IEEE Canadian Review runs a very interesting article titled "Patenting Software Innovations: A brief overview of the situation in some jurisdictions of interest" (PDF available for download at the top left corner of this page).

In this article Alexandre Abecassis gives a short but informative overview of the reality of software patents in Canada, USA and Europe. A must read, if you want to have clear ideas on the subject.

Another One Rides The Bus

At a time when big brains start to wonder what an Enterprise Service Bus (ESB) is all about and have doubts about the health of Service Oriented Architecture (SOA), today's post of Uncle Bob is a refreshing pragmatic counterpoint, as we can expect from him.

Of course I can only concur, but I must say that scorning enterprise service buses, as he does, is not necessary (maybe it is, just for the purpose of counterbalancing vendors who try hard to push expensive ESBs on clients...).

For me, an ESB is a distributed intermediation middleware whose main goals are:

• Facilitating applications interoperability, and
• Reducing applications coupling, and
• Avoiding point to point communication, but also
• Favoring asynchronous messaging and eventing above synchronous remote invocation.

I believe that deploying an ESB does not imply to embrace the full canonical SOA gong show, but can, in fact, be a good occasion for preaching the values I listed above and alleviate the following inevitable traits of a mature software landscape:

• Applications tend to know too much about each other, with integration happening at data level, if not database level, and sometimes happening beyond the enterprise boundaries.
• Applications tend to wait too much for each other, engaging in long chains of synchronous requests while asynchronous messaging could be used to free up threads, hence resources.
  
• Applications tend to talk too much when they have nothing to say: polling mobilizes resources while efficient, yet simple, notification mechanisms have been around for a while.
  

As time passes, each change becomes more and more complex and risky, as it is hard to estimate what other application will go bonkers if you dare touching something. Nothing new here: this is just a macroscopic replay of what happens inside the applications, where components also tend to develop tight coupling.

So an ESB is not a golden hammer but is just an occasion, a driver, a extra reason for making things better. Presented like this, it is not surprising to find out that anyone who value what they do are willing to ride the bus.

Today is B.A.D.

Indeed, this is Blog Action Day and bloggers all around the world talk about the crucial subject that environment is.

What could I say that has not been said before? I do not know so here is the picture of a salmon I took yesterday afternoon in the creek that flows next to my house.

I wish many wild salmons to the next generations.

Yeah, Please Fix It!

I am tired of having my MacBook losing its Wifi connection, while my XP and Kubuntu boxes have no trouble with it.

The inspiring life of Eric Hahn

In the October 2007 issue of IEEE Spectrum, an article (The Codemaker) depicts the life of Eric Hahn, who "has been an executive, an entrepreneur, and an investigator. But he's happiest of all to call himself a programmer".

The life of Mr. Hahn can only intimately resonate with the life of the many whiz kids who started computing when this activity was only starting to become known to the public. Indeed, I started a few years after him and on a smaller scale of machines (Sinclair ZX-81 instead of a Digital PDP-8/m), writing tiny games instead of hard-core emulators. Living in the countryside of North-East France, the analogy stops here as Mr. Hahn had access to the more stimulating and responsive environments of New York and the Silicon Valley.

One very touching aspect of his life is the tension between making a career and remaining a programmer. Throughout the years he kept his passion writing code and has find enough will and talent to create himself opportunities to keep developing. This tension is symptomatic of our societies that respect more those who make others do than those of do, pushing people away from what they thrive to do to.

“I wonder,” Mr. Hahn says, “how many programmers are trapped in the bodies of Silicon Valley executives. We tend to leave programming jobs because they just don't pay enough to support kids and mortgages here in Silicon Valley. But increasingly, when people have some material independence, they revert.

The only thing I can teach Mr. Hahn is that this is not happening only in the Valley!

____
As a side note: if you are not already a reader of IEEE Spectrum and have any interest in technology, I can only strongly encourage you to subscribe, as this is the best magazine I happen to read nowadays and the only one I read cover to cover.

Show off your cool NxBRE project!

Do you feel like running a few minutes remote demonstration of what you have accomplished with NxBRE and RuleML in your project?

Then you are up to the RuleML-2007 challenge!

Please contact me ASAP for more details.

Blinded By Trust

Sun has improved the new version of their Java forums so my previous rant about how disastrous it was must now be taken with a bit of salt. So it is attractive again to browse these forums for helping people dealing with their development issues.

Answering questions on these forums is a very instructive process because, the same way we learn from our own mistakes, there is a lot to learn from the fumbles of others.

Another interesting aspect is trying to figure out what went wrong in the code submitted by a developer: it is a very hard exercise because you have to fight against the natural tendency to trust the other party for stating their problem correctly.

Moreover this exercise reveals incredible blind spots in the way we perceive other peoples' code when we assume that they know what they are doing, which is the normal position you have with your colleagues, for example.

This today's exchange on the forum is symptomatic of this. Focusing on the programmers stated serialization issue, I totally disregarded the JDBC code he wrote, assuming it was correct. But it was really badly flawed!

The lesson from this is that, when helping a developer with an issue, fight against the natural desire to trust what he is reporting, while, of course, maintaining a respectful behavior. This will help alleviating biases and blind spots when reviewing the defective code.

Paint It White

The Register recently reported that, according to boffins, it is dark times for application development.

Just when I thought everything was getting better. Way much better.

• Writing code has never been so fun: we have great IDEs, loaded with refactoring features, enriched by a wealth of plugins that turn them into tailored productivity platform.
  
  
• Our tool boxes are now loaded with pragmatism-driven frameworks, multi-threaded building blocks and a panoply of libraries for everything and whatnot.
  
  
• Testing has never been so easy: we have a great variety of tools for testing applications at almost all levels and in fully automated ways.
  
  
• Testing has never been so rewarding: funny colored lights give us instant reward on our efforts while test coverage tools provide us with an exciting challenge.
  
  
• Source control management is now accessible to mere mortals: no need to be a command line guru or a sysadmin to store and manage code in repositories anymore.
  
  
• Collaborating on-line is now a reality thanks to tools designed for sharing idea, tracking issues and progress and authoring content over the Internet.
  
  
• Making reproducible and automated builds is a piece of cake: dependency management and library repositories combined with continuous integration platforms produce a sense of velocity and fluidity that makes development thrive.
  
  
• The tyranny of modelling and the myth of big design up front have been debunked and relegated to the museum of toxic ideas.
  
  
• Industry luminaries have risen and their voices have encouraged the inception of methodologies that promote communication, honesty, courage and elevated professional standards.
  
  
• Hype and buzz words are consistently derided and exposed to their true natures by the same thought leaders.

Of course, we face clunkiness, bugs and disappointment every day: does this make our times dark ones?