Going Hollow

If you go driving through France, you will notice that every hundred miles you come to cross the borders of the different historic regions, roughly matching the ancient duchies of the kingdom. Road signs clearly show these landmarks by displaying the name and the "logo" of the region.

While driving back to Lorraine, my home region, I noticed that the said logo is now a vague alteration of the original coat of arms. This alteration make no sense and does not carry any value or meaning, unlike the original blazon. See for yourself:

Original Coat of Arms (dated 1183)

Current Logo (dated 1999)

I am not preaching the altar of traditionalism here: all I am saying is that the original coat of arms had a meaning, while the new one has not. The three birds on the red band was a reminder of the legend saying that Godefroy de Bouillon, the initiator of the first crusade who took Jerusalem in 1099, killed three birds with one arrow during the siege of the holy city.

The current logo is simply an aesthetic redesign of the original blazon: the red band has disappeared, the birds point to the top right corner and they look like arrow headed deltaplanes.

Previous Logo (dated 1986)

In that sense, the previous logo was bearing more sense. Lorraine region is positioned on the hexagon that traditionally represents France. The colors represent the resources of the region (water, agriculture, steel industry...).

What is the lesson for us in the IT field? Let me propose the following: Let us not pursue novelty for the sake of itself but only if and when it brings new sense and value to our industry.

Agility Does Not Work!

Well, at least this is what some discussions are about currently on the blogosphere. Of course, this is as nonsensical as saying that concentration, stars or ants do not work. They all accomplish a purpose and do it very correctly when done at the right moment and the right place.

Most of the complaining people could have been frustrated by the fact that agility is not a tool-set, nor even a skill-set but truly a mind-set. This mind-set, whose substance is described by the Agile Manifesto, gets derived in many different practices. Therefore, one could imagine that by following these different practices, the project will become transmogrified into an agile gizmo. Unfortunately this does not work this way: as the law is spawned by the spirit of the law, agile practices come from agile minds. You need an agile mind first in order to put agility in practice.

With this mindset, it is possible to adapt agile principles to the sheer reality of your project or your clients, which is where the true challenge resides. Not all clients will accept the full monty: adaptation is needed. Here are some examples:

• Your client is addicted to BDUF: discreetly invest “analysis” time in running spike projects (call them “proof of concept”) to tackle as soon as possible all the technological risks and uncertainties (allowing to fail fast if need be),

• Your client loves methodologies: turn to Scott Ambler's AgileUP and see how agile the unified process has turned under Scott's expert hands,

• Your client does not want to be collocated: release often and expose your client as early and as openly as possible to the system you are building for him (he sure will react and provide an invaluable feedback),

• Your client has a really big project, so big that you think agility has touched its limits: then use a more traditional approach (serialization) to pilot agile driven smaller sub-projects (read Balancing Agility and Discipline for more about this).

There are many other situations when it will be difficult or impossible to openly sell an agile project to a client: pair programming (why paying two guys for the job of one?), time & features negotiation (these are the specs: what is the price and the deadline?)...

The important thing to remember is that more than a list of recipes, agility is a state of mind that will materialize differently in each and every project.

Coming to the Rough Cuts!

Jim Holmes and James Avery new book, Windows Developer Power Tools, has hit the O'Reilly Rough Cuts, where its chapters will be progressively released.

Chapter 18, covering the vast of subject of Frameworks, will include a section titled "Externalize Business Rules with NxBRE". You can imagine how excited I am: after almost three years of hard work and thanks to the continuous feedback of an excellent community of users and developers, NxBRE is reaching a new level of visibility: an O'Reilly book!

This chapter has not made it to the Rough Cuts already but it is on its way. I will update this post when it will be there.

In the meantime, you can also browse the TOC of the book to discover all the gems waiting to be discovered in it!

[Update 20-JUL-2006] The book has a jolly cool cover!
[Update 19-AUG-2006] The book is now in pre-order on Amazon.

Managing the Gap

Zepag has posted an interesting story in this Blogical shift (whatever that means) titled "From software to detergentware...", where he talks about the new wave of two-zeros (Web, SOA and whatnot) that is currently hitting our jolly technoworld.

The fact that marketing feels like creating such apparently-brain-dead new versions of old stuffs probably means that it is part of a natural motion in the world of selling stuff (be it concepts, software, soap, consultants or SOAP).

This reminded me of the excellent blog posts from Eric Sink about the necessity and strategies for closing the gap between the product and the customer (read part 1 and part 2). And I came to the conclusion that this gap does not really need to be closed but to be managed.

When the gap becomes too small, the customers are in a position of deep familiarity with the product, up to the point were they will stop considering it as something they have tought about and paid for, but a simple and commoditized part of their own life.

This is when you need to manage the gap: creating a new two-zero of something makes the customer in need (if not urge) of getting this new product. Instantly, it has become a new object of desire. In that sense, vendors really know what they do and how to influence the crowd we are.

Of course, nowadays, with the instant worldwide reactivity of the internet connected network of customers we all are, there is a serious risk of backfire. Still, this is a strategy that pays.

