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.

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!

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!

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:

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.

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: