Tag Archives: late

First Day

So Ben Taylor, CEO of RainBird has gone on record1 as saying something along the lines of that, “as a matter of principle, RainBird employees will be taken out for lunch on Fridays, without fail“.

It’s Friday… although, to be fair, perhaps if I’d made it into the office before 11 I’d have more of an argument. I ended up working from home in the morning in order to take delivery of my new monitor before coming in and setting up my temporary desk and writing a document that is quite literally called “Big Ol’ Bunch O’ Questions”.

It’s actually made for a nice first day. I got a lie-in. Apart from a brief period before lunch there wasn’t even anyone in the RainBird offices. I’ve not been bombarded with millions of names that I’m not going to remember2, I’ve not had to go through the whole induction thing, I’ve not had to answer the same questions many times over as I’m shown round the office.

Also, since I came in late I got a lift with my wife. She’s still in town so I’ll shortly be going to meet with her and my daughter for an early dinner before going home for the weekend. Who said startups were ridiculously long hours?

1 Sadly a printed article in the EDP, the online version of the article omits the quote in question.

2 I’ve met one guy, who’s name I’m familiar with.

Programmed to fail

One aspect of programming that fascinates me is the psychology of software development. To study Agile is to study people and their interactions, and there are some interactions that seem incredibly hard to break.

Given how often software projects overrun it astounds me that the same patterns occur again and again. Developers seem very reluctant to admit they’re late and tend not to question deadlines until its clear the deadline is now ridiculous. There is a hope that, somehow, everything will fall into place and everything will work come delivery time. And yet experience tells us that things invariably go wrong – the hope is irrational and yet near universal.

Those managing the team can easily spot the signs that a project is drifting into trouble. Confident answers to progress become couched in qualifiers. Progress reports become terse, or filled with excuses. Progress reports may also start sounding very similar week on week. At this point the project sponsors should be alerted to the issue, but again people seem to cling onto this hope that everything will be OK. Reporting up is rarely done early enough or emphatically enough.

Reports of delays need to be emphatic and early as, the closer to release date you get, the less willing sponsors seem to be to accept delays. This may be due to hard and fast deadlines (e.g. shipping physical boxes of software), but I’ve seen it in teams where the deadline is nothing more than a notional line in the sand. Yes, moving that line may be problematic, but not nearly as problematic as putting poorly functioning software live, or missing the deadline with no contingency at all. Simply defining delays in the project as “unacceptable” doesn’t make them go away. Software development is an art, not a science and delivery dates should be treated as malleable until the software is actually delivered.

With all three levels refusing to face facts its little wonder that we have the issues in software development that we do. Agile helps us by giving us tools to counter these issues, but until people can get out of the Big Project Mentality the psychology of large deadlines in the distant future becoming looming deadlines in the very near future will prevail.