Jeffrey Phillips talks about him belonging to the prototype-oriented quick and dirty camp rather than the flesh-it-all-out-as-you-go camp.

Where I think Jeffrey fell off the sled a bit was the "dirty" part. What he describes as the benefits of his innate approach (failing early and learning from it rather than failing late) is almost synonymous with risk-driven, incremental development. That is, he could be talking about pretty much any agile method.

Except that he said "dirty."

It's easy for organizations to jump on the agile bandwagon and get all the benefits of quick-and-dirty. It takes a more thorough understanding of the discipline and craftsmanship needed to go beyond quick-and-dirty and into the realm of truly sustainable agile development. The world of quick-and-clean.

Yes, adopting agile methods in certain environments can be harder than you'd hope. You're surrounded by people who don't really understand what you're doing and why, even though you've tried to explain them more than once. Perhaps the most dangerous moments of the adoption journey is when those people think they get it but have really gotten it slightly wrong, sometimes leading to failure. Like in this case.

:)

Bill Waddell in a blog post over at Evolving Excellence yesterday wrote a paragraph I'd like to highlight:

American companies, particularly GM where the ROI concept was elevated to an art form long ago, do not put market share or cash flow at the top of the list. They measure themselves by Profits and ROI. With inventory as an asset and full absorption accounting allowing them to take overhead costs away from the profit calculation and park them on the balance sheet in the inventory account, an opposite set of management practices makes sense. Instead of eliminating the waste of setup time and defects, the numbers are better (at least in the short term) when you simply amortize them over big batches of production and move the cost out of the profit calculation.

The above paragraph brings up the advantage throughput accounting has over traditional cost accounting by putting the spotlight on the deficiencies of the alternative which encourages local optimizations all over the place while failing to foster investments that would yield a much better payback.

Jim Shore's most recent blog entry in his change diary contained a hidden gem:

I heard an interesting definition of "introvert" and "extrovert" once. I don't remember where. The definition went like this: for an extrovert, socializing with strangers boosts their energy. For an introvert, socializing with strangers drains their energy. Sounds right to me.

That's one of the best definitions I've heard for the difference between extroverts and introverts.

What we could think of as "energy levels" with people at work is not something to dismiss off-hand. A modern day (read: live and breathing) philosopher once mentioned that we would be wise to acknowledge how we can affect other people's energy through our actions if we want to support a smooth, effective working environment. Poking a coworker in the right way at the water cooler could uplift him energy-wise for the whole day while rubbing him the wrong way might do the opposite--with dire consequences to the project's progress.

Small things matter. Do you remember an occasion where someone gave you a small compliment and that was all that was needed to make you feel like a king for the next couple of hours? Is there anything preventing that from happening at work, every day, for everyone?

I recently presented at the Ohjelmistokehitys 2006 seminar. My talk was about Lean Thinking and its application in the context of software development. I'm not going to blog about my talk, however, (even though it went quite well--I love talking about lean ideas) because what really got my juices flowing was the ending keynote right after my set.

The keynote was given by Mikael Honkavaara, the CEO of Hybrid Graphics, a small group of Finnish "elite ninjas" in the field of embedded graphics (with a background in game development tools and graphics engines). In short, Mr. Honkavaara's presentation was top-notch. I'll try to extract a couple of things from the actual experience that I believe had perhaps the biggest influence on me receiving the presentation so well.

First and foremost, I heard a story. The presenter told the story of Hybrid. Moreover, he told a story of the company as a living thing, a family. It was concrete and personal. Mr. Honkavaara pretty much stripped himself naked as a presenter, speaking directly to the individuals in the audience rather than delivering The Message.

Second, I could assimilate with almost everything that was told of Hybrid's culture. From their recruitment policies to treating employees with respect to the way they party, I could nod to myself and say, "that's just like with us."

I'd also like to highlight one specific aspect of the presentation's content. The fact that Hybrid recently cashed out through an acquisition by NVIDIA is something many "corporate" presenters would naturally levitate towards as the main focus or grand finale, especially for a presentation titled as a "success story". That's not the story I heard. It was part of the story, yes, but--and rightfully so--an insignificant part. Far more important, for me at least, was to hear about a group of people dedicated to being the best they could be, supporting each other and not giving up their ideals even during the tough times.

The fact that the story had a happy ending really didn't matter.
The value was created during the journey.

So Apple today launched the 17-inch MacBook Pro as expected. No surprise there. Unfortunately, because the rumor has it that Apple will dump the 12-inch "pro" model for good. In other words, there will probably not be a 12-inch MacBook Pro. Well, we'll see how the 13-inch MacBook "student" will turn out. It's just that if Apple would've released a 12-inch laptop with a relatively high resolution, they'd have my money by now...