A few years ago, Microsoft understood it and decided to take the whole boardgame one step further: they decided to switch from a raw number version system to a vintage-like years version system. This was very clever because it allowed to make the gap easier to grasp for the human mind: who cares about running on Word 7 in 2006? Now if you say that this is Word 95, you immedialy feel in great need of upgrade!

Hence the gap between products and customers is not negative fact but a parameter that must be managed by marketing people.

Who Can Have The Keys?

With the current upturn in the IT industry, recruiting software engineers is a hot business... again! There are numerous posts throughout the Internet talking about companies' strategies and candidates' adventures (good and bad). I have found this post from Reg Braithwaite particularly interesting, both from the story he tells and the links he shares at the bottom of the entry.

Let me explain how we do software engineers recruitment at Agile Partner. Like everybody else, we look for smart people who can solve problems but, because we are a small IT consultancy, we do not do generic recruiting, like Amazon or Google might do. We look for particular profiles (junior, senior, architects) on particular technologies (.NET, Java), then we tune the “smart people who can solve problems” filter for this particular job offer.

As purveyor of software and services for enterprises and governmental agencies, we look for people able to develop enterprise software (I am so scared to use this expression because of one terrifying post from Alex Papadimoulis), which I reckon is the case for the vast majority of the companies similar to us. What does this imply in term of recruiting?

Most of our software engineers daily job will consist in wiring building blocks together in order to create back-office systems that will solve the business problems of our clients.

This job is not exactly formal Computer Science as almost no algorithm knowledge is required (with the exception of proper XSL-T writing, which involves a lot of recursion. I tend to consider a good XSL-T developer as talented developer). Hence high CS grades are not something we do care for very much.

But this job is about curiosity, instinct and quality.

This is why we look for people:

• who are eager to learn and able to do it fast in order to find their way out in open source project code bases or application server stack fest,

• who know the secret of good middleware development and can conceptualize the intimates of a multi-threaded application,

• who have high work ethics and work hard on themselves to stick to these standards.

If we feel that we share this set of core values and other common reference points (like gurus we worship or RSS feeds we read), we will then try to estimate the actual scope of technical knowledge of the candidate, considering that lacks are gaps to fill, not show-stoppers.

We will carefully avoid tricky questions because they show nothing, except a good memory or the reading of an interview preparation guide. We are much more interested by a candidate who knows where to find the information she needs instead of one who can write the code of an algorithm on a white board or rule out if an obscure piece of code can compile (if you can not decide what a piece of code does by reading it, it smells like it is in great need of refactoring).

Then we ensure that the actual coding practices of the candidate match with her assertions. In case the person is a committer on an open source project, this task is greatly simplified: the code review can be done with a simple browser, as most of the code repositories are accessible via HTTP. Else, we will ask the candidate to realize a simple program, with somewhat incomplete specifications (as in real life) and with no time constraints (the exercise being done at home).

All this can sound pretty lax but, believe me, very few go through this process until the end.

Which is ok because, at the end of the day, they will end up with the keys of the company. Something only possible with people you can trust.

Not A Mere Option Anymore

Just a few days after receiving my free and good looking Kubuntu CD, I am up and running on this splendid platform.

My Dell Precision M90 is fully supported, including Wifi. All my tools are up and running: Callisto, jEdit, Firefox, jBoss, OpenOffice... And it really flies (jBoss up and running in 11 seconds).

So what is left for the other operating system, still available as a dual boot? .NET development because I want to stay on a platform close to the one of NxBRE users. What else? Ah, gaming of course!

With the nice marketing of Vista currently going on, switching to Linux is not a mere option anymore, it is a choice anyone can make, thanks to Kubuntu.

Let us spread the word.

The Way Frameworks Go

While converting NxBRE to .NET 2.0, I came to realize that the SDK has been super sized.

Being a daytime Java geek and an open source developer on .NET, I can say I have a fairly good grasp of the two frameworks. When I started to work on .NET, I really appreciated the compactness and the clarity of its SDK. Informative namespace monikers and well-thought APIs were two features a guy coming from Java could appreciate.

Now the whole stuff is getting really fat, really Java-ish to speak frankly. But this is not the super sizing that I find disturbing.

The introduction of generics has triggered some really strange forks in the SDK. Take a look at the System.Collections namespace and you will notice that it has spawned a generic version of itself under System.Collections.Generic.

I would really appreciate if some .NET guru could explain why such a thing has happened? How come the existing collections have not been made generic? This has been done in Java, why not in .NET?

Now we end-up with two IDictionary interfaces, which can be a pain to handle in the same class. This can happen because you can not and do not want to use generics everywhere, especially if you look for performances with millions of entries collections.

To add to the confusion, the common implementation of IDictionary that was Hashtable has now a generic counterpart named Dictionary. Who said consistency was bad? I leave to the reader to appreciate the definition of Dictionary:

public class Dictionary<TKey,TValue> : IDictionary<TKey,TValue>, ICollection<KeyValuePair<TKey,TValue>>, IEnumerable<KeyValuePair<TKey,TValue>>, IDictionary, ICollection, IEnumerable, ISerializable, IDeserializationCallback

Truly delightful. I wonder how many pearls like this now hide in the SDK...

I thought .NET was a Java copycat but without its flaws. Not anymore. That is the way frameworks go.

PS for the Ruby guys: beware!