chris clarke

Iteration Planning - What I’ve Found Works Well

I’d like to share the method of planning that I’ve evolved because I’ve found it works quite well and better than anything else I’ve tried so far. Note: this is used for planning what will go in the next iteration or sprint and not for release planning.

I take two iterations worth of upcoming work (you may call your upcoming work a Product Backlog) prioritized by the customer and get the team to break each story/feature in to smaller tasks that they are comfortable with. I then get them to estimate each task in days. Some people like to estimate in Story Points or Jelly Beans, other people like to estimate in Ideal Days (a day where no-one is off-sick and there are no meetings or interruptions). I’ve found that for estimating, Plain Old Normal Days work best - developers tend to find it confusing what Story Points mean and they find it difficult to compare stories from one iteration to the next and in relation to each other. Its much easier for them to think in real units of time because thats just how they perceive things in their heads. (Note: I also tend to use Planning Poker cards - so that ALL the team get input on the estimate and they don’t let other peoples estimates affect their own). As you read on, you’ll find that I take these day estimates and treat them as points - as in “the team completed 18 days of work last iteration” - which doesn’t mean they worked for 18 days, but that they completed what was estimated as 18 days (the iteration itself could’ve been a week).

I’ve found nothing beats velocity based planning. The velocity is the average number of days the team completes in an iteration. So say the velocity is 20, I know I can probably fit 20 days worth of work in the next iteration. (Note: Don’t think you can fit just a little bit more, treat it as a hard limit. Think you can fit 21? Don’t do it!). The reason why I estimate two iterations at once is to give the customer a little flexibility - lets say we go in to a planning session with just one iteration to plan and we come out with two stories, one is 6 days and the other is 8 days but our velocity is only 10 (8 + 6 = 14. It ain’t gonna fit!). So having estimated two iterations it gives the customer the option of shuffling some stories around from the other iteration to get a good fit (perhaps another story comes out as a 4 or a 2 - perfect!).

The other important thing that I do is allow a bit of Slack, and by that I don’t mean I let the team be a bit lazy, put their feet up and watch TV all day. I mean allowing for a bit of time in the iteration, maybe 10%, maybe less, which is just there for flexibility. Maybe the time will be used because we underestimated a bit this time round, maybe it will be used to do some long needed refactoring, maybe there’s a whole stream of unexpected support problems this iteration, maybe the team will use the time to make some changes to go faster next time… I was born with a brain that likes efficiency and likes to fill up and make the most of every unit of time so the idea of Slack didn’t really feel natural to me - but hey it works great - I recommend the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Another good book, about planning, is Agile Estimating and Planning.

That’s it. Getting the customer to prioiritize stories and agreeing to shuffle them around is the hard part.

Outsourcing My Own Project

I’ve decided to outsource one of my own pet projects, I just don’t realistically have enough time to work on it but I would still like to see it come to life. I’m using a site called RentACoder to hire a developer to do the coding. I don’t really know quite yet how I’m going to run it, I’ve started by writing some acceptance criteria, and I’ll be testing it myself by writing some automated acceptance tests. Ideally I’d like to give these tests to the developer first but I’m not really sure how all this RentACoder stuff works yet - should be a fun experiment!

One of the more interesting things about starting a RentACoder project is the options they present to you regarding time of delivery:

I’m sure we’ve all been on one of those Option One “Project must be delivered in X days” types. I’ve been lucky enough to be on a few Option Two projects and even a few Option One projects where we’ve negotiated what will be delivered in X days and in what priority. As my project has no deadline and I don’t want my Programmer-For-Hire to rush and reduce quality in order to meet a deadline, I plumped for Option Three.

I quite like the question regarding Managing Coder Estimates - its like your signing up to a contract agreeing that all programmers underestimate by either 2 or 5 times!

Compiler Warnings

This post about Compiler Warnings made me laugh.

Ignoring Common Coding Practice (why you should be too)

Simon Baker wrote a quick blog entry on Common Sense and Common Practice. It hit home with me because recently I’ve been pairing with developers who find it uncomfortable coding in certain ways because it doesn’t fit with Common Practice. A lot of code I see, whether it be reading a programming book, looking at some code I Googled, or looking back at the way I was taught at University, is really just a bit rubbish in my opinion. It works okay, and I’m sure a computer can understand it, but as a human I find myself struggling a bit. Typically the code seems to be telling me how the computation is taking place rather than what it is doing. Sure, you need some how code but put it behind a little what code and give me a chance.

