Tag Archives: deliveries

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.

Delivery Tracking

While lamenting the waste of a day waiting for a “7am-7pm” delivery which didn’t turn up, a friend of mine┬áput the following on Facebook:

“The first delivery company to give a live schedule of how they reckon deliveries will pan out during the day, and keep it up-to-date, so you can at least see where you are in the queue… will make a fortune”

That got me to thinking, how hard would this be? Superficially I don’t think this is too hard a problem to solve using current technology. The hardest bit is the route planning and we can turn to Google for that. So what do we need for an MVP?

I’m thinking a driver app that contains an ordered list of postcodes, interspersed with any breaks the driver may have. The ability to reorder the drops and/or breaks. The ability to mark a drop as done. Here the definition of done is that delivery was attempted. Each time an update is made the app phones home with the current location and an ordered list of outstanding drops and breaks.

A server sits in the middle listening for these updates. Using the current location as the starting point the server will then traverse the drop off points querying Google to find out how long it will take to drive between each point. Store the time to each post code (including any breaks) with the post code.

A client page can then be used to query the server. It would find the correct ordered list of post codes, look up your post code and report how far down the list you are and how long, roughly, until the delivery will be with you.

Of course, the devil is in the detail, and integrating this with the drivers current handheld units, the parcel tracking software and everything else would take some thought, but the basic premis is there. If you were familiar with the Google APIs you could probably knock together a demo web page showing the drivers view at the top and the customers view at the bottom in a couple of days.