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.
A random blog about engineering methods, the music I like and make and other stuff that occurs to me. I work for IBM and the postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Thursday, 25 July 2013
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?
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?
Thursday, 22 September 2011
Waitrose v Ocado, the Final
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!
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!
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
Subscribe to:
Posts (Atom)