Adapted from Alistair Cockburn's People Factor:

[Process-oriented organizations] are designed to battle the inherent individuality of each employee. [Goal-oriented organizations] are designed to capitalize on it.

You might want to check out what F-Secure has to say about Google Desktop and the recent Windows WMF vulnerability outbreak.

So, I see this job ad on the internets and one of the requirements set for the candidate said:

- Experience with clustered servers & log shipping

Wow. I wonder if they'll be able to find a geek that has experience with clustered environments and has worked in the logging industry...

Obviously "log shipping" in this context meant log shipping.

Glen Alleman:

In the spacecraft business no design can survive the review process, without first answering the question - how are we going to test this thing?

I've been doing a little (my own definition of "little") cleaning up at home for Christmas. As a result of going through the pile of stuff I've built up on my desk, I found(*) a piece of wisdom I had written down on an index card abandoned in the very bottom of the pile:

stubborn != disciplined

I can't for the heck of it remember where and why I wrote that down, but I can imagine it has been after an "interesting" discussion...

(*) I also found a little plastic bag from a carry-on bag with three brand new pairs of black socks. An early Christmas present for myself... I guess that tells something about how bad I am with unpacking my stuff before packing again.

If you're around, do consider signing up (and showing up) for the next coding dojo at Reaktor. We've had a lot of fun in the past sessions and I'm sure that we'll continue having fun in 2006 as well.

Allan, a friend and a former colleague, has posted quite a mouthful in the form of his orthogonal root principles of software design.

My favorite online bookmarking service, del.icio.us, has been down for at least 12 hours after a power failure and some kind of a RAID crash left the bookmark databases with corrupted data. They've said no data has been lost and everything will be just like before as soon as they've rebuilt all the indexes.

Based on all of the comments in the del.icio.us blog, it sure is a popular service. And I have to say I do feel a bit naked not able to tag a certain blog entry that's been sitting on my laptop's screen since this morning.

Hmm. Maybe I should pick up my pace on the feed translator and start developing a tagging aggregator which would synchronize my tags between the various online bookmarking services and protect my addiction from this kind of downtimes...

It depends.

But Clarke has posted quite a gem for differentiating the definition of quality in two contexts: product development and manufacturing:

• Quality for PRODUCT DEVELOPMENT: "Fitness for Use"
• Quality for MANUFACTURING: "Conformance to Specificiation"

Now, as a customer for a software project, which would you prefer? Software that's fit for its intended use or software that conforms to the original specification?

Simple. Brilliant. Keep it coming!

Seen on the tube, an ad by AXA (an insurance company):

"If an apple a day doesn't cut it. Plan."

It works the other way around, too.

Yesterday night (again, the night before a flight...) I hacked my feed translator project a bit.

One of the tasks I decided to take on was to take the application on FastCGI at Dreamhost. It turned out to be a bit problematic, involving plenty of HTTP 500 errors, complaints about premature header endings and what not. I got it more or less figured out, eventually, but it certainly was a lot harder than one would expect. Certainly not Railsy...

On a more positive note, I'm happy to post a couple of more screenshots!

The first one, below, shows ...

Looks much better than the previous screenshots, doesn't it?

The second screenshot highlights a problem I just realized, however:

Surely we can't let code snippets inside <pre> and <code> tags mangle up during the translation so I fixed it while being at it by judicious application of regular expressions:

Still on the to-do list:

• Serving translated feeds from a cache
• Server-side conditional GET requests
• Client-side conditional GET requests
• Support for more feed formats (currently RSS 2.0 and 1.0)

Once those are in place, the service is probably stable enough for me to actually try and make it public. No promises, though!

The night before leaving for XP Day, I started writing a little bit of Ruby code for translating Frank's blog automatically from German to English so that I could actually read it.

What I managed to accomplish in a couple of hours in the middle of the night was more or less a spike solution that fetched Frank's RSS file from his website, ripped it to pieces, fed the bits and pieces to an online translation service (simulating a web form submission) parsing the translation results from the resulting HTML, and then stuffing these translated snippets back into the feed object hierarchy, eventually printing them out on the console.

