Head On

Another thing: ThoughtWorks is sponsoring Agila Sverige 2008, and we have three tickets to give away. Send me an email or add a comment to this post if you want one.

Proponents of RUP, the golden methodology of 1998, is trying revamp it as OpenUP.

My first reaction is positive - browsing the Work Products I cannot find any required UML diagram. But after a while I get the feeling that they have fixed the implementation without getting the big picture.

It is still has four phases, delivering a feature complete project after the transition phase. No lean, incremental deliveries to production, but how could they? It explicitly defers deployment and operation leaving it to other parts of the organization.

But this is my favorite one:

OpenUP is minimal, complete, and extensible. It’s the minimum amount of process for a small team.

No, it is not minimal and it is not complete. It is less lipstick on the pig.

I was happy to note that Dion Almaer commented on my blog post on Merb. Dion is one of my favorite bloggers/podcasters and I value what he writes highly.

But I disagree with him on this one. The problem with using Java for web application development was never one of too much choice. In fact, it was because of that choice that Java became a player in the server side market at all. Sun alone never had the answer to what was needed for server side development, instead the open source world stepped in and made incremental corrections.

The same thing is happening to the Rails world. The core team cannot create a framework that is a one-size-fits-all. The initial Rails proposal is great for a large number of webapps, but it is other things around it like plugins and JRuby that is making Rails a viable choice for all.

My Java tools of choice was usually Tomcat/Jetty, FreeMarker, iBatis, WebWork tied together with Spring or PicoContainer. What I hated was having some frankensteinian-enterprise-architect-design-by-comittee-lets-not-be-different stack forced upon me with a fullblown J2EE server, EJB’s, Struts or the JSF monster, sprinkled with an Eclipse-only development environment. And I hope dearly that Rails development is not going the same way where people question you on your choice of tools and wonder why you are not using MySQL and TextMate like the rest.

There is one choice that I do not miss though - directory layout. I am truly happy every time I do not have to choose it.

Instead of not having to choose, the most important difference I’ve experienced is that Java as a language together with the Servlet/J2EE spec induces a lot of accidental complexity, which is almost non-existent in the Ruby/Rails world. It is that which enables the increased velocity many development teams experience when switching to Ruby.

I have used Rails on a daily basis for almost a year now, and before that I was a night time hangaround. While I am definitely a happier programmer using Rails than anything built on Java, I still feel that it can get better.

First of all I want more things to be plugins. And really, they should not be plugins at all but gems instead.

Why plugins? We use RSpec instead of Test/Unit, HAML instead of erb and are seriously looking into JQuery instead of Prototype. And of course, we are using Mercurial instead of Subversion. All of this is of course possible to use in Rails, but a lot of things are sort of made for the default choice, such as generators generating tests, and plugins having the -x switch for Subversion. And I am pretty sure that this is the way DHH wants it.

So, when 2.0 is now released, I see that the Rails community as a whole does not see the same problems as I do. If they did, they would have done more like the stuff above, instead of sexy migrations and ActiveResource.

This is where Merb becomes really interesting. I have looked at it before not understanding its value, but now I see a framework that does everything I want Rails to do. Gems as plugins and very agnostic about templating languages, Javascript frameworks and even ORM frameworks - almost a heresy in Rails. I will definitely think about using it instead of Rails in the future.

I came back last night after two great days of conferencing at Smidig2007 in Oslo, Norway. The mornings where all lightning talks and the afternoons where reserved for open space discussions. I gave a lighnting talk on the experiences we have had at WeMind trying to implement a lean enterprise, and I initiated two open space sessions, one on the GUI artists role in an agile process and the other on what makes different languages have so different communities and cultures. I will expand on those in later posts.

During the two days I had the pleasure of hooking up with Niclas Nilsson, Aslak Hellesøy and a bunch og other great people. It was very stimulating discussions and I am really motivated into doing a few new things with our own testing/speccing.

It was all in norwegian, so all you non-scandinavian speakers out there are really missing out on something - finally a reason to take that class in swedish or norwegian you always thought about.

Photos and a few deeper comments are due later, but for now: a big thanks to my norwegian friends for a great time.

I am subscriber of the Test Driven Development mailing list as well as the RSpec ones. One thing that strikes me continually is the lack of innovation and new ideas in the former one, as opposed to the flurry of brilliant ideas constantly coming out of the RSpec one. It seems to me that communities stagnate and that the people who once were the revolutionaries turn into keepers of their own revolutions ideas. The free thinkers become conservative.

Guy Kawasaki gave a brilliant keynote on the MySQL conference, talking about innovation. He said that the only way most people think about how to improve themselves is by using the tools they know more proficiently. No makers of horse carriages became car manufacturers. And the original TDD’ers are still talking about the same things they did five years ago. The revolution has moved on.

I just got an email saying that my lightning talk proposal for Smidig2007 was accepted. I will speak about the experiences we have had at WeMind when trying to run a lean enterprise.

