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.
Tuesday, 23 August 2011
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)
Monday, 19 July 2010
Pretentious! Overblown! Self-indulgent!
Truth in advertising. I love prog rock. Which is frequently, as in the title, pretentious, overblown and self-indulgent. And most of the time that is fine with me. ELP, Yes, King Crimson, Van der Graaf Generator (cue fans of at least two of those bands saying they were never prog). Great! Can't get enough!
So at the weekend I went along to the doubledotbash in Reading. Lots of people I had never heard of, ranging from a guitar and drum noise duo (it's more fun for you than anyone else, guys) to the wonderful The Hand (acoustic, thus labelled "folk", but they are not really). Francois and the Atlas Mountains - solo Frenchman doing electronics, guitar and trumpet (!). First couple of songs not so sure, but he definitely grew on me.
Then there was Max Tundra. Pretentious! Overblown! Self-indulgent! And crap. Max, dear boy, sampling Keith Emerson does not give you his talent. You went on for too long, you were far too pleased with yourself and your undoubted instrumental and vocal abilities. I got the impression there was some good stuff fighting desperately to get out, but it was drowned in the smoothie maker of everything else going on.If you throw everything in, it doesn't sound more clever, it just gets to be monotonous, a bit like when you played with plasticine as a kid and what you ended up with was always that brown stuff when you mixed all the colours together.
Maybe what you need is a damn good editor / producer.
So at the weekend I went along to the doubledotbash in Reading. Lots of people I had never heard of, ranging from a guitar and drum noise duo (it's more fun for you than anyone else, guys) to the wonderful The Hand (acoustic, thus labelled "folk", but they are not really). Francois and the Atlas Mountains - solo Frenchman doing electronics, guitar and trumpet (!). First couple of songs not so sure, but he definitely grew on me.
Then there was Max Tundra. Pretentious! Overblown! Self-indulgent! And crap. Max, dear boy, sampling Keith Emerson does not give you his talent. You went on for too long, you were far too pleased with yourself and your undoubted instrumental and vocal abilities. I got the impression there was some good stuff fighting desperately to get out, but it was drowned in the smoothie maker of everything else going on.If you throw everything in, it doesn't sound more clever, it just gets to be monotonous, a bit like when you played with plasticine as a kid and what you ended up with was always that brown stuff when you mixed all the colours together.
Maybe what you need is a damn good editor / producer.
Thursday, 15 July 2010
Linda Perhacs - Parallelograms
I read about Linda Perhacs in the Rough Guide book "The Best Music You've Never Heard" (which turned out to be true for only about a third of the artists in the book, but then I do have, umm, an interesting taste in music). The mention there was intriguing, so I sought her out and heard a few tracks online. If you are looking for comparisons, the closest you would get would be Joni Mitchell or perhaps Tori Amos, but those are misleading. Linda is a true original. Her music is soothing and thought-provoking, relaxing and challenging, sometimes by turns and sometimes at the same time. I defy anyone not to have the melody for Chimacum Rain stuck in their heads after just one listen. And Parallelograms is like a mathematical hug (I know what I mean - you'll just have to listen to find out).
Ah, what the heck, just buy it. If you don't love it, I guarantee you will find someone that does. And that person will be (no false modesty here) very special.
Ah, what the heck, just buy it. If you don't love it, I guarantee you will find someone that does. And that person will be (no false modesty here) very special.
Powered by ScribeFire.
Monday, 19 April 2010
Why do Freeview PVRs have such awful interfaces
For over three years I have been using a Topfield 5800 Freeview PVR. The great thing about the Topfield is that it has a programming interface and encourages people to create add-ons. Many of these are improvements of the user interface as the basic interface is painful. Even setting a timer is not simple and you need several button presses to get to subtitles. This machine started to give problems a couple of weeks ago, probably power supply problem (known issue with these) but work has got in the way of checking.
Because we love the MyStuff interface (an add-on for the Topfield), we wanted another Toppy, so we ordered a Topfield 5810 (current model) from John Lewis. Unfortunately, that lasted about two days before it refused to do anything. Literally, all I could do was go to system settings and do a service search or factory reset.
So SWMBO said: let's just get the Which? best buy. That would be a Humax PVR9300T. Used it for no more than a couple of hours and she then said: can we get another Topfield, this interface is horrible. Of course, this wasn't helped by the Hummy losing a recording of Foyle's War - it seems if you Chase Play, it only holds for a limited time and then forgets that you were recording. So I am now waiting for the delivery from Play.com.
Now, we did check out several PVRs in reviews, and they all, without exception, have user interfaces that were, and there is no polite way to say this DESIGNED BY PROGRAMMERS. There, I said it. Only the person who wrote them could love them. They are uniformly, diabolically, awful. Even the much liked Sky+ box is pretty grim (but we don't have Sky, so no point going there).
So why is the MyStuff interface so good? Clearly, the developer is extremely good, it is remarkably reliable with few bugs. But far more important, it has been thought out with a view to what people want to do with a PVR. Want to record a program while you are watching it? Press the Record button. Want to record a program from the guide? Press the record button. Want to edit the details of a timer? Go to the timers screen and (can you guess?) press the record button. Of course, it does far more than that, like a way of using the series data on Freeview to minimise the chance of clashes (it looks for alternates even across multiple channels). I can see 11 channels at a time, and as many hours as I want (of course, what you can physically see is limited by text size, but you can at least see six hours).
And there are other things, like smart programs that save the EPG to disc (so you don't have to wait half an hour for it to populate after turn on), programs that make using subtitles really easy - most Freeview boxes don't let you swap to text if you have subtitles on and vice versa, you can on the Topfield.
The real problems with all this on the Topfield are that (i) it should be set up with a decent interface anyway and (ii) most people don't know about these add-ons.
Because we love the MyStuff interface (an add-on for the Topfield), we wanted another Toppy, so we ordered a Topfield 5810 (current model) from John Lewis. Unfortunately, that lasted about two days before it refused to do anything. Literally, all I could do was go to system settings and do a service search or factory reset.
So SWMBO said: let's just get the Which? best buy. That would be a Humax PVR9300T. Used it for no more than a couple of hours and she then said: can we get another Topfield, this interface is horrible. Of course, this wasn't helped by the Hummy losing a recording of Foyle's War - it seems if you Chase Play, it only holds for a limited time and then forgets that you were recording. So I am now waiting for the delivery from Play.com.
Now, we did check out several PVRs in reviews, and they all, without exception, have user interfaces that were, and there is no polite way to say this DESIGNED BY PROGRAMMERS. There, I said it. Only the person who wrote them could love them. They are uniformly, diabolically, awful. Even the much liked Sky+ box is pretty grim (but we don't have Sky, so no point going there).
So why is the MyStuff interface so good? Clearly, the developer is extremely good, it is remarkably reliable with few bugs. But far more important, it has been thought out with a view to what people want to do with a PVR. Want to record a program while you are watching it? Press the Record button. Want to record a program from the guide? Press the record button. Want to edit the details of a timer? Go to the timers screen and (can you guess?) press the record button. Of course, it does far more than that, like a way of using the series data on Freeview to minimise the chance of clashes (it looks for alternates even across multiple channels). I can see 11 channels at a time, and as many hours as I want (of course, what you can physically see is limited by text size, but you can at least see six hours).
And there are other things, like smart programs that save the EPG to disc (so you don't have to wait half an hour for it to populate after turn on), programs that make using subtitles really easy - most Freeview boxes don't let you swap to text if you have subtitles on and vice versa, you can on the Topfield.
The real problems with all this on the Topfield are that (i) it should be set up with a decent interface anyway and (ii) most people don't know about these add-ons.
Powered by ScribeFire.
Monday, 14 September 2009
Business, stakeholder, system and technical requirements - More thoughts
On the Requirements Engineering Newsletter, Roger L. Cauvin wrote (responding to something I wrote):
the way I think of this is quite old-fashioned, in terms of function, the business requirements define why a system should do something (what I want to achieve), the system requirements define what the system must do to deliver what I want to achieve, and the design defines how the system does it. Of course, quality / constraint / non-functional requirements need to be taken into account throughout.
So, if your business requirement is "reduce the time taken to do taxes", then I would say that you need to do some analysis to understand what this means, still in the business area. Let's say that it breaks down into three activities (please don't argue with these, they are intended just as examples):
This system requirement happens to be a fairly simple restatement of the decomposed stakeholder requirement, changing the focus from what I want to achieve to what the system must do - and that is common, but not inevitable.
Keith Collyer (keith.collyer@uk.ibm.com) wrote:Here is my response:
> System requirements define (but not design) the solution to the
> problem . . . . [T]hese requirements define what the system must
> do to provide the desired capability.
I agree with much of what you wrote in the rest of your message, Keith, but this particular statement highlights again how oxymoronic requirements terminology has become.
How is it possible for so-called "system requirements" to define but not design the solution to the problem?
Let's say one of my problems is that it takes me too long to do my taxes. I challenge you or anyone else to "define what the system must do" to solve this problem without introducing any design choices. Is there anything that the system truly MUST do to solve this problem, aside from create a condition in which it no longer takes me too long to do my taxes?
the way I think of this is quite old-fashioned, in terms of function, the business requirements define why a system should do something (what I want to achieve), the system requirements define what the system must do to deliver what I want to achieve, and the design defines how the system does it. Of course, quality / constraint / non-functional requirements need to be taken into account throughout.
So, if your business requirement is "reduce the time taken to do taxes", then I would say that you need to do some analysis to understand what this means, still in the business area. Let's say that it breaks down into three activities (please don't argue with these, they are intended just as examples):
- collect income and expense information
- calculate tax
- complete tax form
This system requirement happens to be a fairly simple restatement of the decomposed stakeholder requirement, changing the focus from what I want to achieve to what the system must do - and that is common, but not inevitable.
Powered by ScribeFire.
Subscribe to:
Posts (Atom)