Yesterday, feeling unable to make much progress on the book, I decided to pick up the slack and continue developing the feed translator, effectively putting it on Rails. I started by simply glueing what I had behind a Rails controller, fighting off the spider webs I had already managed to grow since I last played with Rails. Eventually, I had a live URL to which I could tack a non-English feed's URL and get back (after a somewhat long wait...) a translated version of the feed, sort of.

Today, I spent a couple of hours cleaning it up, making things a bit more Rubyish, and writing down a little to-do list for the (hopefully near) future. It's far from finished. So far, in fact, that I won't publish the URL since even a bit of traffic could bring down the service altogether... I'll show you a screenshot, though, showing Frank's blog in Bloglines, translated through my feed translator service.

As I already mentioned, it's far from ready. There's no caching at all, which is the most pressing issue. I'll have to introduce some kind of a time-expiring cache in front of the translation stuff. Then, I'll go for implementing a conditional get. At some point, I'll probably add gzip compression as well. The translation itself isn't perfect either, but that's something I'll have to live with.

It's actually a bit prettier than the above screenshot would imply (it's old) but there's two rather big limitations that I (so far) can't get over: 1) the quality of the translation service I'm integrating with, and 2) encoding special characters (both for XML and for URL encoding). Better than nothing, though!

I'll keep you posted on the developments...

The Kawasaki method in 8 words:

"10 slides, 20 minutes and 30 point font"

Quote from Matt Raible's account from the Spring Experience conference:

I just spotted the following marketing blurt through testdriven.com:

[name of a build server product] helps software organizations reduce high risks of failures of projects caused by broken code base by delivering uninterrupted daily builds.

Yes! Finally! All of our software projects will be raging successes now that we have technology that builds our software automatically!

If you didn't spot the sarcasm...

It's not the tools that make continuous integration happen. It's the people. Even the most advanced build server can't do shit if the people don't integrate their changes continuously. Even the most advanced build server can't spit out a good build if the people have screwed it up.

This is not a bash against Parabuild. It could be a terrific build server. It's just that I start hearing these voices in my head when someone even remotely suggests that there's a new tool that somehow magically fixes the stupid humans.

Allan just emailed me an excellent quote by John Cage, an American composer of avant garde music that resonates with the software industry incredibly well:

I can't understand why people are frightened of new ideas.
I'm frightened of the old ones.

- John Cage

(via quotationspage.com)

If you've noticed that radio, the server this blog is running on, has been intermittently unavailable, you're not alone. There's been some stability issues related to a huge volume of spam piling up to a blog without the owner of said blog cleaning them up from time to time. This apparently led the web container eventually dying and would only start again with manual intervention. I'm not intimate with the details so I might be telling tales here, though. The good news is that the problem should now be history. Fingers crossed that doesn't happen again.

Once again, Glen Alleman is at it.

"My sources inform me..."

I recently heard a rumor from trustworthy sources that Accenture Finland is investing in training willing technologists in Ruby and Rails, and [wait for it] that they're looking for project opportunities where to apply said technologies. This can only be a good thing--if the big players are suggesting customers to use Ruby/Rails for certain purposes, that means us smaller players have easier time convincing those same clients about the value frameworks like Rails and dynamic languages like Ruby can deliver!

Here's my short account on XP Day 2005. I realize the conference was exactly a week ago and my blogging this is hopelessly late according to blogosphere standards. What can I say? Busy times...

Monday

Tim Lister kicked off the conference with a keynote that was both inspiring and entertaining--I wouldn't expect any less, of course. I had a chance to exchange a couple of words with Tim before the conference. It's interesting how all the "big" names in software development seem to have visited Finland in the early 90's but few are around nowadays.

I also talked with Tom Gilb right after the keynote. He mentioned feeling awkward being almost the only person in the conference wearing a tie. Tom used to work at IBM back in the "dress code days." I'm just glad they didn't have dress codes anymore back when I joined Accenture in Finland.

Somewhere along the way, I mentioned the ferry conference we've been talking about on the Agile Finland mailing list and Tom said he'd be delighted to attend. In fact, he wasn't the only one who immediately "lighted up" after hearing about the concept. We'll have to look into whether such a conference could be put together. It'll require certain legal stuff in place before we can commit to venue reservations etc. and coordinating registrations from two countries for what's essentially two separate cruises having some overlap is definitely going to be a challenge. We'll see.

