Commit Risk Analysis

I like to compare the stability of a legacy application as a saddle point:

QA provides some lateral stability that prevents the legacy application (this little funny red dot) to fall sideways. But, still, a little push on the wrong side and down the hole the application will fall.

What the legacy code typically misses is unit tests. With unit tests, the saddle disappear and the code stability ends up in a pretty stable parabola:
In an ideal world, there will be no legacy code. In a little less ideal world, there will be legacy code but every time a developer would touch any class, he would first write unit tests to fully cover the code he is about to modify.

Unfortunately, in our world, code is written by human beings. Human beings turned the original code into legacy code and human beings will maintain and evolve this legacy code. Hence there will be modifications on non unit tested code that will end up checked in. Inevitably, the little red ball will drift on the wrong side of the saddle.

I came to wonder what could be a way to estimate the risk that has been introduced by changes in a code base. Basically, the risk would be inversely proportional to the test coverage of the modified class.

I came with a very basic tool, Corian (Commit Risk Analyzer), that simply fetches the Cobertura coverage percentage for classes that were modified in Subversion for a particular number of days in the past.

Do you know of any method or tool for estimating the risk that a series of revisions could have introduced in a code base?

Bauhaus & Software Development

It took me a while to realize this but I finally noticed the deep similitudes between software development and the Bauhaus school of design. My CS teacher and mentor, who was knowledgeable about almost everything, had a particular penchant for the Bauhaus: it only took me 16 years to grok why...

Quoting Wikipedia, "one of the main objectives of the Bauhaus was to unify art, craft, and technology". Is not this unification realized in software development? In fact, should not this unification be the basis of successful, satisfying and fulfilling endeavors in this field?

Technology - This is the easiest one. Software development is obviously about technology, as the concrete manifestation of scientific and engineering progresses. The smaller the transistors, the denser the processors, the more powerful the computers, the happiest the software developers!

Craft - Uncle Bob speaks about it better than I could ever dream of. He has just proposed a fifth element for the Agile Manifesto:

Craftsmanship over Execution
Most software development teams execute, but they don’t take care. We value execution, but we value craftsmanship more.

Art - The connection between software development and art is often controversial. Here, I will let Kent Beck convince you, with an excerpt of Implementation Patterns:

Aesthetics engage more of your brain than strictly linear logical thought. Once you have cultivated your sense of the aesthetics of code, the aesthetic impressions you receive of your code is valuable feedback about the quality of the code.

A superficial look at Bauhaus buildings or paintings may give an impression of coldness and impersonality. But if you look again while keeping in mind the objective to unify art, craft and technology in an harmonious design, you will see things differently.

Try with this:


Or that:

And now with that:

Just Read: Managing Humans

Michael Lopps' capacity to deconstruct and analyze every aspects of both software engineering management and nerd internal mechanics is simply outstanding.

This book is not only insightful and amusing, but is a looking glass where all the intricacies of humans' management get revealed.

A. Must. Read.

Blog Inaction

Larry O'Brien said it better that I could ever formulate it, so here you go:

I've been busier than some metaphorical thing in some metaphorical place where things are really busy.

And here is what kept me and is still keeping me busy those days:

Silverfight

The Register is running what seems to be a balanced review of (the yet to come) Microsoft Silverlight (2.0).

It seems balanced because you have ten pros and ten cons, which might suggest that adopting Silverlight is merely a matter of taste (XAML is attractive) or politics (like for the NBC Olympics). But I think that, if you ponderate the different pros and cons, you might end-up with a balance that leans on a particular side (I let you guess which one).

The availability of designers' tools that runs on the Macintosh platform will certainly be critical if Microsoft wants to entice them out of the Macromedia world.

Similarly, the heroic efforts deployed in Moonlight to make Silverlight cross platform will be key to the overall success of this, otherwise proprietary, platform.

As of today, here is how a simple example comparing Silverlight and Flash runs on my machine:

Yep, this is a big empty white box with statistics about how fast Silverlight renders it in the status bar. If Microsoft is serious about dethroning Flash, which I am not entirely convinced of, they will have to go past this kind of... emptiness.

Just Read: Implementation patterns

If you are an aficionado of formal pattern books, you might be disappointed by the latest book from Kent Beck. This book is more about a mentor sharing his experience than a succession of diagrams, code samples and rules for applying or not a particular pattern.

In this book, Kent clearly took the decision to engage the reader in a direct manner: there is no fluff, just the nitty-gritty. Just years of experience and experiments summarized in less than 150 pages. I leave to your imagination to figure out how dense the book is. It is sometimes so rich that I came to wish that a little bit of code or a neat hand-drawn schema could be added here and there, just to make a particular pattern more edible for a slow brain like mine.

There is an intense tension in this book: I have been fulminating after reading some takes from Kent where he states counter intuitive approaches as far as defensive coding is concerned. And then I reached the last part ("Evolving Frameworks") and it striked me: so far in book, Kent was not coding for public APIs. And it striked me again: Kent is a master, he adapts his way of coding to the context.

Let Kent Keck talk to you: buy this short book and listen to what he wants to share with you.

GMail Auto-resizing Rules!

Just a quick "thank you" to GMail's team for the new auto-resizing feature that makes the edit box use efficiently the available screen real estate.

This is good.

Cuil Geared To Hidden Success

It took me a while to realize this but Cuil, the new flashy search engine that randomly displays porn and has a name that looks like the French word for an unspeakable part of the male anatomy, bears in its name the inevitable fate of a hidden success.

Let me explain. To succeed on the webernets, you need two Os in your domain name. Amazon made the risky choice of a M-separated-double-A and they surprinsingly do well, so far. But anyway, if we narrow down the field to search engines only, it is pretty obvious that the double-O is de rigueur for success.

So what on Earth did happen to the guys at Cuil? Well, you see, the trick is in the pronunciation. It is pronounced "cool". Here you go! The double-O, that was hidden in the domain name, becomes visible when you say it.

Consequently, a hidden double-O can only lead to a hidden success. Which is not a failure by the way.