Anyway, enough passive-aggressive blogging, here are some things that people tend to find uncomfortable and perhaps why they shouldn’t:

Long names

Long descriptive names seem uncomfortable to people because you don’t normally see them in Common Practice. I think they help because it’s much easier to see what’s going on without looking in to the details of the languages implementation and its easier to find code that already does what you want.

Extracting composed methods that don’t remove duplication

Before:

After:

People seem a bit uncomfortable with this refactoring because they think it doesn’t achieve anything except adding more code. Sure, no duplication has been removed but its now much clearer what the public method does without having to look in to the imperative details of how it does it in the private methods. I can now understand this code at a glance after splitting out the two things that were happening inside the loop and as an added benefit I was able to remove some comments by naming the methods well.

Creating classes to express your domain

Ivan Moore and Keith Braithwaite ran a workshop at SPA 2008 on Programming as if the domain mattered which inspired me on this one.

For example, if you are writing a Banking application, you can create classes that express familiar language in Banking.

Without domain classes:

With domain classes:

I’ve found people are put off by this domain language because a lot of the classes involved don’t achieve much, you’ll have to imagine a lot of them for yourself but for example the Money class could start life as pretty much a wrapper around a primitive:

Another argument against is that it increases memory footprint - and hey if that’s really really (come on is it really?) important to you then just use primitives.

Be Brave

I wish people would be a bit braver and use the code to express what they are trying to do and not worry about whether the way they are doing it is against Common Practice. Remember, the majority of software projects are still failures, so why follow Common Practice - it isn’t working!

Using an SVN client with Team Foundation Server

Tim Goodwin blogs about SvnBridge. Its a tool for being able to use Subversion clients with Team Foundation Server. I quite like the idea of creating good interfaces to bad systems, however it would be much easier if people stopped making bad systems.

Mocking Concrete Classes in JMock 2

In JMock 1 you extended the cglib version of MockObjectTestCase but in JMock 2 its different. You need to change the Imposteriser used by the Mockery:

Find which process is listening on a port

To find which process is listening on port 22:

Find out which port a process is listening on e.g. httpd:

Or by PID:

lsof can also be used to find the files a process has open. To look for where httpd writes it’s log files:

Unix stuff

If you work a lot on slow Solaris boxes, you can speed up finds a little bit:

The depth option looks at the contents of directories before the directory itself and the ‘type f’ constricts the find to only look at regular files. You can speed it up a bit more if you have more information about the file e.g. the owner:

Looking for something inside a file and only want to list the files containing your search:

Working on a box that doesn’t have recursive grep:

The ‘-X’ option ignores files that would mess with xargs e.g. filenames with spaces in.

How many developers does it take to change a light bulb?

Well, you gotta re-deploy the lightbulb application, should take a couple of minutes right? First up you have to upgrade CrappyAppServer because the boss said so. OK, so you install the new version of CrappyAppServer, but there’s a problem, you’ve run out of disk quota. But you can’t increase the disk quota yourself, you have to contact some other guy in some other department. You send the guy an email. Nothing. You escalate it to his manager. You get an email, apparently you have to fill out a form to get the disk quota increased. You ask “Do I really have to fill out the form? I only need a few more gigs and you only have to run one command.”. Yes, apparently without the form and appropriate signatures it can’t be ‘processed’. Now the form requires you to know the physical location of the box but of course you don’t know so you have to contact some other guy in some other department and it goes on and on and on ….

Private, Public and Static in JavaScript

JavaScript doesn’t have keywords for making things private, public or static like other languages but it is possible - unfortunately like most things in JavaScript it’s possible in several different ways!

Public and private access in JavaScript

To declare a method public in JavaScript you can assign it to the prototype:

..or you can also assign it to this in the constructor:

To make things private you can take different approaches aswell. You can just define them to a var in the constructor:

…or you can use the approach Carlos Villela suggests and define your public and private methods in different objects inside the constructor and return the public object:

Static members in JavaScript

Static members are easy, you just define them directly on the class: