I just learned about a new "web 2.0" start-up having launched. It's called edgeio and the core idea is "a classified listings system around content generated by edge publishers [...] giving individuals and businesses the opportunity to list content using their own websites rather than ceding control to a centralized service."

In other words, you tag your "anyone want to buy my old Powerbook" blog post with a "listing" tag and edgeio picks up your blog entry as a classified ad, aggregating it on their website.

We'll see how this fares against the real world.

Following my announcement earlier this month about my WeblogPublisher getting finally committed into the CruiseControl CVS, Jeffrey and Jerome just blogged about the said piece of work being in the 2.4.1 release. The documentation for the WeblogPublisher can at last be easily found in the documentation.

I'm consulting an unnamed high-tech company where someone once decided that it would be a good idea to pay millions of dollars a year for the second-worst version control tool in existence (the worst is called "no version control at all"). I don't mind company A being arm-deep in company B's pockets but I do mind the fact that the developer's life in company B is made a living nightmare.

For example, how long a time would you consider a reasonable wait for a seemingly simple operation such as "show me the version control status for all four text files in directory X"?

How does 30 seconds sound to you?

Enterprise?

Very.

Not to mention that it takes 4 commands to add a file or a folder under version control from the command line.

*Sigh*

Fortunately we've been able to adopt Subversion on some projects and there is some movement within the organization to make Subversion an officially supported version control system.

