ZPlanner!

I've been using variants of Scrum for a number of years now. Now, the topic of what does or doesn't qualify as Scrum is worthy of a blog itself (and it'll get one, trust me), but this blog is about something else, namely toolsets.

I've tried the notecard things a few times, but I always end up coming back to software solutions to manage stories and tasks. And in most cases the companies I've worked for have not been willing to put up the coin to buy an 'enterprise' solution, such as VersionOne or ScrumWorks. Those look like nice, though in the case of VersionOne overly complex, products. Mostly I've just used XPlanner XPlanner as it's free, open source, and relatively easy to set up and use.

But XPlanner seems to be dead at this point. There doesn't seem to be an active development and the last release was almost two years ago. I honestly think it's works fairly well, but I do think it has a number of shortcomings

• A story can't be turned into a task and a task can't be turned into a story. It's often the case that you initially defined something as a task, but you realize it's actually a story (or vice versa). You have to delete the original item and recreate it as the other type, you can't just *move* it.
• Moving tasks amongst stories and stories amongst iterations uses a huge dropdown of all items within your product
• There is no backlog. You can get around this by creating a fake iteration, but it's kind of kludgy
• The way in which estimates/burndowns are tracked over time is confusing

There are a number of other things I dislike, but primiarly they all stem around the klutzy interface. Something that mimics more closely the ease with which one can move around notecards would be great.

A few months back my company was going through a re-org. I found out that there no long was a position for me and being a bit nervous about my future, decided I better start brushing up on my programming skills. After all I've been a manager now for a few years and after trying ot think of something useful to motivate me to start doing a bit of programming again, I decided I'd try writing my own version of XPlanner, fixing all the things I thought wrong in the original.

Since it was mainly started as a project to refresh my programming skills, I decided to try a few new technologies just to get familiar. At the same time I didn't want to just use a technology for the sake of using it. In the end, the stack I ended up with was:

• Stripes
• DisplayTag
• JQuery/Ajax
• Maven2
• Hibernate Annotations
• Mercurial
• Cobertura
• HSQL (for unit tests)

My goal at all times was to keep the code as simple as possible. To this end I did most of my work using TDD, even "breaking" sacred rules of coding if it seemed like the simplest solution. For example, both Stripe Actions and Hibernate domain objects use annotations. Since in my first case the action and the Hibernate object has the same field, why not have a single file with BOTH sets of annotations? My Stripes action and Hibernate file the same code? What?!? You can't do that!

Well, I did.

When my design started to get kludgy, only then did I split them out. Similarly, I didn't abstract much of anything to start with. I didn't think out my class design in the beginning. I just coded the simplest possible thing I could.

Using this appraoch, I actually had a working application in which I could enter stories and tasks (even with ramping up on 5-6 new technologies) in about 40 hours. Of course, I've subsequently spent quite a bit of time refactoring, rewriting tests, adding more functionality, and most of all futzing around rather hopelessly in Ajax (I suck at front-end development).

Still, I've probably put in a total of 150-200 hours of work and have learned quite a bit. And I actually have a "kind of" working application. It still needs a ton of work, but it's getting there.

Screen shot of app and Ajax-based drag-n-drop inteface:

See how few files there are. Very few config files either:

Cool dependency graph courtesy of Maven2 and Eclipse plugin:


Cobertura test coverage report:

Why the programming language you use should be the last thing you worry about

As I’ve mentioned before, I don’t really do much coding at work. Most of my time these days is spent greasing the wheels of a soul-crushing bureaucracy with my blood.

Well, that and attending meetings.
They are of a piece.

But occasionally I do still delve into slightly more technical stuff. Mostly it’s on my own time, but recently I’ve actually been learning a little (gasp!) while at work. I recently moved over to managing a new team. My old team used Java. My new team uses .net. I’ve never done any dev in .net so I decided to pick up a book, crack open Visual Studio and try to make myself a little less clueless.

The key word being ‘little’. As a manager, I feel it’s my duty to be mostly clueless. Otherwise, what do the developers on my team have to bitch about privately?

It’s been awhile since I’ve used anything Microsoft-related for coding. In fact, my last professional experience was using VB at my first job back in 2002. Before that I used Microsoft’s VC++ for some time during school.

Now having been primarily using Java the last few years, this is where I’m supposed to start whining about the lack of checked exceptions in .net or the way it uses “:” instead of ‘extends’ and ‘implements’ to denote that a class derives from another.

The problem is this, though: I don’t care.
It doesn’t matter.

None of the differences matter. Or at least they don’t matter relative to having good code. You see, the thing is, I’m more and more convinced that about 90% of all code just flat-out sucks. In light of this, I’ve come to the conclusion that the choice of language is largely a triviality.

Now, don’t get me wrong. I’m not disputing the assertion made by Sapir-Whorf that language affects how we think and solve problems. In Java, everything’s an object. This does have a lot of implications (good and bad). But you can write equally crappy code in an OO model or a functionally decomposed model. One may fit your paradigm, but neither precludes having a good implementation any more than the only one guarantees an elegant solution.

I’m not saying writing in 80x86 assembler is just as good as C#. It’s a snap to do text-parsing in Perl, whereas it basically sucks when you have to do it in Java. That said, I still maintain that the language you’re using is towards the bottom of the list of: things to worry about ™.

At the place I worked prior to where I’m at now everything ran on Apache mod Perl. When I started I had never used Perl and I immediately took a dislike to its simplistic, loose typing and lack of a spiffy IDE. In fact, when I was made technical lead on a new, high profile project, one of the things I and some other members of the team pushed for was that we should switch to Java.

Oh, Java has strong typing. There’s Eclipse. It has integrated unit testing. Developers will be easier to find (We were having a hell of a time finding good Perl developers). There were any number of reasons to make the switch, none of which I regard as completely wrong now. The thing is, though, it didn’t make that big of a difference.

Shortly after we made this decision we brought in our first batch of Java developers . I explained to them a bit about the project, gave them an initial implementation I had written of what they were to develop more fully, and set them loose.

They came back two weeks later with a train-wreck of obfuscated, hopelessly overcomplicated code. And it didn’t even really work. My boss after looking at both sets of code suggested we toss what they’d done and begin again using my initial prototype.

Of course, we eventually got rid of the people who’d written the code, but we kept soldiering on in Java (we did use Perl for some things). A year later we had something largely workable and a new “architect” was brought in to assess our work.

His first complaint: this isn’t in Perl. Java is not a dynamic language and doesn’t have closures. This should be rewritten in Perl.

Of course, that first craptastic implementation wasn’t the fault of Java. Any more than some of my frustrations with our old code base has been the fault of Perl. They were implementation details. Whatever we did wrongly in Java, I’m sure it would have been equally wrong in Perl. Maybe in different ways, but still wrong.

Worry about the code foremost. If you already have that nailed, then, maybe you can start worrying about what language it’s in. I haven’t seen many people get past that first step, though.