Logistics of Toast

I can’t help applying logistics to my everyday life. When I travel to London I walk along the platform at Epsom until I get to the different coloured platform stone which is where one of the train doors will stop allowing me to get on near the end of the train so that when I arrive at Vauxhall, I get off next to the stairs.

I then walk into the underground and turn left into the tunnel and walk along the platform until I get to the white painted square. This is the ideal location for getting out beside the stairs at Warren Street.

A colleague of mine once said ‘What’s the point? You have to do the same amount of walking wherever you get on the train and tube.’ But he was missing the point (and should have known better as our role at work was designing journey planning algorithms).

My approach doesn’t optimise distance, it optimises time. It’s not that I’m in a rush to get to the office, it just feels like the right thing to do.

I’m the same in the kitchen, although it is distance that I optimise in there. When I’m working at home the daily routine starts by filling the bread machine and making a cup of coffee.

The kettle, bread machine, measuring jug and spoon, coffee and sugar are at one end of the kitchen (point A) and the weighing scales, flour, yeast, salt and margarine are at the other (point B). The sink is in the middle (point C). So without consciously thinking about it over the past few years I’ve optimised my routine as follows:

1.       Start at A. Pick up kettle.

2.       Walk to C. Fill kettle.

3.       Walt to A. Return kettle and turn it on. Take the bowl out of the bread machine and pick up measuring jug and spoon.

4.       Walk to B. Take weighing scales out of cupboard. Add yeast, flour and salt.

5.       Walk to A. Take sugar out of cupboard.

6.       Walk to B. Add sugar and margarine.

7.       Walk to A. Return sugar and while cupboard door is open, retrieve cup and add coffee.

8.       Walk to C. Fill measuring jug with water.

9.       Walk to B. Add water. Pick up bowl, measuring jug and spoon.

10.    Walk to A. Put bowl in bread machine and turn it on. Return measuring jug and spoon to their home. Pour boiling water on coffee. Pick up coffee.

11.    Walk to B. Put weighing scales back in cupboard.

As well as optimising my distance travelled I’ve also optimised some of my time because I don’t have to wait for the kettle to boil because I’m busy filling the bread machine.

Note: In the summer the distance travelled is slightly further because the margarine is kept in the fridge.

If I draw the above as a diagram you can see that it isn’t the most optimal distance:

If the distance from A to B and then B to C is 1 then the total distance is 16. Steps 4 to 7 involve two trips between points A and B which could be reduced to one, decreasing the distance to 14. However, I can’t carry the bread machine bowl, measuring jug, measuring spoon and the sugar all at once.

If this exercise was like an old text adventure game on a computer where you could carry as much as you liked in your inventory then I could reduce the distance to 6 by collecting things from A, carrying them to B and collecting everything else, walking to C to get water, walking to A to make the coffee, fill the bread machine and put half the things away before walking to B to put everything else away. However, I might end up waiting for the kettle to boil if it takes longer than it does to fill the bread machine and put half the things away.

Despite what you might think after reading the above, I don’t optimise every activity in the kitchen. If I was toasting three slices of toast under the two slice capacity grill I think I’d do it in four goes instead of the optimum three.

I’m sure I’m not the only person to add logistics to my life without realising it. When my train arrives at Vauxhall the majority of the people in my carriage get off and when I’ve ridden in the front carriage (the ideal place for getting off at Waterloo) I’ve observed very few people get off at Vauxhall, so I’m clearly not alone.

Over Engineered

We have a piano in the dining room at home which means we don’t really have room for a dining table. We searched for months to find a gate fold table which could be left folded against the wall most of the time, but all we could find were ones that looked like they’d just been lifted from a Victorian home.

Eventually we found one at the Ideal Homes exhibition in London, ironically made by a company a few miles from home in Leatherhead. It was very expensive but we had to have it because the leaves were fitted with pistons which slowly lift each leaf once it they have been given a manual start. The piston isn’t strong enough to keep the leaf in an upright position for use, so you still have to scramble under the table to fold out the gate, therefore rendering the piston pretty pointless – over engineered if you like.

I’m thinking about this now because we’ve just bought a new suite for the front room and the two poufs have magazine storage compartments inside, and you’ve guessed it the lids have pistons on them. These are a little more useful because they keep the lid up while you rifle through months of magazines trying to find the article you are after, and prevent the lid from falling on your head.

It turns out they are not the only pistons in the house, we have a soft closing toilet seat which is essentially a piston too. I think this clearly falls into the over engineered category, I’ve certainly never worried about the toilet lid falling on my head.

All of this got me wondering about what else we have that is over engineered and whether I’m guilty of doing it too.

How do you open a document on your computer? Double click on it, right click on it and select Open from the menu, open the application first and then select the Open command and search for the file, or maybe you drag it onto the open application. That’s four different ways to do the same thing, and I can’t help thinking that there’s probably a fifth way that I’ve forgotten.

Surely we don’t need all those ways to open a document. You can make a very good argument that the piston examples add to the desirability of the product and make them sexier in some way – it was the main reason for us buying the gate fold table after all. But does the number of ways I can open a document in Windows affect whether I buy it or prefer iOS instead.

If some people use the options and find them useful or easier then what’s wrong with adding them? It makes the software more complicated that’s what. Somebody has to spend the time writing the alternate functionality, somebody else has to test it, if you have comprehensive documentation somebody needs to add it to the user manual or online tutorials, and if it fails it will take time and resources to fix it.

Having said that the latest web site data entry tool I’ve been working on has almost as many ways of editing a record as Windows has for opening a document. You can double click on it, right click and select Edit from the context menu, single click to view the record and then press the Edit button in the view window.

After reading what I’ve said above you are probably wondering why I did that. Well, I guess it’s because we think our users expect it.

It’s a lame excuse and it would be better to know whether our users do use these functions, although now that we’ve added them it seems pointless taking them out, it’s not like a piston which adds to the ongoing production costs.

At a recent conference I sat in a talk about the IOT or Internet Of Things for the uninitiated. I find it hard to understand the value of a lot of IOT applications – do I really want to change the temperature of my home heating while I’m on the train going home? But one example did sound pretty useful for a manufacturer of white good.

I bet your washing machine has about a dozen wash programmes and I also wager that you have never used most of them. So why do they exist? Because somebody thinks somebody uses them and it looks impressive on the marketing material. The IOT example in the conference suggested that every time somebody starts a wash the machine should send a message to the cloud indicating which programme was being used, so that half of the buttons can be removed when version 2 of the machine is designed.

So should I add instrumentation like this to my software, so that I can remove some of the Edit options?

As it happens my software already has instrumentation – every call to the server is logged in the database so that we can see which functions are used more than others and more importantly we can see which ones perform badly i.e. slowly. However, it doesn’t matter how you select Edit on the UI it always logs that the same edit function has been executed on the server.

It’s given me something to think about but like most people I think I’ll continue to over engineer my software in the hope that each extra option I add will attract or please at least one of my users. 

Lazy Developers

On The Museum of Curiosities on BBC4 radio one of the topics last week was ‘What do you consciously do repeatedly which is stupid?’ One of the examples they gave was a cleaner who cleaned the same lift twenty-five times in a single day. He thought it was a different room on each floor!

Undoubtedly funny but I’m not sure it answered the question because surely he wasn’t conscious of the stupid action. It got me wondering about what I do repeatedly that is stupid.

It’s much harder to answer than I first thought. I’ve been working at the same company for nearly fifteen years because it’s on my doorstep, convenient and I quite enjoy it. There are undoubtedly better opportunities up in the big smoke. But I’m not sure that’s stupid it’s just sensible.

Figure 1

A member of my team retired recently and he left a legacy system for the rest of my team to support. One of the support activities is to import data files into the system when the client emails them to us at random times throughout the week. The process starts with a number of manual steps such as saving the email attachment, checking it, and copying it onto the production server and then completes with a final automatic step that imports the data.

This is clearly stupid. Not only is it time consuming performing all the manual steps when the complete process could be automated, but it is very disruptive to other activities, we have to drop everything and import the data when the email arrives unexpectedly. And that’s only considering the impact on us, the client emails the file and then has to wait an unknown amount of time for their data to appear in the system – our support person might be on a tea break, in a meeting or on holiday.

Last week I was sat in a presentation given by the head of development at Lotus F1 and he showed a slide of his development team with their feet up reading books. The caption on the slide said ‘Only ever employ lazy developers.’ Obviously the picture didn’t reflect the sentiments of this expression.

I’ve come across this suggestion a few times in the past, most recently in a presentation by our CIO where he was talking about encouraging the business to ‘Automate the Norm’. It’s the same thing, in other words you don’t want your developers spending time performing manual processes when they could spend a little effort up front to automate them and free themselves from the task in the future – not so that they can put their feet up and read but perform some other more productive tasks.

One of my other colleagues illustrated this very nicely on his blog a few years ago with the graph shown in figure 1. I’ve changed the labels to match what I’m talking about here.

The key to success with this graph is deciding at what point to write an automation process, they aren’t always simple things to write and sometimes they require ongoing maintenance (the graph doesn’t reflect this) so writing one before the first manual iteration is probably not a good idea. Personally I put it off until I get fed-up of doing it manually.  

