In this post, I am going to describe an interesting feature in Io, and how I extended it a bit to enhance an XML generator.

In the example provided, the following Io code:

Builder ul(
  li("Io"),
  li("Lua"),
  li("JavaScript"))

can generate the following output:

<ul>
<li>
Io
</li>
<li>
Lua
</li>
<li>
JavaScript
</li>
</ul>

This is made possible by redefining the forward method (“slot” in the terminology of Io), which is responsible for deciding who to apply the method calls (“message calls” in Io) to.
The other key thing is that it is possible to obtain the details on a message call, even when this message is not defined, a bit like what method_missing does in Ruby. This is done using call message.

For example, while this would be a normal method definition:

Builder myMethod := method("I have been called" println)

you could also do it awkwardly by redefining forward and using call message:

Builder forward := method(if(call message name == "myMethod", "I have been called" println))

This leads us to the following program (provided in the book) as a way to implement the Builder called in the example:

Builder := Object clone

Builder forward := method(
	writeln("<", call message name, ">")
	call message arguments foreach(
		arg,
		content := self doMessage(arg);
		if(content type == "Sequence",
			writeln(content)
		)
	)
	writeln("")
)

The exercise was to add indentation dependent on the depth of the tag. It turns out that slots (that is, members of classes or instances) can added to pretty much anything in Io, so I decided to add a depth slot to arguments. Here is the resulting Io code:

// create a sub-class ("prototype") of Object
Builder := Object clone

// redefine the forward method in order to intercept unknown method ("message") calls
Builder forward := method(
	// if the message does not have a "depth" attribute ("slot"), add it
	call message hasLocalSlot("depth") ifFalse(call message depth := 0)
	// indentation is "depth"-times a tab
	indent := "\t" repeated(call message depth)
	// open an XML tag, the name being the name of the message,
	// preceded by the indentation
	writeln(indent, "<", call message name, ">")
	// loop on each of the arguments of the message
	call message arguments foreach(
		arg,
		// increase the depth level for the sub-message call
		arg depth := call message depth + 1;
		// call the message represented by the argument on the current instance
		// (or on the current prototype, as it is the case here)
		content := self doMessage(arg);
		// check if the argument turns out to be a normal String
		if(content type == "Sequence",
			// prints the value of the argument, preceded by the indentation
			writeln(indent, content)
		)
	)
	// closes the XML tag
	writeln(indent, "")
)

With this, the folllowing code

Builder p (
	ul(
		li("Io"),
		li("Lua"),
		li("JavaScript")
	)
)

produces this result:

<p>
	<ul>
		<li>
		Io
		</li>
		<li>
		Lua
		</li>
		<li>
		JavaScript
		</li>
	</ul>
</p>

To sum up, we have created a DSL by redefining the way methods are called, introspecting the method call, and finally added a parameter to the method call (!).

If you want to read more about this technique, check out this other post on Io in the 7 Languages book. Curiously, Ben Nadel uses a variable on the Builder to store the current depth. That works, but it seems to me that it behaves just like a global variable, which wouldn’t be thread-safe. Also, I rather like associating a tag to its corresponding depth.

However, it can only go so far to prevent your code base from swelling permanently. In theory, if your revenues keep growing, you can keep recruiting more people in your development team, and all will be good. Unforunately, that’s not usually how software works.

Like many other things in life, software goes through well-known phases: birth, growth, maturity, and decay. At some point, the costs of maintaining the software are just not justified anymore and the editor pulls the plug.

However, we can do a little better than that. If the project still has some life in it, it can be a better plan to reduce its complexity, in order to lower its maintainance costs and increase its life. In fact, there is no need to wait for the product to decrease in popularity. Housekeeping should be done as early as possible in the lifecycle. No need to maintain features that cost more than they pay.

My current customer has exactly this problem. Their project suffers from feature creep. Regression tests become more and more costly to maintain (it is actually planned to delete some of them regularly — though, of course, nobody really knows which ones we can afford to throw away).

I would call the activity I’m promoting “Feature Refactoring: the process of changing a computer program’s list of features (and corresponding code) without modifying revenues significantly” (balancing short- and long- term revenues). This means that it is OK to remove some features, as long as it is acceptable to your customer base, in terms of money to make in the long term. Basically, you want to avoid the classic pattern where 80% features that are little used or not used at all.

