Last Night Eclipse Demo Camp

I attended my first Eclipse Demo Camp last night in Vancouver and it was really a great event! Of course, the profusion of food and beer offered by the Eclipse Foundation at the end of the evening surely helped building such a great impression...

The whole evening was driven by the Tasktop guys, which gave us a chance to get a feel of the interesting ecosystem that is growing around Mylyn. I would like to turn the spotlight on two projects which are worth discovering on your own:

• Tripoli, an EclEmma-powered code coverage diff tool that allows you to pinpoint issues in an efficient manner.
• TOD, a so-called omniscient debugger that allows you to do back-in-time debugging without a DeLorean (which made me think a lot about what ReplaySolutions is building).
  

These two projects are brilliant illustrations that academia can produce concrete results in software engineering. That is surely encouraging for practitioners!

As a closing note, if you happen to be in Luxembourg tomorrow evening be sure to hit the Eclipse Demo Camp over there. You will have a chance to see Pierre-Antoine and Fabrice live, which is really worth the trip!

Mulecast: “Mule in Action” book interview

Ross Mason has interviewed John D'Emic and I about Mule in Action.

If you listen to the podcast, you will get a 27% discount voucher as a compensation for ear damages caused by my broken English.

Isn't life a bliss?

Seven Years To Rot

So here we are, seven years after the Manifesto, and the webersphere is pontificating about the decline of agile, to the point that Uncle Bob has hard time containing his anger in front of such a display of nonsense and dishonesty.

What is going on with agile? After seven years of existence (I know, the techniques and approaches agile promotes predate the Manifesto), has it started to rot?

Some suggest that agile is following the Gartner hype-cycle and has now past its "peak of inflated expectations":


Of course, there is hype around agile and the diatribe of some of its fanatics can be a little over the top. But I think that the current "decline" in agile is not due to some disillusionment.

I think this so-called "decline" comes from the numerous software sweat shops and less-than average programmers who started to pretend they do "agile" without changing anything in their craftsmanship. Instead of a disillusionment, agile suffers from dilution.

Hopefully, people will be able to sort the wheat from the chaff and debunk these agile fraudsters. When this will happen, agile will start climbing its "slope of enlightenment".

The Path of Least Resistance

While fighting with monsters of legacy code, I have kept thinking of all the possible reasons why developers would end up building such a man-made hell. My capacity to analyze the situation and figure out possible causes is limited to the knowledge of the external forces that these developers where exposed to. For what was happening inside of them, I am limited to build analogies after looking at my own battles and shortcomings.

I have been trying to distill a unique question. Here it is: why would a developer choose to the walk the path of least resistance?

Though skill, experience and professional standards are factors at play, I do not think they can explain the whole picture. Deadline pressure certainly encourage to cut corners and follow the easiest and dirtiest path. But the crux of the problem is not there. It is in the resistance.

What is this resistance anyway? It is multiform and hard to characterize. Any developer surely has felt at least once the slight despair it entails: you want to progress and get blocked by a wall of resistance that is not insurmountable but would incur a great cost in term of work disturbance.

Here are a few example of the outcome produced by such a resistance:

• Teams entrenched behind layers of management feel encouraged not to wait for the others to do something that they need and end-up building sub-optimal solutions with what they have now.
• High cost of database changes can drive developers to extremes like the reuse of existing fields, the use of inadequate field types or the storage of serialized objects in BLOBs when a few extra columns would have done the trick.
• Long feedback loops between a code change and the result of testing orient developers towards implementing new features with minimal changes to existing code, which ends up with code duplication, spaghetti plates and design-less applications.
  

Facing resistance, it is very hard for a developer to postpone the completion of his work because, when he is building something, he is driven by the goal to reach and tend to disregard warning signs. This is the same challenge that airplane pilots face when their guts tell them to stay on the ground or to turn back but their focus on reaching the planned destination make them fly into trouble. The only difference is that, oftentimes, these pilots will not survive their decision to ignore warnings, while in software we can move on to a new job and pretend nothing happened.

Taking intelligent decisions while being goal driven is hard. Everybody knows that the path of least resistance is rarely the best one. Alas, we walk it and, I suspect, not by laziness but by renouncement.

Just Read: Facts and Fallacies of Software Engineering

Sometimes, when I read a book, I look at the publication date and wonder out loud: "what on earth was I doing this year to miss this one?". This is exactly what happened while reading this book from by Robert L. Glass. What on earth was I doing in 2002 to have missed such an excellent book?

Known as the F-Book, after its original title proposition ("Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering", which thankfully was not kept by the editor), this dense book is truly the sum of all truths and untruths about software engineering.