This year's XP Day was also a chance to meet some virtual buddies in person. Clarke running a session right after the keynote made it easy for us to actually shake hands even though the plan about sitting down for lunch didn't actually realize. Maybe next time...

Next, I attended Rachel and Romilly's session on agile thinking tools. In practice, that more or less meant mind mapping. I've tried mind mapping before for structuring my thoughts on a topic for a presentation, for example, but I haven't really picked it up as a regular thing. There are really good things about the technique and I know some people who are actively using mind mapping at work. Maybe I'll give it a shot again, soon. Rachel and Romilly also introduced De Bono's concept of thinking hats. I'd heard of the technique before but hadn't really tried it out. It's hard. It really is. At least for me. But it also helps you bring out stuff that matters but that you'd otherwise missed. (Related: Simon Baker has posted pictures from the session)

I also happened to bump into Joe Schmetzer who recognized my name from having read my CruiseControl articles. It's always a pleasure to learn that someone has actually read my stuff and found it useful. Several people also mentioned recognizing my name from being "active in the XP list," which is a bit odd since I feel like I haven't posted more than perhaps 1 message a month during the past year or so. Too much stuff to keep up with. My gmail account says I've got 1800 unread discussion threads under the "XP Yahoo! group" label...

In the afternoon, Steve Freeman and Andy Pols did the "Getting to know your customer" session, which was a more or less direct continuation from Rachel and Romilly's topic of thinking tools. We went briefly through the cynefin sense-making framework, did a butterfly stamp exercise, and then moved on to Luke Hohmann's innovation games. A bunch of very useful tools. Some of them are arguably a bit "out there" and thus perhaps not suitable (as such) for all contexts, but they're certainly packing a punch and I'm sure I'll be able to apply some of the techniques in actually talking with our customers.

I also managed to meet up with plenty of old friends such as Giovanni, Brian, Fred, Willem, and probably a whole bunch that don't come to mind right now. After the official program, we headed to the nearby Mudlark pub where we had a lot of interesting discussion, catching up, and drinking free beer courtesy of Finetix. I also met Daniel Poon, a live Smalltalk programmer who's actually doing Smalltalk for a living. Nice. And obviously he insisted that I should pair program with a smalltalker for a day and I'd learn the enormous advantage Smalltalk has over other languages (or should I say platforms?). I'm afraid that won't happen until someone decides to start running a Coding Dojo in Helsinki using Smalltalk ;)

Tuesday

Tuesday started with a keynote by William Gaver, a designer from the Royal College of Art. He presented a different and very intriguing talk about how a group of researchers have explored new ways of fitting technology into our lives through innovations like "floating table", "terrence the dog", etc. While the topic was rather far from software development, I did see certain connections between what the researchers were doing and how, for example, the Cynefin model suggests we act to resolve problems identified in the chaotic sector. Andy Pols has posted some links and pictures featured in Bill's keynote.

The first session after the keynote was Tom Gilb's "Quantifying Any Quality". Unfortunately, I left Tom's session without really knowing how to go about quantifying any quality. Tom did demonstrate how he could work together with a customer (a volunteer) from a vague qualitative "requirement" (more innovation) for a project to something measurable (increase in annual income) through a process of reducing the qualitative requirement into the customer's "real" needs (money).

While looking at Tom work the requirements was enlightening in itself, the problem is that this transformation is only half of the solution--the other half being, how to measure the resulting quantitative metric of "increase in annual income?" This question was clearly in the minds of many other attendants as well and someone actually did ask Tom what to do while we don't want to wait for 3 months to get the accounting numbers. Tom's answer: on a weekly level, follow progress through "number of innovations".