Might not mean much to the international audience, except perhaps the few Railers among us, but I just spotted what I imagine is the first mention of Ruby on Rails in the Finnish IT press, namely in an article on "Web 2.0" in the February 23rd issue of ITviikko. (Please correct me if I'm wrong)

Yes, Scott Ambler was recently interviewed by Floyd Marinescu on the upcoming Waterfall 2006 conference. Floyd could almost keep the poker face until the end. Almost.

Forrester Research:

One In Seven Enterprises Uses Agile, And Others Will Soon Follow

Jürgen Ahting:

"If you don't sell software to a mass market,
the economies of scope are much more important
than the economies of scale."

How about adopting honestly subjective performance reviews in your company?

Better? Definitely.
More laborious? I don't think so.
Worth a shot? No question about it.

Gmail displays random quotes on the top of my inbox and just now my attention was drawn to the quote (which doesn't happen often--usually I barely notice that there is a quote). The quote was by George Bernard Shaw, a well-known 19th century vegetarian playwriter:

"Take care to get what you like or you will be forced to like what you get."

What got me blogging about this little moment is that this quote immediately brought back memories from a previous employment where us lemmings were thrown around from project to the next based on what senior management decided behind closed doors. Ironically, when I once effectively sold a small 30-day project to a client--a project that I really wanted to do--management prevented me from going forward, offering another consultant to the client instead. It turns out the client didn't want someone else and the whole project was halted until a few months later when the client had hired someone qualified on their payroll.

In that organization, most people were effectively forced to like what they got. For some, that was all they needed and wanted. For some, that was frustrating. Some, myself included, made their best effort to get "in" to the discussions about forthcoming projects and to be able to affect the resourcing decisions. After a couple of years of projects and a couple of years of networking, all of this started to get a bit easier. Yet, even then it took serious effort to make sure you didn't end up in some godforsaken ERP system integration project with some CRM and B2C thrown in to give it some flavour.

I was able to get myself on some very interesting projects with that past employer but it certainly wasn't easy at times and, as you might expect, there were occasions where I had to endure periods of working on things that were hopelessly boring, maintaining something that was badly engineered, or writing software everyone knew was not going to create much value to the client (even though the client had a project manager tasked to make sure that the software was indeed built to spec).

I love the way I can influence what I do at Reaktor. I love being able to pimp myself to work on things I am genuinely interested in and to which I believe I have the most to contribute.

I just noticed that there's going to be a Continuous Integration and Testing Conference in Chicago this April. It's unlikely that I'll be able to join, Chicago being rather far from Finland and me currently not having clients in the US, but I wanted to spread the word regardless.

Joe Schmetzer, a nice Australian fellow I finally met face-to-face at last year's XP Day in London, replied to my earlier post about the presentation style I had used with a question. To paraphrase Joe's reply, the question was "How do I prepare such presentations?" and I decided to turn my reply into a blog post in its own right.

In general, I start preparing the slides just like I've done with any other technique I've used -- by drafting an outline or a "plot" and then refining and elaborating it, getting into smaller and smaller details. When I have an outline I'm satisfied with, I start a kind of a "slide simplifying" process where I condense the slides (which up to now have had bullet lists, quotes, prose, etc.) into one-liners. Bullet lists usually expand into a sequence of one-liners while other type of content often ends up being one or two words or maybe a full sentence if it fits on a single line.

During the simplication process, I "spell out" the sequences and try to do little tweaking, choice of words, etc. At some point, usually when I've got a presentation full of simplified slides, I start rehearsing. Repetition and speaking the plot through is the key to finding a way to communicate your message in a way that's understandable and makes sense, i.e. flows smoothly.

Rehearsing is also essential for keeping yourself within the allocated time for the presentation. With 10 slides, it's easy to remember things like "oh, I've spent 30 minutes out of 45 and I'm only half-way to my slides--I better pick up my pace" but with a slide count in the 3 digits, that becomes awfully difficult to do. It can be done, of course, but I find it much more effective to simply talk your way through enough times that you learn (by doing!) the proper degree of terseness and verbosity in your speech. "It's all about the feedback loop, baby!"

In this particular presentation, I had 150 slides and it took a little over 30 minutes to get through, translating to 12 seconds per slide on average. I did stay on some "essential" slides for longer than that while some slides I just ran through one-per-second with something of a lip sync. The actual presentation duration was within 5 minutes of what I had timed during rehearsals. Leaving almost 15 minutes for Q&A instead of the 10 minutes I had estimated, I was quite satisfied.

This Lessig-Hardt-Takahashi mix of minimal presentation style is not a cure-all, of course. It's a good fit for some occasions and not so good for others. In any case, it's a lot more entertaining (in the "not boring" sense) but also likely more laborious for the presenter than the traditional corporate style bullet points galore.

No, I'm not talking about such materialistic traits like salary. No. I'm talking about the monthly hits on this blog! January 2006 reached well over 115,000 hits (including aggregator polling, but still). The numbers for this month will be much less, apparently due to Simon upgrading our Pebble to a newer version with the accompanying changes in the way stats are collected.

More press for agile methods in Finland.

The result of a recent phone interview I gave to a Finnish business paper, Taloussanomat, apparently went online last week. If you've got the knack for Finnish, it's freely available on their web page with a snappy title, "kuinka ketterä olet?"

I'll just go ahead and translate a couple of "gems" for the international audience...
Please note that I did not say these things. Really, I didn't! :)

"We use the Scrum method from rugby where the team gathers together shoulder to shoulder."

"Agile software development means focusing more on people and interactions rather than on processes and tools. This creates better tools and processes."

At this point, I had to pinch my arm to convince myself that I'm not just making it up. And, finally, one more pearl for the swines:

"Agility is a synonym for Agile, and also an endurance sport for dogs."

All in all, I welcome the attention agile methods are getting but I can't help making a bit of fun of the kind of misunderstandings that seem to be inevident when interacting with members of the press over a phone line. Ironic, isn't it, considering the topic of my recent talk...

I recently did a relatively improptu retrospective for a client team I was visiting and something interesting turned up, as usual. The team had been running iteration retrospectives for several months and they had consistently identified the same issues in need of improvement.

I realize that this might not be surprising as such--after all, many of us have been trained to consider this normal by corporations doing their annual employee satisfaction polls where the employees complain about insufficient salaries and management decides to compensate by having fresh fruits delivered to the headquarters (where most people don't work) every Tuesday noon. Next year, the same complaints about salary come up and the same fruits are delivered, this time twice a week but in smaller quantities, etc. The real problem, however, remains (and it's probably something else than the salary) and most likely gets worse over time without getting the attention it so desperately deserves.

The problem with this specific team's retrospectives seemed to be that it had became too much part of the process rather than a way for the team to reflect upon their ways of working and, including but not limited to, process. Just like with the imaginary Big Bad Corporation doing what seems like polls for polls' sake.

Digging further into the apparent frustration, we established that while the retrospectives were run using a textbook group brainstorming format and while the sessions had always resulted in lists of things that went well, things that need improvement, things that puzzle us, and so forth, the resulting action plans were simply too vague to have much chance of actually getting executed. For instance, it's easy for a team to fully agree that "we need to improve our communication", it's not as likely to lead into actual steps being taken to improve the said communication as a more explicit statement of the required action would.

Project retrospectives are an invaluable tool for teams as well as individuals to learn about themselves and for the organization as a whole to evolve towards an even better awareness of our strenghts and weaknesses. Iteration retrospectives, however, have an additional and highly significant role in agile methods. Iteration retrospectives are a mechanism for an ongoing agile project to develop its process through the feedback loop the retrospectives represent. Iteration retrospectives are not just about what we'll do differently in the next project. They're also about what we'll do differently starting next Monday.

If you're serious about succeeding with agile methods, I'd suggest you invest the time and effort to run proper retrospectives and treat them as what they are.

If you haven't had the chance to experience a software project that employs extreme programming, this article by a game developer at High Moon Studios might be of interest. The part about going surfing during the lunch hour is a bit too much "rubbin' it in", perhaps, but otherwise it's a quite nice report.

Spotted via Clinton Keith's blog.

Ok. This should make right some of the wrong I did to some of you by posting a ridiculously small thumbnail of the edition of Tietoviikko we featured in.

Here's me on stage at the recent Testaus 2006 seminar:

Yeah, I know. It's still somewhat small, shot from behind the audience, and the colors are way off but that's the best their photographer could do.

Oh, and that slide right there is indeed representative of the presentation style I employed, inspired by the powerful style of legends such as Lessig and Takahashi. I got some very positive feedback. Still waiting for a more comprehensive (but less effective) feedback based on the organizers' feedback forms.

He did have an excuse, though. The same as mine, in fact. I woke up 5am today to catch a train to Tampere. 5am. That's 5 o'clock in the morning. zero-five-hundred hours. That's just brutal, especially considering that I was padded like a polar bear and still shivering from cold out there! Now if I'd only manage to force myself to head back to the hotel...

Hey, it only took 16 months of people hitting this blog from Google searches like "+cruisecontrol +weblog" but my first and so far only contribution to the CruiseControl project now seems to be in :)

Looking at what I had written brings up interesting notions about how my preference towards smaller methods has strengthened enormously since 2004. Part of the reason for the big methods (and the big class in general) in the WeblogPublisher was that I wanted to keep it all in one source file. In hindsight, I can't figure out why I thought it would be somehow inappropriate to introduce a subdirectory...

Maybe I'll submit another patch for a refactored version some day. Right now, I honestly don't have the time--I'm busybusybusy with getting my manuscript ready for the 2/3 review.

Oh, and if you're wondering what does the output look like from the WeblogPublisher, take a peek at my old postings from 2004.

The next coding dojo in Helsinki is on Wednesday the 8th and is again hosted by Reaktor. I can't make it this time myself because I'm not in town. Even more reason for you to sign up!

Could it be?

Seeing such a thing would definitely be a day of joy. Too bad that day of joy is still a couple of years ahead, at best, unless Sun is going to do something dramatic about their release cycle for the JDK...

Perhaps more than we'd think?

There appears to be quite a long thread going on at TheServerSide.com about whether or not agile development reduces the need for QA staff. Apparently it all started from Floyd Marinescu's blog entry about what Scott Ambler had said in his presentation to the Toronto Association of Systems & Software Quality.

The TSS thread has a lot of FUD flying around, although Dave Rooney and Scott Ambler seemed to be doing a pretty good job at keeping it real. Scott's description of what he actually said in his presentation can be found from this post near the middle of the discussion thread.

We sort of touched on this topic yesterday in the closing panel of Testaus 2006 as well. I really do believe that good professional testers are worth their salt also in the context of agile development. It's the grunt work of regression testing that test automation, for example, off-loads from testing staff and the time savings automation yields on regression testing can be used for more productive and more exciting work--the kind of stuff we're actually better than the computer.

Also, the change is not going to be quick. There's plenty of learning to do and, frankly, not everyone is into that sort of thing. In the meantime, some organizations are able to get an edge over the competition with effective test automation and skilled testers with a smart mix of approaches such as context-driven and session-based, exploratory testing techniques. It's those organizations that are both creating better software and doing it faster.

As you may have noticed, the blog software at radio.javaranch.com was upgraded recently and we're now running on version 1.9.1. In practice, that means some new features (like the tags link right under the blog title) and, what's even better, less spam due to the nifty little captcha implementation Simon threw in as a bonus. For you, my dear reader, that means you'll have to answer a simple math quiz when you're posting a comment on my blog. I'm hoping this will finally get rid of the link spam I've already gotten used to removing every day...

I've been running a private Subversion repository on my DreamHost account for some months already and, finally, today they announced in their customer newsletter the official support and a one-click installer for Subversion! That means being able to access your repositories over HTTP from practically anywhere.

Hooray!

<plug> if you decide to sign up for an account with them (for example, to run your Rails apps;), please consider entering their site through this link. It'll shave off $50 from your first bill and contribute almost $50 to the hosting of agilefinland.com </plug>

I presented today at the Testaus 2006 seminar on the topic of collaboration and how to foster it. It really was a pleasure to present there because the venue (Wanha Satama conference center) has a good infrastructure in place. The portable mics actually worked, no circulation, the projector not blinding the speaker, and so forth. The presentation itself went quite ok as well, with only a couple of minor glitches with my slide sync (I used a Lessig-inspired technique this time). I had to skip the cocktails afterwards, though, because I'm in the process of finding a new home for myself and there was a promising apartment on display which I wanted to check out.

The next time you'll have a chance to catch me on stage will probably be in 4 weeks on the 1st of March when I'm talking about quality at the Merito Forum seminar titled Agile Software Development Practices.