Sunday, 15 May 2016

A Doomed Project

I had been working as a senior consultant at my then employers for around eighteen months when Ronald (all names have been changed), my boss, called me in to his office.
“You know Paul has resigned.”
“Yes, I did know that.”
“I’d like you to take over Project X, Rick and Jason will stay on it but I need you to manage it.”
“OK, what sort of state is it in?”
“Well, the customer isn’t very happy at the moment, they don’t think that they have had the results that then need. We are ten months in and the project is due in another two”
“Hmm…, OK, I’ll talk to the guys and find out what’s going on.”
Well, that’s a bit worrying, seemed like I had been handed a poisoned chalice. Still, better get some facts before I jump to conclusions.
Rick and Jason were in the shared office, so it didn’t take long to find out the state of the project. It was a mess.
A bit of background. The project was for a government defence agency and involved prototyping user interfaces for weapons targeting on a land vehicle (tank, in everyday terms). In order to do this, it had to display a viewport containing landscape features with targets and other objects overlaid. This was some time ago, so the whole thing was running on a Symbolics Lisp workstation (if anybody remembers those) as PCs were nowhere near capable of handling the demands. It was also written in an artificial intelligence environment. So, nothing ordinary about it.
Paul was a bit of a prima donna, very bright and interesting to talk to, but with very little regard for other people’s abilities, which he took delight in belittling. In line with this personality trait, he had kept all the work he deemed interesting to himself, and had not documented any of it.
So, what did we have? Jason had created a database of targets and other objects with symbols that could be placed on the landscape, so that was good. Rick had made a pretty good start at landscape painting (mind you, this was black line drawing), including obscuring objects that would be hidden, so that was also good.
Paul had kept for himself the user interface prototyping, and, from what I could tell, none of that worked or was even written in a way that any of the rest of us could understand. This was, of course, the part that the customer really wanted, the database and drawing were almost eye candy so far as they were concerned.
It was pretty clear that there was no way we could deliver what the customer wanted within two months. Given that all three of us were able to concentrate on replacing Paul’s work, we reckoned we could deliver something useful in three.
I went back to Ronald.
“We’re going to need more time, if we try to do this in two months we run the risk of the customer refusing to pay.”
“How long?”
“We think a one month extension will do it, but I have an idea of how we can make that more acceptable.”
“Go on.”
I had read Tom Gilb’s Principles of Software Engineering Management and its description of evolutionary development, which was revolutionary and predated agile by around two decades.
“Well, you know Paul had been meeting with the customer once a month and telling them whatever nonsense it was?”
“That’s about the size of it.”
“Well, I want to be upfront about the issues, and propose weekly meetings. At each meeting, we will decide what is the most important thing we could be working on and for which we could show them results at the next weekly meeting. I think they will go for the weekly meetings because they really need to see progress, and they will like the engagement we bring by laying out what we could do and asking for their input.”
“But it will seem like we are abdicating responsibility.”
“Not if we explain that the whole goal is to get to something useful to them as quickly as possible.”
“OK, I’ll talk to them about extending the delivery date.”
“Great, but please make it clear that they will get something delivered each week that they can review and provide feedback on. They won’t have to wait until the end of the project before they get something.”
So that’s what we did. The first meeting with the customer was a bit touch and go, but we were able to show them some of the work Rick and Jason had done (Paul had kept it from them, probably to claim it all as his own), and agreed on something we would deliver for the next meeting. And so it went on.
Did they get everything they originally wanted? Pretty much. Were they happy with the result? Yes. Did we get paid? Yes. Did we work with them on other projects? Yes.
Is there a moral to this story? Well a few, I guess:
  • Don’t give the project management job to an overbearing egotist who tries to take all credit and deflect all blame
  • Work with the customer closely
  • Deliver something of value as soon as possible
  • Deliver something of value at every meeting.
  • Review everyone’s work and ensure it has enough documentation that someone else can take it over.

Sounds pretty much like agile development, even though, as I said, the term hadn’t even been invented at the time. Nothing new under the sun.

Friday, 7 August 2015

Can using the "wrong" mouse hand help you work?

In the beginning

I'm right handed, and, like most right-handed people, started off using my mouse with my right hand. Now, when I say I started off, I mean when I first used a computer with a mouse attached, which was certainly not the first time I used a computer. It was probably at least ten years later. So, by the time I started using a mouse I already had some computer use habits fairly well-established. Anyway, it felt natural to use the mouse with that hand.

Moving on ...

Scroll forward several years (at least two decades, so my mouse habit was well-established by then) and I noticed a colleague using his mouse with his left hand. I asked him if he was left-handed, and he told me he wasn't, but found using his mouse with the left hand was useful as it left his right hand free to take notes.
The more I thought about it, the more sense this made. I gave it a try and found I was very quickly able to learn to use the mouse with the "wrong" hand. Maybe this is partly because I am a bass guitarist, so using the left hand to do things other than just gripping was already something I did.

So, why does it help?

When I am working at my home office desk, my laptop is docked out of the way on a docking station in a slide-out drawer to the right of my working position and I use a wireless keyboard and mouse. I have my mouse on its mat to the left, keyboard in front of me and paper notebook to the right. So, when I need to take notes, I don't have to take my hand off the mouse (though I usually do) and, more importantly, I don't have so far to reach to get to the notepad. This is especially useful as I have the keyboard positioned with the "home" keys to the middle, which means I already have the number pad to the right of the main keys I use. Moving to a notebook past the number pad and a mouse mat would mean moving my hand something like fifty cm (18"), which would also mean either moving my chair or twisting around to write. It's not so much the moving, but the interruption it causes.

Why shouldn't you do it, and when don't I do it?

If you do a lot of fine work with the mouse, drawing, graphics, photo editing, etc., then it might make sense to use the mouse with your dominant hand as you tend to have finer control with that hand. Mind you, if you are doing a lot of that, you probably have a drawing tablet / pen anyway.
Interestingly, when I am using a laptop on its own, I don't usually bother connecting a mouse, mostly because it's just one more thing to carry. So I use the built-in track-pad, and that I normally use right-handed.
If I am doing a lot of writing, as I do when I am thinking things through, sketching ideas, etc. I generally push the keyboard away (benefit of a wireless keyboard!) and just use pen / pencil and paper.

What do you think?

Give it a try, let me know how you get on.

Tuesday, 21 January 2014

Thursday, 26 September 2013

Sonic Pi

I just added more stuff to my Evernote shared notebook https://www.evernote.com/shard/s16/sh/4b17a5fa-239f-46d1-a3ff-fb93df8113da/8b59c21a15fa7759aa6ce90f4ddf0163

Thursday, 25 July 2013

FIT payments from e.on

You know, from the way that e.on behaves, you would almost think that they don't want to pay out the money. I have heard from many people that they are very slow in paying - my last payment was made almost two months after submitting, others have had to wait much longer. My guess is that they get the money from the government straight away and bank it to earn interest. Good business practice? Perhaps. Ethical? Certainly not.
They make it very difficult to apply, I submitted all the relevant documents and had to send them all in again due to a mess up on their side.
They provide absolutely no guidance on how to submit. I only found out the correct email address in a correspondence with a (very helpful) customer service rep who told me (thank you, Hannah Brown).
They give you a two week window in which to submit, so obviously they have systems in place to remind you, don't they? Err, no. You have to put a reminder in your own diary. What happens if you are away over the relevant period? According to e.on, you will simply get the payment next time round, so three months later. I guess that isn't too unreasonable. They also say I should get paid within 5-10 days, so that will be an improvement over last time, if it happens. Oh, and you have to email, no web submission here.
Why the government decided to involve private industry in this is beyond me. OK, it isn't, it's their cronies who benefit from the interest in the bank. In what rational world does it make any sense to have a government subsidy managed through private, for-profit, companies? None at all.

Wednesday, 24 April 2013

Amazon caught out



We all know Amazon manipulates prices depending on who you are, right. Here is the result when I searched for Stomu Yamashta's Go Sessions on Google Shopping:



And here it is actually on Amazon:


I didn't think they would be that blatant. Anyway, it's £16.99 from play.com, so guess who got the business

Monday, 17 October 2011

Documentation and collaboration

To paraphrase Winston Churchill "Documentation is the worst form of communication available to you... except for all the others that have been tried".

One of the agile principles is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation". Conversation and close collaboration are fine on small projects with little novelty and little staff turnover. Let's assume that you use conversation and close collaboration. What do you do when you need to remind yourself of a decision that was taken a few weeks (or months, or even sometimes years) ago? How does conversation help that, unless you have recorded the conversation (and guess what, if it is written, that's a document, just one that is particularly hard to use). What if the best answer to "why are we doing that?" is "go ask Joe", with whom you had the conversation? Well, I have news for you, Joe left six months ago and now works for a competitor, so good luck with that, you had better hope that he documented something.

Communication through conversation is suitable for ephemeral information. If the information has a life, it needs to be recorded. If this is not done as a group activity, then each person on the team will make their own record, which will likely be incomplete and almost certainly inconsistent with the record of other people. Try this experiment next time you are in a meeting - get two people to take minutes (independently of each other) and compare afterwards what they have written.

So you need to record things, and the natural form of record is some form of document. The main problem with documents is not the documents per se, it is their use as if they were the product. They are not, they are just a (form of) repository. Ideally, as someone else has pointed out, the documents would just be reports. We use documents because they have structure, and that brings benefits, like making it easier to find things and also giving guidance about what needs to be considered by having sections calling out specific topics (what, it had to be secure? we never had a conversation about that!). By all means converse and collaborate closely, but record the results in a form that you can easily find them when you need them in the future (which you will, except for the most trivial systems).

The hatred of "big" requirements documents seems to me to largely stem from a post hoc ergo propter hoc logical fallacy - these failing projects had big requirements documents therefore big requirements documents caused the failure. Of course it is essential to document requirements, it is stunningly naive (but amazingly successful for methodologists on a personal basis) to think otherwise, though it does pander to the prejudices of developers. As I have said before, documenting requirements does not always or necessarily mean a requirements document. However, let's not forget the advantages of a document: amongst others, it gives us one place to find the requirements for the whole system, it gives us a great way of locating related (overlapping, duplicate or inconsistent) requirements, it gives us a basis for configuration management, it is very often needed for contractual reasons.

There is absolutely no reason why documents cannot be developed incrementally, filling in information as it is obtained. There is also absolutely no reason why sections (even line items) cannot be approved and acted upon independently. There is also absolutely no reason why every requirement has to be in one document, so long as people can find the information. In particular, it is extremely bad practice to place requirements from different levels (e.g. stakeholders and architects) in the same document. Likewise, why document the detail of all (sub-)systems in one document?

One final question - if documents are so bad, how come the form that most people choose to use to argue against them is ... documents? Surely they should just converse and closely collaborate with everyone else to get their points across?