Last order, I searched for Special K and got an error page. Oh. Well, I know it is a cereal, so Cupboard -> Food -> Cereals. Even better, it's from Kelloggs, so let's click that button. Hmm, in all the four pages, the only Special K items are the cereal bars. OK, turn off Kellogg in the search. There it is - a pain to find because you can't enter a page number of use a binary search as you only get the closest pages to choose from. Let's order while I can. Hmm, only 500g packets, I'm sure they do a 750. Here's a thought, I see Corn Flakes here, surely the most iconic Kellogg product, not sure it was in the restricted list. Ah, it isn't.
So, site too hard to use, coded by script kiddies wanting to show off rather than people with the customers' interests at heart. Too many mistakes, too slow. I'm out of here.
Bye!
Thursday, 22 September 2011
Wednesday, 14 September 2011
Waitrose v Ocado - which one is better - Part 3
Second order from Waitrose. First thing I notice is that my trolley has items in it. It is the last order I made. Interesting. There is an option to tick items and remove them. I guess this will be useful as more and more things become part of a regular order, but there tends to be a lot of variation week to week. This first time I deleted about half the items.
On checking out, the delivery address does not default to my address, even though that is the only one on record. You have to select to use it, then click the radio button next to it. I know it's only two clicks, but strangely irritating.
That time it took me nearly three quarters of an hour. Still slower than Ocado.
On checking out, the delivery address does not default to my address, even though that is the only one on record. You have to select to use it, then click the radio button next to it. I know it's only two clicks, but strangely irritating.
That time it took me nearly three quarters of an hour. Still slower than Ocado.
Sunday, 11 September 2011
Waitrose v Ocado - which one is better - Part 2
Following on from Part 1, still on the same order. Some more points:
- The Waitrose site is much slower than Ocado's. Having pop-ups that dim the rest of the screen while updating, even if just to add an item, means I cannot do anything else while waiting. On Ocado, I can add items as fast as I can move the mouse and click. Clearly, Ocado's web developers have learnt to separate processing from handling the input queue, which is pretty basic stuff
- Waitrose has a forum, which is good, whereas Ocado only has email communication
- Both sites have far too many graphical adverts at the top, before I see what I really want.
Waitrose v Ocado - which one is better - Part 1
We have been long term users of Ocado's delivery service - over five years, I think. Now that Waitrose has decided to make delivery free for orders over £50, which is less than my normal delivery, and Ocado charges me
around £10 a month for deliveries over £40 each, for I have decided
to give Waitrose a try for a month and see what I think. I believe
it will take that long to become sufficiently familiar with the
Waitrose site as opposed to Ocado.
So far:
So far:
- Multiple search on Ocado is incredibly useful. I often start
by putting in my shopping list, knowing that the categories can
be sorted by Favourites first means that I usually see the
things I want early
- Ability to edit Favourites on Ocado is very useful
- Suggested order from Ocado also very useful. I never order everything, but it is a great reminder.
- Browsing through by pressing "Next" button for next category very handy on Ocado, as opposed to going to the top of the page, clicking on a (not very obvious) drop-down menu in Waitrose.
- Ocado site looks like it was designed for usability, Waitrose looks like a web designer was showing off
Tuesday, 23 August 2011
Murdoch Maths?
The front page of the Sunday Times had a headline that police could be looking for 30,000 rioters. How did they get that figure? Simple, according to police, there were between 1,500 and 3,000 reported crimes during the riots and each crime has "up to" ten people involved. Therefore "up to" 30,000 rioters.
Am I the only one who can see the massive holes in that reasoning? If I were Ben Goldacre, I could probably spin this out to a full article, but I won't, I'll just leave it there.
Am I the only one who can see the massive holes in that reasoning? If I were Ben Goldacre, I could probably spin this out to a full article, but I won't, I'll just leave it there.
Sunday, 13 March 2011
Agile's four tenets - false dichotomies? (or Agile versus the traditionalists, part 2)
The Agile Manifesto has four tenets:
Individuals and interactions over processes and tools: I don't think anyone would argue that individuals and interactions are unimportant. But does this really mean a choice? Of course not. What about tools that encourage interactions? We all want our development teams to have the best individuals in them, but it is a truism that 50% of developers are below average (almost, but not quite, by definition). So how do we make the best of these less than stellar individuals? Well, how about having a process in place that lets us check their work, and maybe even lets them learn. Hey, maybe we could pair them up with a more experienced (better?) developer? We could even give it a sexy name, maybe "pair-programming". (See what I did there - agile prefers individuals and interactions over processes and tools, and achieves this by, oh, having processes. Hmm.) And how do we get interactions? Maybe we could have a quick meeting every day, we'll make everyone stand up so it doesn't take too much time. Oh, another process. Well, how do we decide what to do? I know, we'll keep a list of things to do (what will we use to store this, I don't know, maybe some sort of todo list tool? Oh, look, a tool) and every so often we'll decide which are the most important. Oooh, another process. OK, scrap all that, let's just let everyone interact with everyone else. Let's see, we have ten developers on the team, that means forty-five communication channels. We can manage that. What happens when the project grows and we now need twenty developers? We now need 190 channels. Whoah, that's a lot. Maybe we should break things down into teams and get the teams to communicate through the team leads. Sounds like more of that darned process stuff.
Working software over comprehensive documentation: I think we can all agree that we want working software. This is a no-brainer, right? So, how do we know the software is working? How do we know it doesn't have some hidden flaw that's going to bring the whole thing crashing about our ears? We don't. Unless we test (actually, that's no guarantee, but that doesn't invalidate the argument here). What are we testing against? Well, we have these User Stories, and the software meets all of those. But does it also behave in the expected way when people do the wrong thing? OK, so we need to make sure that the User Stories account for user error (or missing input, or communication line corruption, or invalid data in the database, or...). Great, sorted that out. oh, just thought, what happens when it doesn't work? We'll need to look into the design to see how the story was implemented, and we will want to know why design choices were made so that we can decide if they are (still) valid. And we will also need to understand how the code matches the design. Ah, there is no comprehensive design documentation. OK, I'll just ask Joe, who coded it. Oh, Joe left six months ago and is now at a competitor. Hmm
Customer collaboration over contract negotiation: Hey, Mr. Customer, we've got a great idea! You just give us some money and we'll deliver what we can. And we'll keep chasing you for input. What, you want to know how much it will all cost so you can work out Return on Investment? No, you don't need that, we'll just keep spending your money until it's good enough. No, there's no need for a contract, you can trust us! No, wait, come back, it will work, honest, lots of people who make their money telling people how to do this say it will. OK, let's step back a little, we all know it isn't really like that (don't we?). But in the real world, customers do want to see some commitment. And, sad though it may be, they often want that commitment to be legally binding. And that means a contract, which needs to be negotiated. Yes, we would all like to be collaborators with our customers, and a good contract provides the legal framework for that to be possible.
Responding to change over following a plan: Change happens (to mis-quote Forrest Gump). A change is only a change if there is something there to be changed. What is that something? Well, a good start is what was planned to be produced. Actually, this tenet isn't as much of a false dichotomy as the others. In fact, it is one of the bases of good project management practice in all disciplines. But there must be some sort of plan, even though it is acknowledged that it will inevitably change.
So when we look at these "X over Y" statements, they either don't stand up to scrutiny as being in as much opposition as is claimed, or are what has been best practice for a long time. So what is agile giving us? Unfortunately (stand by for wild over-generalization), it is often used as an excuse for throwing out the "Y" parts of the tenets without considering the consequences. In many cases, it is little more than an excuse for undisciplined hacking of the worst sort. To reiterate a statement that I have made many times in the past, I am not against the ideas and ideals of agile. What I am against is people treating it as a panacea or something that blows away the need to remember the lessons of the past. So, perhaps you should prefer X over Y, but that does not mean that you don't do the Y at all.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Individuals and interactions over processes and tools: I don't think anyone would argue that individuals and interactions are unimportant. But does this really mean a choice? Of course not. What about tools that encourage interactions? We all want our development teams to have the best individuals in them, but it is a truism that 50% of developers are below average (almost, but not quite, by definition). So how do we make the best of these less than stellar individuals? Well, how about having a process in place that lets us check their work, and maybe even lets them learn. Hey, maybe we could pair them up with a more experienced (better?) developer? We could even give it a sexy name, maybe "pair-programming". (See what I did there - agile prefers individuals and interactions over processes and tools, and achieves this by, oh, having processes. Hmm.) And how do we get interactions? Maybe we could have a quick meeting every day, we'll make everyone stand up so it doesn't take too much time. Oh, another process. Well, how do we decide what to do? I know, we'll keep a list of things to do (what will we use to store this, I don't know, maybe some sort of todo list tool? Oh, look, a tool) and every so often we'll decide which are the most important. Oooh, another process. OK, scrap all that, let's just let everyone interact with everyone else. Let's see, we have ten developers on the team, that means forty-five communication channels. We can manage that. What happens when the project grows and we now need twenty developers? We now need 190 channels. Whoah, that's a lot. Maybe we should break things down into teams and get the teams to communicate through the team leads. Sounds like more of that darned process stuff.
Working software over comprehensive documentation: I think we can all agree that we want working software. This is a no-brainer, right? So, how do we know the software is working? How do we know it doesn't have some hidden flaw that's going to bring the whole thing crashing about our ears? We don't. Unless we test (actually, that's no guarantee, but that doesn't invalidate the argument here). What are we testing against? Well, we have these User Stories, and the software meets all of those. But does it also behave in the expected way when people do the wrong thing? OK, so we need to make sure that the User Stories account for user error (or missing input, or communication line corruption, or invalid data in the database, or...). Great, sorted that out. oh, just thought, what happens when it doesn't work? We'll need to look into the design to see how the story was implemented, and we will want to know why design choices were made so that we can decide if they are (still) valid. And we will also need to understand how the code matches the design. Ah, there is no comprehensive design documentation. OK, I'll just ask Joe, who coded it. Oh, Joe left six months ago and is now at a competitor. Hmm
Customer collaboration over contract negotiation: Hey, Mr. Customer, we've got a great idea! You just give us some money and we'll deliver what we can. And we'll keep chasing you for input. What, you want to know how much it will all cost so you can work out Return on Investment? No, you don't need that, we'll just keep spending your money until it's good enough. No, there's no need for a contract, you can trust us! No, wait, come back, it will work, honest, lots of people who make their money telling people how to do this say it will. OK, let's step back a little, we all know it isn't really like that (don't we?). But in the real world, customers do want to see some commitment. And, sad though it may be, they often want that commitment to be legally binding. And that means a contract, which needs to be negotiated. Yes, we would all like to be collaborators with our customers, and a good contract provides the legal framework for that to be possible.
Responding to change over following a plan: Change happens (to mis-quote Forrest Gump). A change is only a change if there is something there to be changed. What is that something? Well, a good start is what was planned to be produced. Actually, this tenet isn't as much of a false dichotomy as the others. In fact, it is one of the bases of good project management practice in all disciplines. But there must be some sort of plan, even though it is acknowledged that it will inevitably change.
So when we look at these "X over Y" statements, they either don't stand up to scrutiny as being in as much opposition as is claimed, or are what has been best practice for a long time. So what is agile giving us? Unfortunately (stand by for wild over-generalization), it is often used as an excuse for throwing out the "Y" parts of the tenets without considering the consequences. In many cases, it is little more than an excuse for undisciplined hacking of the worst sort. To reiterate a statement that I have made many times in the past, I am not against the ideas and ideals of agile. What I am against is people treating it as a panacea or something that blows away the need to remember the lessons of the past. So, perhaps you should prefer X over Y, but that does not mean that you don't do the Y at all.
Tuesday, 8 March 2011
Response to Sticky Minds article
I wrote this in response to an article on Agile Documentation on StickyMinds - it will make more sense if you read the article first (Agile Documentation).
(Truth in responding - I work for Rational and for many years was a DOORS Principal Consultant)
I wholeheartedly agree with the principles behind what you write here. A well-written requirements document is not just a 300-page lump of paper, it is structured to make things easy to find and with a narrative to make it easy to follow. Unfortunately, when writing specifications people forget everything they ever learnt about writing.
An advantage of a document over a Wiki is that it has that structure - so it becomes fairly easy to see where an area is noticeably heavier (or lighter) than others - particularly important when some areas have regulatory importance. Of course, a tool is even better - and there is no excuse for these things, whether in word processors or requirements tools, to be out of date. Even a simple system should be no harder to maintain than a Wiki. I get quite cross when I hear people say things like "you can't use DOORS for agile". Of course you can! It's just a repository, you can use it how you like.
I posted something on my internal IBM blog about (apparent) false dichotomies in the agile manifesto and have now added it here (scroll down to the section on Working software over comprehensive documentation)
(Truth in responding - I work for Rational and for many years was a DOORS Principal Consultant)
I wholeheartedly agree with the principles behind what you write here. A well-written requirements document is not just a 300-page lump of paper, it is structured to make things easy to find and with a narrative to make it easy to follow. Unfortunately, when writing specifications people forget everything they ever learnt about writing.
An advantage of a document over a Wiki is that it has that structure - so it becomes fairly easy to see where an area is noticeably heavier (or lighter) than others - particularly important when some areas have regulatory importance. Of course, a tool is even better - and there is no excuse for these things, whether in word processors or requirements tools, to be out of date. Even a simple system should be no harder to maintain than a Wiki. I get quite cross when I hear people say things like "you can't use DOORS for agile". Of course you can! It's just a repository, you can use it how you like.
I posted something on my internal IBM blog about (apparent) false dichotomies in the agile manifesto and have now added it here (scroll down to the section on Working software over comprehensive documentation)
Subscribe to:
Posts (Atom)