I am really looking forward to this conference, it is all lightning talks and open space.

I was listening to the podcast of the interview with Steve Jobs and Bill Gates, and this one thing struck me. When asked to predict the future, Bill Gates provided some insightful guesses, while Steve Jobs simply answered “I don’t know”. Twice. Steve’s explanation was that five years ago he would not have predicted what we have today, so therefore he does not trust himself to say what the next five years will look like.

I have previously spotted Apple to be early agilists, and Steve’s position here enforces my claim.

One important aspect of grasping agile in my mind is to accept the fact that you cannot predict the unpredictable. Instead of making detailed plans to support the illusion that you know what is going to happen, you say “I don’t know”, but then let that knowledge, that you actually do not know be the base for how you approach your work.

I have many times been faced with the quest of predicting the future, “how long will it take?”. As I have become more experienced I have learned to say “I don’t know”, of course at the same time offering an alternative iterative approach that will eventually provide knowledge for better estimation. Sometimes that is not a popular answer, and the question is forwarded to someone who will answer it. Of course, they do not know, but the illusion of control is very powerful, so their answer is better received.

I guess that many CEO are pressed to predict the future, by employees, share holders etc. And many times they probably provide an answer that they themselves do not believe in. It appears to me that Steve Jobs does not fall into that category.

Mike Ratliff did a very good presentation on Fit/Fitnesse at Valtech Days. While praising the effects it can have on a development project, he also highlighted some of its quirks such as the ones I’ve complained about earlier.

The main point he made in my mind was when he said that Fit is not a testing tool but a requirements tool. It does not replace your regular acceptance testing tools. According to Mike, the main advantage Fitnesse brings is an increased, and executable, dialogue between customers and developers, and the possibility for customers to work with the spec in a “what if” manner.

I have been going over that thought for two days now and I think I really like it. And it makes me revalue Fitnesse, I definitely see the value of customers being able to work with the tests dynamically. I might just end up writing a blog post these days titled “Why I like Fit” :).

I’ll be traveling to Dallas, Texas this weekend to speak about agile documentation at Valtech Days.

I am looking forward to attending other sessions, the rest of the conference is looking really interesting. If you are in the area and want attend the conference, I believe there are still a few seats available.

From Revolution in The Valley:

Instead of arguing about new software ideas, we actually tried them out by writing quick prototypes, keeping the ideas that worked best and discarding the others. We always had something running that represented our best thinking at the time.

Alan Francis: Jobs, etc.: “[…] being an old-school XP-er who thinks Kent got right the first time and only dug a deeper hole trying to re-explain himself. ”

Well put. XP 1.0 is mostly brilliant, whereas the additional value of 2.0 could could have been published in a short addendum.

Kent Beck is probably the hero of the geeky part of my life and I am sorry to say that I find the quality of his work receding. Whatever he wrote or spoke about before, it was always empirically based and with a very appealing rebel touch. It seems to me that he is becoming more and more theoretical. For example, I found his keynote at XP2006 about “responsible developing” very abstract.

Let’s hope that the book he is releasing this fall proves me wrong.

(Via Planet TW - Alumni.)

I don’t like Fit. Believe me, I want to like it, I have tried to like it. I mean, Ward Cunningham created it for crying out loud, the man is a genius, so I am probably just missing something - right?

Every time I have looked at Fit, I always like the parts that handle column fixtures. They are clean and easy to read and generally does a really good job. Buth then we get to weird cousin Row Fixture which is not at all that easy to read and uncle Action Fixture which just won’t stop and finally family FitLibrary which does all good things but are utterly unreadble - which probably is due to my lack of experience, but then again wasn’t this intended for non-programmers?

Geoff Bache told me at XP2006 to look into FitLibrary and Erik Lundh suggested that I read the book on Fit. So now I have done just that, and I still don’t like Fit. As a language that is.

What the book did explain clearly, which I find the truly awesome part of Wards invention, is the idea of executable requirements written in advance. It is soo XP that you just have to love it. And I finally get why you should test the logic layer and not through the UI. Happy now?

But the book did not address all my concerns. It does not talk about the problems with version control; if you choose to work with Excel based Fit tests you will not be able to track changes as they are binary files. Neither does it suggest how Fitnesse pages are to be kept in version control. Also, all Fit formats are hard to follow if you track changes by commit messages by email.

The Fit syntax is in my opinion a table based DSL for writing acceptance tests. How many other programming languages do you regularly use that are table based? Excel? It is awesome for column based calculations which is the same as Column Fixtures, which I like. I alreay wrote that. But the rest is just … ugly.

A better solution in my opinion would be a Markdown based documentation format, where code formatted text, the indented one, is executed as tests just like tables in Fit. Could probably easily be turned into a Wiki if needed. For testdata I would use Yaml. Now if I could just find the time