Soooo... I've been laying low for a while. Partly due to myself having caught a bug. The kind of old school type bug. The keeps you in bed without energy to focus on anything productive for several days kind of bug. Luckily I got over it just in time for a training gig for a small team of four. We're halfway through the training and it's going pretty well, I think. The participants seem to be enjoying themselves and learning in the process. We'll see what they're going to say about the dreaded legacy code exercise! Har har har...

In other news, the program for XP2006 is live so I guess that means I can try to lure you into the session we're running together with a fellow Reaktorian, Markus Hjort. It's a 3-hour activity going by the name "Coding Tournament". It's really not a tournament, though. It's going to be more like, oh, I don't know, the best time you've ever had in a conference ;)

Keith Ray posted a link to an excellent write-up where the author talks about developers thinking that writing code without tests is faster and comparing that to what he calls "process addiction."

Here's the link: Break Your Process Addiction

Jonathan Kohl blogs about the dangers of reckless test automation. He's right on the money and I strongly recommend reading what he has to say.

One thing I'd like to highlight is that the source of the problem is not "100% test automation" itself but the interpretation of it. I haven't heard a single agilist I consider knowing his (or her) stuff say that the goal should be 100% test automation and 0% manual testing. What I have heard people say (and what I've said myself as well, from time to time) is exactly what Jonathan is suggesting: that all regression tests should perhaps be automated but that context-driven, risk-based, exploratory manual testing should be carried out in addition to the automated tests.

Computers are good at finding bugs we told them to look out for. Humans are excellent at finding those we couldn't see coming.

A study by the U.S. National Institute of Mental Health and Montreal's McGill University has found out that "smarter brains are more agile, not bigger".

There. Scientific, medical proof that you become smarter if you use agile methods.

And here's the smiley :)

I ran a serious after-hours hack-a-thon on Sunday this past weekend. The result of which is now a Sourceforge project named JspTest. Here's the short description from the Sourceforge summary page:

JspTest is a JUnit extension for testing JavaServer Pages (JSP) outside a J2EE container. Internally, it uses the Jasper JSP compiler from the Jakarta Tomcat project and the Java compiler distributed as part of the system's default JDK.

We're talking about real unit testing here, not integration testing against code deployed on a web container like is the case with many web-related "xUnit" libraries.

In other words, it lets you write unit tests for your JSP pages like so:

import net.sf.jsptest.JasperTestCase;

/**
 * Unit testing JavaServer Pages has never been this easy!
 */
public class HelloJspTest extends JasperTestCase {

    protected String getWebRoot() {
        return "./websrc";
    }

    public void testRenderingIndexJsp() throws Exception {
        get("/index.jsp");
        assertPageContains("Hello from Jasper");
    }

    public void testRequestAttributes() throws Exception {
        setRequestAttribute("who", "You");
        get("/say_hello.jsp");
        assertPageContains("Hello, You!");
    }
}

The good news is that there's no servers to start up (not even lightweight ones) and once a given JSP source file has been compiled (seems to take around 1 sec per file), further tests rendering that page with different request attributes etc. will execute blazing fast--just as if you were invoking a Servlet class directly (because you are!).

It's alpha and needs a whole lot of improvement (not least in terms of the API and extension points, not to mention missing built-in assertions) but it works alright for what I've used it on. What's in version control right now is based on a spike I did (I actually named the original Eclipse project as "JasperSpike") at figuring out how to use Jasper. As a result, the class hierarchy will likely evolve quite a bit in the near future. Also, I've only got a couple of acceptance tests in place because I was mostly just hacking to get Jasper's peculiarities sorted out for myself. That'll have to change if this thing takes on a life of its own.

There's no release, yet, (not even a development snapshot) so if you'd like to take a closer look you'll have to resort to doing a...

svn export https://svn.sourceforge.net/svnroot/jsptest/trunk jsptest-snapshot

...and (because I haven't yet written a build script) importing the "jsptest-snapshot" directory into Eclipse in order to export a .jar file.

PS. I am aware of the JSPUnit project at Sourceforge and that the first Google hit for "jsptest" is an existing open source library with the same name as my stuff. The thing is, both of these are effectively dead and haven't seen any real activity in years. They're basically inferior implementations of a subset of what projects like HttpUnit, jWebUnit, HtmlUnit, and Canoo WebTest offer to thousands of users worldwide.

Lask week, I saw an article in Tietoviikko on agile methods, including among other positive notions the following quote (my translation) in the context of VTT's research and the adoption of their Mobile-D methodology (an agile method created at the VTT for embedded software development, if I remember correctly):

"The results are so significant that they can increase the need to move software development work back into Finland due to the reduction in cost of development."

As sugar on top for my late evening RSS feed reading session (which took a bit longer than usual because I've been offline since Thursday), the article also mentioned us as a company having "developed agile methods" in Finland.