Note that I am not merely talking about features representing significant weight in terms of code, tests, or documentation. Rather, I want to target anything that costs money to maintain, understand (for new hires), market, etc.

How can we do this? Well, here are a few smells that can help

• your client representative tell you about it — the easy scenario
• you detect that few customers actually use your modules – monitoring tools can help you here
• you find bugs in production… and few people actually complain about it — should this feature be there at all?
• you upgrade your project… and nobody complains — if your features are popular, someone is bound to complain about any change
• specs for a particular feature are not updated — features that do not evolve tend to rot
• run workshops with customers — a interesting format for this is Speed Boat

My point is that there are even more potential benefits in term of code maintenance when removing features, compared to refactoring the code base (which is a good thing to do, too).

Refactor your features. See this one there in the corner? You Aren’t Going to Need It.

You’ll be happier.  And you will probably save money.

I’d like to have many visitors. But compared to some blogs I follow, I still have work to do. Here are some information, according to Google Analytics.

• Compared to Claude Aubry, who writes in French about Scrum, I now reach 1,500 unique visitors per month, while he has twice that many.
• Julian Simpson’s Build Doctor on Continuous Integration, seems to average 100 visitors per day (it’s difficult to tell on the graph), I think I’m around 50 per day. Missed again!

My wife does not like it when I compare myself to others. Me, I feel it is stimulating. This makes me want to write more.

Other trivia:

• my most popular post ever is the one about Gienah; strangely, it is also the most popular one in the past 3 months, although it is 18 months old
• next, with almost the same number of visitors, a post about a classic error message in Maven and one about download stats for CC and Hudson, which has been referred to by quite a few sites, including dzone.com
• Firefox is by far the most popular browser, with more than two thirds of visitors
• Almost 80% of people use Windows (I was hoping Linux and MacOS would do better, but they got less than 10% each)
• the vast majority of people find my pages through Google; other sources are dzone, Blog Valtech, FeedBurner (possibly because of syndication), NetVibes (I guess some people have added my blog to their home page) and The Build Doctor.
• the two most popular region of origins are the USA and France (half of the traffic in total). I am rather happy with that, as I do write in English to be heard outside France.

Anyway, my biggest satisfaction is that traffic has been consistently rising from the beginning. It does take time, but who wouldn’t do that for fame, money and women! ;-)

One thing I have done recently is add FeedBurner analysis. It does not show much for the moment; I’ll guess I’ll get data next year. The other thing I did is syndicate my blog under Planet Valtech and CITCON Blogs. That will probably make a difference in the medium term.

In 2007:

• I got married
• we almost completed improvement work in our flat
• Attended 7 conferences (compared to just 1 in 2006). Hard to say which one was my favorite!
  • Sun Tech Days
  • XP Day Paris
  • AgileOpen Europe
  • CITCON Brussels
  • Valtech Days
  • BarCampParis15
  • Paris On Rails
• helped organized Valtech Days and CITCON, and joined the Agile 2008 organizational committee, as a sidekick to Laurent Bossavit, for the Breaking Acts stage.
• became “Technical Leader” for Valtech France
• technically, became serious about Hudson, Maven, Spring and Hibernate
• organized internal training sessions, and consultants going to conferences
• taught Scrum and Build Process for Valtech Training

All in all, a pretty good year!

In this screen shot, the website is all in English, as long as my browser is configured for English as the primary language. All fine and good.
But, if I switch to French as the primary language, I got the site only partly in French. Of course, it makes sense in a way: the website engine is supports many languages, but the content written by the contributors is only in English. Well… why not make English the default language for the site as well? I guess this is what you get when you don’t stick to English at all times.

This can be forgiven for a website hacked together by a few developers for their own needs, but what if Flickr/Yahoo does it too? well, it can get really, really ugly.

Consider this: I configured Flickr and my browser both to use English. As for Yahoo, I couldn’t find a way to specify the language. All I did was set to the content to be US-centric. My location remained France, though.

Well, believe it or not, when I wanted to upgrade my flickr account to Pro, I was served with a page containing a mix of English, French… and Italian. Now, English & French, OK, I can understand (though not forgive: Yahoo should know better); but Italian?? Where did that come from?

Even the French part is weird, though: did they pick it up from my localization? Or from the IP address of my internet gateway? I sure hope not: I remember being in Denmark in 1997, and trying to access my developer account on Microsoft website: one day, all appeared written in Danish…

