skizz.biz

Yesterday I had the best night bus experience - I caught the N38 from Charing Cross Road after the TW Christmas party, and there were (as usual) quite a few people on the inebriated side. In particular a couple of rather jolly lesbians who were trying to gee up the bus - which was packed as usual. Anyway, they started up a banter with another inebriated gentleman on the bus, and before long they had started singing Christmas Carols. And then the rest of the bus joined in. And we sang progressively sillier versions all the way back to Balls Pond Road.

I think my favourite was Partridge in a Pear Tree, which no-one could remember the words to, so it ended up going something like:

On the fifth day of Christmas my true love gave to me:
Five go-old rings,
Four na na na na
Three na na na na
Two na na na na
And a Partridge in a pear tree

It was very cool. Sometimes I do love London.

Some time ago when Mike was in London we had a bit of a hat about using JIRA as a tool to manage agile projects. We could enter the cards as issues and then you would have happy management. Develpers would then pick up the cards from JIRA instead, and work on them.

But of course we don’t work that way. Its ironic that we are developing sophisticated software systems using index cards, but they have some very important advantages over issue tracking systems and other electronc management tools.

• Cards are concrete — well paper actually, but what I mean is they can be shuffled, passed from hand to hand, shoved around the table, placed in piles, crossed off or even torn up.

• Stuck on the wall they are visible — and when you place a big bold cross on them you can easily see how many you have done.

• A pile of cards on the todo pile gives visual cues of the amount of work left — big pile or small pile.

• You can stick task cards under the story cards to which they relate.

• You can staple related cards together

• you can move cards into different areas to indicate different priorities — in our project higher up the board means higher priority

• different areas of the board have meaning — ‘ongoing’ cards and ‘targets of opportunity’ each have their own area on our board

All good reasons to use cards. But I got to thinking about it, and there’s nothing there that you couldn’t actually do in code. And if the paradigm (ugh) works well for cards, why not for other things?

Imagine a “surface” with a set of “things” — little boxes with text in them or whatever. You could associate an axis on the screen (say the y axis) with an attribute of the “thing” (say priority). Then dragging the “thing” up or down the screen would change the priority of the thing itself.

Or define a “region” of the screen to be associated with a particular value of an attribute — following the story cards idea lets say that you have a region for each iteration. Then dragging a card into that region would set the iteration on it.

But of course the “things” don’t have to be cards. Say you are managing a unix system with many processes. Dragging a process up or down might change its priority.

And such a system could layout the things for you — so if you went into some other system and changed the card’s priority and came back to the visualisation, then the card should have moved.

So I guess what I want is a generic visual layout engine that lets me do this sort of thing — almost a two-way dot

Does anything like this exist or am I going to have to write it? :-)

I love Ruby. Its elegant, simple, clean, powerful and dynamic.

Python is pretty cool too, but its not as good as Ruby — its OO support seems ‘tacked on’ — I mean passing around self references? Come on!

But developing in these languages is nowhere near as good as in my favourite dynamic language — Java. Or rather, Java+IntelliJ.

Huh? Java is not a dynamic language is it?

Well not strictly, no. But in terms of the way that I develop — using IntelliJ to help me code — it might as well be.

If I were developing in a text editor with only a little support for the language, then Ruby would win hands down. I can create properties (getters and setters) really easily, things like the command pattern, implemented as Runnables in Java are elegantly expressed as blocks in Ruby. All of this is way cool and very very productive.

But I can’t refactor automatically. I can’t even rename a class and be sure that all references have been changed. And I won’t find out until runtime. Search and Replace just don’t compare to a Rename refactoring — and don’t even get me started about Move.

I am more productive in Java+IntelliJ — because the combination makes up for Java’s verbosity.

And that’s my point. Good code is not about using a smaller number of lines to achieve a particular piece of functionality. It is about how efficient and easy it is to maintain that code, to refactor it and keep it lean and simple. And that is much more dependent on the tools that you use than it is on the language you use.

Of course by ‘tools’ I don’t mean wizards and drag and drop abominations like Visual Studio or JBuilder. I don’t want a clippy that thinks it can write code better than me. I want a tool that helps me write code, so that I don’t spend valuable brain time writing code that is obvious.

The best way for a tool to present code to me (the coder) is as code. Isn’t that obvious? I don’t want to have to learn a new language (the language of yet another GUI bean wizard for example, or yet another GUI UML refactoring tool) to do something as simple as creating a getter or setter. In IntelliJ I just type x.getFoo() and press [Ctrl-Enter] and it does it for me. No guis, no mouse, nothing to distract me from the code.

Working with a tool like that is a joy — a tool that helps me write code efficiently rather than trying to write code for me. And that is dynamic code.