This book is really invaluable as an aid for debunking hype of all sorts and performing reality checks on tools and methods that oftentimes are dumped on software engineers with the promise of a brighter future (that never materializes).

With half a century in the field, Robert has seen it all and heard it all already. If you think your problems or questions are new or unique, then read this book and keep it, because you will have to come back to it and quote it whenever you will need to challenge a snake-oil vendors or an ivory tower methodologists (pretty much like you do with the anti-patterns catalog for development mispractices).

Silver Still Very Light

I have just switched to the latest version of Moonlight, the port of Microsoft Silverlight on Linux, and the least I can say is that things have significantly progressed since the last time I tried.

So far, I have found only one site of use whose Silverlight application runs fine on Linux: the Ryanair destination map. Though the plug-in reports a rendering speed of close to 100 FPS, the zooming and panning is still way behind what pure JavaScript or Flash applications provide. But it is very impressive already.

The only problem seems to reside in the Silverlight detection algorithm used by most of the sites. Most of them give me the Redmond finger:


... while Moonlight is there and ready to chew XAML and render it! Too bad, I would like to see more of these sites and keep track on how this runner up technology will compete with the ones already in place.

At the end of the day, I have no doubt Silverlight/Moonlight can become a credible alternative to the current RIA browser-side technologies. My main concern is that sloppy developers may create Silverlight-powered sites that will only work with a limited set of platforms (browsers, OSes), which would be a regression from the current state of the web nation.

Where the hell is... Alineo?

After Matt and his little dance, my brother in law, of VoilaSVN fame, has decided to go freelining worldwide.

Two episodes so far: the classic grand Canyon and the way more exotic Luxembourg.

Enjoy.

Reality Check Levels

I am in a "question everything" phase. Maybe it is a side-effect of reading the excellent F-book (review coming soon) or the outcome of learning about the software half-life hypothesis? All in all, I am more and more dubious about what I read and hear about in the field of software. I have grown tired of half-baked ideas (including mine) that present possibilities as realities and niche solutions as widely applicable ones.

It seems this is natural: smart people have started to change their views on important subjects. Since I am not that smart, I would like reviewers of articles and publications to add something like the color-coded terrorist threat level to indicate the reality-check level of what I am reading.

That could be something like:

RC0: This is highly hypothetical material. Mainly works in the vendor's environment, on the open source committer's laptop or in the researcher's lab.

RC1: This plays well in the F100 or governmental field. Complex committee-driven years-long BDUF-minded expensive concepts can be applied here. But nowhere else.

RC3: This is the field of pragmatists. The ideas, methodologies or products are based on simple, well-established and proven concepts.

Like the threat level, this scale is coarse and over simplistic. Would you like it anyway? Would you had more levels?

Legacy Tests

In Working Effectively with Legacy Code, Michael Feathers states that, for him, "legacy code is simply code without tests". As he says it himself, he has "gotten some grief for this definition". I can understand why.

I have come to deal with some legacy code monsters recently and came to realize that this code had tests written for it. So could it be that this code was not legacy after all?

After a closer inspection, the truth finally came out:

• the test coverage is very low (less than 30%),
• the tests explore counter-intuitive paths (for example, just the unhappy ones),
• the tests themselves are monstrous (created in what looks like a copy/paste spree),
• they overuse mocks in a lax manner (many are not verified at tear down),
• they do not verify the complete state after execution (no validation of indirect outputs like request and session attributes),
• and, corollary of the legacy framework the code targets (EJB 2), full correctness can only be proven when deployed in an application container.
  

I immediately thought of chapter 9 of Uncle Bob's Clean Code, where he advocates that unit tests should be written with the same care than for actual code. The tearful hours I spend refactoring these tests so I can then refactor the code they are supposed to exercise, are a good testimony to this imperious necessity. Keep tests clean!

Else you will end up with nearly worthless legacy tests.

Two third of a Mule in Action

I am happy to report that two third of Mule in Action is now available from Manning's Early Access Program.

If you were deferring buying the book, now is a great time to part from a few bucks and get it! Indeed, you will find in these 280 pages a lot of practical knowledge about Mule that John and I have put together for your utmost enjoyment!

And just to thank you for spending your time reading this blog, I will share a little secret with you. If you use the aupromo25 promo code when buying the book, you will get 25% off the price. But please, don't repeat it.

Finally, just so you don't think it is all about money, you can always get the source code for the book for free. That is zero Dollar, which is also zilch Euro and no much more of any other currency you happen to have in your pocket.

JBound 1.1 is out

I have just released version 1.1 of JBound, my simple utility that performs boundary checks on domain model objects.

This new release features native support for more JDK data types and the possibility to register custom data types.

Consult the daunting one page user guide for more information.