What is most intriguing to me is the parallel that can be drawn between each of these books, and the facilitating technique of the Five Whys.

The line of thought for the author of Guns… seems to have been the following:

The European civilization dominates the world.

• Why? Because they have had stronger armies, more developed weapons and means of transportation, better writing skills, and deadlier germs.
• Why? Because they have been able to support dense populations, a hierarchical society, scientists, scribes, and an environment where germs have multiplied.
• Why? Because they have had plentiful food in terms of edible plants and useful animals; the later have brought germs along. All this earlier than competing societies.
• Why? Because appropriate domesticated plants and animals where available nearby (mostly from the Fertile Crescent) in great numbers.
• Why? Because fauna and flora were more rich and diverse.
• Why? Because Eurasia is the largest continent, and has a West-East axis, which helps fauna and flora to spread out (climates varies less than on continents with a North-South axis), compete with each other, and develop more useful characteristics.

As a side note, not only the European civilization ended up dominating other continents, but the fauna brought along as well (this is a general statement; counter-examples do exist).

For Jim Collins, the author of Good to Great, it goes more or less like that:

Some companies used to be mediocre, but at some point raised to greatness and never fell back. That, over a fairly a long period of time (more than 30 years).

• Why? Because they are selling the right products.
• Why? Because they have had an appropriate core concept of what they want to do, can do, and make money with in the long term
• Why? Because they have thought long and hard, and then stuck to their core concept, no matter what
• Why? Because they had the right people on board
• Why? Because they had a “Level 5″ Leader (a servant-leader, consistent and fearless); also, they did not have a high-profile, bigger-than-life leader that proves impossible to replace
• Why? Mostly because someone was lucky enough in assigning this person as CEO

Of course, both chain of thought might strike as a bit simplistic. In a way, they are (though you’d better read the books first before judging them to quickly). For example, in Guns… the author admits that some additional explanations are required, for example the fact that Europe was geographically dispersed helped creating competing nations, as opposed to, say, China.

Still, they strike as reasonably good analysis of the main forces at work. Such depth of analysis is refreshing in a world where authors tend to serve ready-made solutions.

Obviously, in the context of this post, it sounds trivial that these sentences are nonsense. However, in the heat of the conversation, they can pass unnoticed. Both persons seemed actually convinced that they were true, and used them as proof to further the debate.

How often are we taking random figures at face value? (“we have estimated this project to cost this much”) We should always be at least critical.
The idea is to think of other things to judge the figure against (“the laws of economics would probably prevent the price of bread to increase so fast in such a short time”). Intuition helps, naturally.

“Common sense is the most fairly distributed thing in the world” (Descartes). It seems that it is still not enough. Let’s keep in mind that others can be wrong, and that we ourselves can be wrong. Judging people and behavior is foolish, but judging data is not.

So, when hearing figures, always keep a critical mind, especially if this figure is used to take decisions. Conversely, do not show figures as hard facts. Be as honest as possible and make clear that “well, I heard this on the radio, but I might have misunderstood”. Giving a wide range of possible values helps too (“the most probable estimate is 1000 man-days, but plausible estimates range from 500 to 5000″). You’ll be helping others, and yourselves.

From 1998 till early 2000, I used to work for Verilog, a French software company (I was based in the Dallas office) that was doing pretty well with its IDE targeted at the SDL world. One fine day of December 1999, I arrived in the office, only to learn that Telelogic, the other major player in SDL, had acquired us. Telelogic was no worse, nor better that Verilog (though certainly more commercially aggressive), but I needed a change and in April, I went back to Europe and joined Valtech (in London for a few years, then Paris).

When we were at Verilog, we used to worry about Telelogic (which we thought was using disloyal means to take business from us), and also, though less, about Rational (for its real-time software IDE), i-Logix, and a few others.

Well, Telelogic snapped Verilog, then i-Logix (among others). IBM acquired Rational (among many others), and now Telelogic.

It’s a strange feeling to hear about a company you used to work for. It’s a bit like hearing about long-lost high school friends: how did they do? and, inevitably, did I do any better?

Every now and then, I come across people that used to work for Telelogic, including the project manager of my current consulting gig at EDF, and Pascal Roques, a UML guru and a colleague at Valtech (the proverbial small world).

More here.

If you don’t know them already, here they are for your reading pleasure.