In summary, it was fascinating and teaching to see Tom dig out the stuff that matters from the customer and how he organized his thoughts on paper while doing that, but I remain unsure about how to really quantify any quality in a meaningful, feasible, measurable way. Later on, I came up with a follow-up question I eventually forgot to ask: how would one estimate the effort for a project of which requirements are expressed as qualities (referring to Tom's story about a company that "stopped doing features")...

Tom was also busy burning cds full of stuff for the audience, including a complimentary copy of his latest book, "Competitive Engineering." I did make a note of taking a peek at his book (especially the chapter which talks about quantifying any quality) even though--and largely because--I didn't get that good a picture of the techniques involved from the session itself.

Next, it was time for a session titled "Agile is ready for business, but is the business ready for agile?" by the BNP Paribas crew consisting of Fred Tingey, Marc Kennedy, and Nick Price. Theirs seemed a very timely topic for me, considering that we're currently working with several clients who are either feeling pains caused by the bottleneck moving after adopting agile methods or who are asking us for help in making sure that there will be as little "pain" as possible (prevent pain from being created in the first place).

In practice, the value I got out of the session was something completely different. We split into groups, each group taking the perspective of a specific part of an organization and brainstorming the kind of obstacles that particular stakeholder can have with agile methods. It was a useful eye-opener, highlighting things that everyone kind of knew already but that everyone also forgets to think about, all too often.

After lunch it was time for a bit of storytelling exercise using Fit with Steve Freeman and Mike Hill. Steve and Mike started the session with a very enlightening simulation of a developer and a customer working through a specification on the flip-chart, effectively formulating an executable specification, a skeleton for a Fit table. I applaude the simulation because that sort of things really convey the interaction and collaboration better than any diagram or writing can.

I only attended the session half-way, though (because I wanted to jump to Kevin's Jidoka session which was scheduled to start mid-way through), and what I managed to get out of Steve and Mike's session before the break pretty much circulated around the discussions we had in our table during the exercise regarding how to present certain conditions/assertions in the test document. Interestingly (or not) we spend most of our available time discussing whether we should add a certain column or not or whether we should write two tables instead of one, essentially trading duplication for readability. Finally, we ended up going for no duplication (which wasn't really such a bad idea even though that must sound awkward coming from someone who promotes readability every chance I get)...

To finish off Tuesday, Kevin Rutherford ran a session on Jidoka, which is one of Toyota Production System's two pillars (the other being Pull). Unfortunately Kevin was suffering from a chest infection and that, in part, affected his output. Kevin did manage to present the core idea in Jidoka very well, though, through his excellent story about a silk factory in Northern England (don't pass on faults) and the magnificent Chinese Whisper exercise.

XtC

After Kevin's Jidoka session and a brief closing where a lucky Exoftwarean (Dave) won a free ticket to next year's XP Day in exchange for a feedback form, it was time to head out to the other side of the river, to the Old Bank of England, the place where all the important stuff goes down. Yes, I'm talking about the Extreme Tuesday Club.

Needless to say, perhaps, there was much talking involved. I talked splash screens with Dresdner folks (can you imagine two agilists bragging about their splash screens for trader apps?), I talked pizza with the Grenoble US-expat league, continued the Smalltalk/Ruby/Python/whatnot language discussion with Willem, Daniel, and a bunch of other folks.

Before getting thrown out of the club room (yes, the pubs still close at night even though legislation would allow 24/7 service), we talked with Willem for quite a while about workshops, coaching, etc. It's always useful to share, confirm and compare experiences. We also talked about drawing. Willem mentioned about a psychologists in the US who had suggested making a conscious effort in getting back into a "lost skill" such as drawing. The whole discussion actually started from the flyers Willem had put together for a workshop, using silhouette-style graphics to give some texture for the otherwise text-dominant content.

Throughout the night, I managed to mention a number of people about a certain rails app I started writing on the night before my flight to London, creating more social pressure for me to actually get it finished. We'll see. I haven't yet touched it since that initial 2 hours :)

Getting thrown out of the Bank, we continued to the after party with Willem and Marko since the rest of the bunch bailed out early. Can you believe that? They were pulling lame excuses about work in the morning... (*rolls eyes*) We had a bunch of fun, a lot of it having to do with subordinating things to the constraint along the way to a pub between Angel and King's Cross :)

Getting thrown out again, some time around 3am, we tried to continue to the after-after party at the hotel bar. Alas, it was already closed so there was no option but to get some sleep before the next day's challenges. After failing to convince Conan, Duncan and others to come with us, we realized that the core of the whole XP community in Europe is rather small and actually consists of two Dutch people and a Finn. Or then our metric was a bit off. Some have suggested it's the metric.

Wednesday

Wednesday started, not surprisingly, by sleeping late, missing the breakfast by more than an hour, and meeting up with Willem, Marko, and Rob at King's Cross a bit after 11 o'clock. Since all of us had booked late flights (although some less late than others), the plan was to spend the day together doing tourist stuff, a.k.a. having fun.

As you might or might not have guessed, we planned our day with user stories, of course, while eating a fat breakfast at a little breakfast/lunch joint popular among local bluecollars. Most of the cards we came up with were actually constraints rather than stories (e.g. "catch flight"). We didn't quite manage to finish all stories, although the most important features (getting everyone on their respective flights) were completed in time.

During the few hours we had before having to head out to various airports, we talked about the usual stuff geeks talk about (women, and C64 computer games), continued the subordinating theme, walked quite a lot (even though one of the constraint cards said "not much walking"...), and ended up sitting in a pub (who would've guessed).

Cutting to the chase...

Stories completed:

• Buy a double-decker
• Take a photo of a double-decker
• Buy a gift for a 1 1/2 year-old girl
• Buy batteries
• Have fun
• Catch flight

Stories not completed:

• Buy vanilla coke (don't ask)

It was fun. Can't wait for next year! Although I have a feeling time will fly...

Do I feel a Gordon Pask Award heading towards Brad Appleton's direction? Perhaps. But maybe not for this Agile Six Sigma stuff...

Here's an excellent project management quote from Glen Alleman:

Not that other domains don't but here PM is
a line function equivalent to engineering,
not an add on to keep score.

Charles Miller blogs about good Java developers vs. excellent Perl hackers--and which one should you prefer to hire on your team. Actually, Charles quickly swaps in Python for Perl, talking about a "merely good" Java developer versus an excellent Python developer.

What's funny about the blog is how Charles jokes about the Java developer having to deal with the Python developer constantly complaining how "whatever feature you’re working on could be implemented better in five lines of Python." I'm actually involved with a project that uses Python as well as Java, and I think it's actually me who complains about Python (I'm a Java guy by background) and not the other way around. Yes, you read that correctly.

Whereas Python being a dynamic scripting language and all is nice, I can't help but feel that it's a compromise between the power and freedom of Ruby and the rigor of Java and the like. Yes, the list comprehensions are ok but what the heck is going on with tacking that "self" everywhere? :)

I digress. Back to business.

So, in his blog, Charles also says something I can't help but quote verbatim:

A great programmer may not crank out features ten times as fast as a good one, but they still may have that much performance benefit overall. For me, what gives great the edge over good is some combination of: attention to detail, which means their features will be more completely implemented with fewer incidental bugs, attention to design, which means they’ll leave the code in a better state than they found it, and inspiration, where they will find solutions to a problem that simply wouldn’t occur to other programmers. All of these have really, really powerful flow-on productivity effects for the whole team.

Let me repeat the part that especially struck a chord with me:

Attention to design, which means they'll leave the code in a better state than they found it, ...

Amen, brother! There are plenty of "good programmers" out there who manage to crank out bug-free software and come up with smart solutions, but I'm always most excited about seeing someone do the dirty work--cleaning up after whomever happened to code that particular function--without giving it a second thought. That's the kind of "good programmer" I'd hire for my team. Whereas it might be a nice-to-have in some contexts, living and breathing refactoring is a requirement for an agile project to deliver working software week in, week out, sustainably.

I recently stumbled on this story involving a flight, an expired passport, and a fiance waiting at the destination. A scary story, which reminds me that I'll have to renew my passport which expires in less than a month. Last year around this time I almost missed a training gig because of an expired passport. Which is why I ended up getting a year-long "express" passport which is why I'll again have to queue for a passport in December with plenty of other stuff I could/should be doing...

Subliminal messages. What do you think of them? Do you feel they're ok? Do you feel they're immoral? Even though research has apparently failed to show that subliminal messages have any effect, I'd hazard a guess that most people consider the use of subliminal messaging suspect at best.

What if I told you that you're being affected by something rather similar to (but not the same thing as) subliminal messages every single time you speak with someone?

The clothes you wear, the perfume you use, the words you choose, the facial expressions you make, the movement, everything. All that stuff is essentially a more or less distant cousin of subliminal messaging from the "unconscious" recipient's perspective. And we do that all the time.

Is that a bad thing? Should we stop wearing clothes? Should we stop smelling good? Should we inject Botox to our cheeks once a week to lose those facial expressions? I don't think so. Do you? Does this make any sense? Why am I still awake at this hour? And why am I blogging about subliminal messages?

Kevin Lawrence's old post from 2004, titled Fight complexity with complexity, is a nice story about the value refactoring can create.

(via Keith Ray)

Clarke just posted a quote from a memorandum on what the Secretary of Defense calls "evolutionary acquisition". I'm still waiting for the day when I don't get surprised by how few people are aware of DoD's bias for incremental and iterative development that they've had for several years already.

Last week I shared a cab from the airport with a lawyer. No, he didn’t carry a pitchfork nor did he have a pointy tail. After some time the discussion turned to the lawyer describing what seems to me a textbook example of the dangers of local optimization.

The modern lawyer does almost everything via email. Disputes are arbitrated by sending email back and forth, making adjustments to an electronic document rather than a printed sheet, etc. People would only meet a couple of times during a typical engagement—once to get things started and once for signing the papers.

Now, before computers were the norm, lawyers would travel across the city (or to another city altogether) for a meeting with the opposite party’s representatives. They would sit in meetings for long times, making small adjustments one after another. At the end of the day, they’d go home with the signatures on the paper, having scrapped half a dozen printouts of intermediary versions throughout the day.

Looking at the efficiency of a lawyer in these two scenarios, there’s a clear gap between the two. The lawyer with a computer and email would make the adjustments in a fraction of the time it takes the old-school lawyer to perform the work, not to mention the time it takes to travel to the train station, sit in the train, etc.

Yet, the old-school lawyer is better off in many ways. Why?

As you may have guessed by now, the answer lies in local optimization. The "e-lawyer" is efficient in the little things but faces a lot of problems that the old-school lawyer is much better prepared to resolve. Here’s a couple of examples.

Communication

Electronic communication is, while easy, very limited in terms of bandwidth. Some studies have estimated that email, for example, loses as much as 85-90% of the information we’d be able to receive through direct, face-to-face communication. It’s all that body language, facial expressions, tone of voice, and so forth, that we’re missing completely.

This issue is highlighted in legal disputes, contract negotations, etc. highly "official" engagements where the context pushes us towards using toned-down language, fine-tuning our words to not convey any unwanted meaning. The problem is, that fine-tuning results in us missing a lot of useful information about the emotions, real feelings, and real needs behind the deal. As a result, people end up interpreting each other wrong, minor disputes explode into battles larger than life, and so forth.

One party might "win" big time while the other feels screwed (sometimes rightly so) and the partnership doesn’t get exploited to its full potential. It’s a win-lose situation at best.

Waiting

The other example of how the old-school lawyer is better off has to do with waiting, one of the seven big wastes in any process. And it’s not the kind of waiting that involves hanging around at the airport or train station. It’s the kind of waiting that makes us lose windows of opportunity, miss whole markets, scrap enormous amounts of investments, etc.

It’s the kind of waiting that happens between the email savvy modern day lawyer writing an email highly efficiently and actually getting a response from her counterpart. While it’s true that sometimes the other party might reply in just a few minutes, the more probable outcome is that the other party spends a good time reading the email word-to-word, looking out for a side-punch equivalent to the small print or whatever tricks those damn lawyers tend to pull.

That waiting—which happens a number of times during a typical negotation—is what makes the electronic communication such a bad medium for a lawyer to handle legal disputes. Whereas it would certainly be more costly (from a cost accounting point of view) to travel to a meeting in a remote location to refine a contract, the added costs are often overcome by the significant increase of chances of success in terms of reaching a win-win outcome and in a timely manner.

So, what can we learn from this?

No, it doesn’t make sense to claim that all lawyers should stop using email to do their work. Nor does it make any more sense to suggest that lawyers should do all their work through email. The whole point about this blog entry is to help you and me realize when we’re optimizing locally and hurting our bottomline in the process.

Next time you’re wondering whether you should just send an email instead of walking down the corridor, think twice. You might be optimizing locally.