The other thing that needs to be considered when creating the automation process is what tools to use. If we want to introduce ‘Automate the Norm’ as a principle in our IS team we need to ensure we have some design patterns and the appropriate tools for the job.

If we consider the data import example, SQL Server Integration Services (SSIS) is pretty good at doing that but if the file of data is uploaded on a website by one of our clients then getting an SSIS package to process the data and return the results to the user is difficult. If the client is emailing the data file to a shared inbox the task is even more difficult, I assume Biztalk could be used in this instance but it’s not readily available (i.e. licenced) to everybody in the team.

There is one other wrinkle to creating automated processes to save time, lots of people in our business are consultants and they charge the client by the hour, if we automate the manual processes that they perform we reduce the number of hours they can charge which affects our profit. This is an old fashioned non-client centric mentality which thankfully we are slowly getting away from.

Now what stupid things do I do repeatedly?

Legacy Projects - Mixed Blessings

I’ve been a software engineer for over 25 years now and my past is filled with legacy projects – some successful and some not so – some still live and others long since dead – and most importantly some that I would be happy to work on again and others that I certainly wouldn’t.

So how do you get to pick and choose which ones come back and which ones stay buried in the past. I think the real answer is you don’t, it just sort of happens and you have to put up with what you get.

You could change jobs to get rid of legacy projects but it’s a bit drastic, especially when you’ve got a good job with some interesting new projects on the horizon. It doesn’t always work either, when I left Racal Marine in the mid 90’s I was contacted a year later to go back on Saturday mornings to work on a millennium bug. I had no ties and could have easily said no but I felt obliged even though the bug was nothing to do with me and had been created many years before I’d even started working there.

I did two stints to fix the same bug for two slightly different deployments. The first one was a bit of a disaster for me financially because I did the work in less than half the budgeted time I had given and only got paid half the money – hardly worth getting out of bed on a weekend for. But I ensured the second one was done on a fixed price and after a quick fix I ran with the cash.

The worst project I worked on was at Primary Image where I was responsible for writing the SCSI scripts which ran on an embedded SCSI controller and controlled a tape drive for archiving digital video. The ‘happy path’ software was fine but as soon as the error handling code was added the scripts became a rabbit’s warren of execution paths.

Looking back it feels as though that was all I worked on at the company but there were other enjoyable projects. This one had been put to bed and was running happily until a client in Ireland reported that they couldn’t retrieve data from the tape and they needed it to catch a man suspected of cashing a fake social security cheque. The prospect of revisiting the code was a nightmare but it had a silver lining – I flew out to Dublin for the day, discovered it was user error and flew back. The only disappointing thing was not getting to see any of Dublin except from the back of a cab because the bank manager insisted I accompany him to their free staff canteen for lunch instead of site seeing and then gave me a lift to the airport on his way home to save me the taxi fare only to deny me another opportunity of site seeing before my late flight.

While working at Atkins (the whole millennium so far) I have worked on a number of large projects which have stayed with me in one form or another. The Carbon Tools Knowledgebase was a carbon modelling system created to be delivered as Software as a Service, we spent a fortune building it only for the recession and a change of CEO to cause it to be cancelled. Another was Transport Direct, a public web site offered by the Department for Transport which was the only true national multi-modal door-to-door journey planner available, it was cancelled because the EU insisted the DfT retender to extend the 12 year contract and they couldn’t justify the expense.

Instead of deleting the Knowledgebase system from the servers when it was cancelled I moved it to some new servers so that a few people who had been using it could still use it on the QT. One of these users has just sold the complete service to a national organisation and the project has come back to life – and guess who the only person left in the company with knowledge of the system is? Yep, yours truly.

It was always ‘my baby’ and in some ways I’m happy that it has come back to life, but I have other things to work on now and it’s a distraction. I’ve been helping somebody familiarise themselves with the code and pointing them in the right direction to investigate the few minor issues with the software. But I can’t help wondering how he’s getting on and want to chase it up.

Most of the IP for Transport Direct belongs to the DfT, so they made it Open Source when shutting down the project in the hope that somebody might pick it up and offer the public the service again. There isn’t a car planning service that can provide a journey plan for future days with predicted congestion, so there is now a gap in the market, albeit one that wouldn’t generate any revenue. It has already been picked up for exactly this reason and I’ve been contacted by the company concerned asking for assistance with getting it running.

I’m less inclined to get involved in this software again but I feel guilty denying Atkins the opportunity to make some consultancy money from the situation. And we might miss out on selling the bits of IP that we own from the project.

With the advent of Linked-In and other social media sites I wonder if changing jobs would get me away from these legacy projects in the same way that it has done in the past – I think the fact that the DfT have always managed to find me and others with party invitations in the last few years of the project when we were no longer directly involved suggests maybe I couldn’t.