Methods and Music

Documentation and collaboration

2011-10-17T09:51:00.001+01:00

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?

Waitrose v Ocado, the Final

2011-09-22T16:00:00.002+01:00

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!

Waitrose v Ocado - which one is better - Part 3

2011-09-14T09:10:00.001+01:00

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.

Waitrose v Ocado - which one is better - Part 2

2011-09-11T13:06:00.002+01:00

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 dimthe 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 itemsas fast as I can move the mouse and click. Clearly, Ocado's webdevelopers have learnt to separate processing from handling the inputqueue, which is pretty basic stuff
Waitrose has a forum, which is good, whereas Ocado only has emailcommunication
Both sites have far too many graphical adverts at the top, before Isee what I really want.

Waitrose v Ocado - which one is better - Part 1

2011-09-11T13:04:00.003+01:00

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:

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

So far (and this is only one order), Ocado is looking like it is in the lead. It took me nearly 45 minutes to place my first order on Waitrose, it normally takes well under 15 on Ocado. And that order was around half of the normal order value. That is at least two hours a month, and I think my time is worth more than £5 / hr.

Murdoch Maths?

2011-08-23T10:31:00.000+01:00

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.

Agile's four tenets - false dichotomies? (or Agile versus the traditionalists, part 2)

2011-03-13T13:59:00.002Z

The Agile Manifesto has four tenets:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Are these four "X over Y" statements really putting things into opposition? I don't think so. Let's examine each and see.

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.

Response to Sticky Minds article

2011-03-08T15:13:00.001Z

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)

Pretentious! Overblown! Self-indulgent!

2010-07-19T17:23:00.003+01:00

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.

Linda Perhacs - Parallelograms

2010-07-15T11:21:00.003+01:00

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.

Why do Freeview PVRs have such awful interfaces

2010-04-19T20:55:00.003+01:00

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.

Business, stakeholder, system and technical requirements - More thoughts

2009-09-14T10:46:00.003+01:00

On the Requirements Engineering Newsletter, Roger L. Cauvin wrote (responding to something I wrote):

Keith Collyer (keith.collyer@uk.ibm.com) wrote:

> 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?

Here is my response:

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

These are still stakeholder requirements, as they are decompositions of the original requirement and still reflect what you want to achieve, within the context of the environment in which you work (in some jurisdictions you calculate your tax, in others the tax authority does). So now work out which of these is costing you most time and you know where you can save most time. At this point, you are still defining the problem. Say the place you can save most time is in calculating tax. Now I can say what a system must do, it must calculate tax, faster than I could do it, using the collected information. I'm not saying anything at all about how it calculates tax.

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.

Business, stakeholder, system and technical requirements

2009-09-11T09:09:00.003+01:00

Terminology bedevils requirements. So here are my views on some common terms.

Business requirements generally define the problem to be solved. The general term we used in Telelogic's Professional Services was "stakeholder requirements". Some people divide these up into levels and differentiate Business and Stakeholder requirements, but they are really just different levels of problem definition. For example, the CEO's view of the problem is necessarily less detailed than that of the department heads. In terms of (at the risk of re-opening a different debate) "function", these requirements define what the business (or stakeholder) wants to achieve - the capabilities. But they must also define all those other types such as performance, security, usability, etc. - and if you don't like the term non-functional for these, then we used "constraint". It's not perfect, but I think it worked better than non-functional without some of the confusing connotations of "quality requirement".

System requirements define (but not design) the solution to the problem. Again, there can be (generally are in a non-trivial system) several levels, for systems, sub-systems, components, etc. In terms of "function", these requirements define what the system must do to provide the desired capability and we were quite happy to call these functions. Again, there will also be constraints in the system requirements.

Stakeholder and system requirements, especially constraints, can be identical. For example, physical constraints, such as a maximum weight, are often identical.

Oh, it is also important to note that you can't always (probably not in general) separate constraints from capabilities or functions; most (but not all) constraints are tied to a single capability (function) or a related set.

Margaret was right

2009-08-19T19:53:00.001+01:00

On The Apprentice last year, Margaret Mountford was heard to say that the University of Edinburgh was not what it used to be. Having just seen them only just beat a team which had a homoeopathy student in its number, I can only think that she must be right.

All songs rated

2009-06-06T15:37:00.001+01:00

160GB iPod
roughly half-full
nearly 11000 songs
all rated! woo-hoo!

Agile versus the traditionalists - Part 1

2009-05-20T16:42:00.001+01:00

I have called this Part 1 because I suspect know that this won't be the last entry in this blog on the topic. It's just too big.

Let me make my position clear. I am firmly in the "traditionalist" camp. But, having said that, I think that there is a lot of value in agile approaches. I'm certainly not going to dismiss it out of hand. Of course, some practices associated with agile (like pair-programming) have proved to be less effective than the original proponents claim, but there is a lot to be said, in many environments, for ideas such as test-first design, use of backlogs, user stories, etc. But there is also a lot to be said, in many environments, for having documented requirements specifications.

For an excellent description of what I am talking about, see David Parnas's classic paper "A Rational Design Process, How and Why to Fake It" in (D.M. Hoffman and D.M. Weiss, Software Fundamentals: Collected Papers by David L.Parnas, Addison Wesley, 2001). Even though you didn't really develop your product that way, you should make it look as if you had a chronological flow of development artefacts (for example, stakeholder requirements, system requirements, architecture, etc.). Why is this important? Well, firstly, the development team won't be there for ever. So it won't be possible to just walk over and ask Joe. Joe is now working for your competitor. But someone still has to maintain the system, so you need some way of recording the common knowledge. But we have all our user stories, you say. Unfortunately, a list of user stories does not always give a sufficiently clear overall picture. Sometimes, you need to be able to understand the whole system at various levels and user stories just don't do that.

So it may still be necessary to document requirements. Note that "document requirements" does not necessarily mean the same as "requirements document". But a requirements document does allow an overview of all requirements in a form that is familiar to people.

But isn't there an overhead in doing this? Sure, there is. The question, though, is: does the investment pay off? Well, if you are delivering a "small" system, say up to a couple of hundred requirements, it may well not. Such a system probably only has at most a few tens of user stories, and experienced people can hold these in their heads. This sort of development is ideal for agile. But when the numbers of requirements starts to creep up it becomes essential to be able to see the big picture. Another situation when the need for a requirements document occurs, even with a realtively small requirements set, is where the requirement specification forms part of a contract. Software has the great advantage here of being incredibly malleable, and also usable even if not complete. Hardware systems generally have neither of these characteristics. Even something as simple as a garden shed to hold tools would be useless without one of its major components, without walls the weather and theft protection is lacking, without a door you can't put things in or take them out, without a roof you lose weather protection, without a lock you lose theft protection, and so on.

So where is the gain in creating a requirements document? Simply, it presents the requirements in a consistent, navigable and understandable way. So, if something needs to change in the future, it is easy to see where that change needs to be made. This means that it is possible for people who were not involved on the original project to make changes in the full understanding of what these changes mean.

And more: if you don't just create requirements documents, but use a requirements tool, you can also see what information is linked. So when a stakeholder says a requirement needs to change, you can see what effect that has right down to implementation level. Simply having a set of user stories, without the linking, does not allow this. And naïve use of user stories will make it hard to use common components (I have seen this happen in practice, leading to a system that we estimated at being around three times as large as it needed to be because people re-implemented).

So, what do I recommend? Surprisingly, perhaps, I would say "use agile". But use it with your eyes open. Use it where appropriate. And don't be browbeaten into not documenting your requirements just because that is the fashionable thing to do.

Incredible String Band

2008-12-01T13:36:00.002Z

This next is a bit of a rant.
While on the subject of "forgotten classics" or "cult" records, I recently bought The Hangman's Beautiful Daughter" by The Incredible String Band, appropriately in a charity shop.
Now I love weird music. The stranger the better. But this goes way past weird all the way back to - well, what exactly? They say there's a thin line between genius and madness, this record shows that there is a thin line between genius and not very good at all. I have read reviews praising the singers use of non-Western tones. I'm sorry, but to me it just sounds like me singing. Which, as anyone who has heard it will tell you, isn't singing at all. I can't listen to The Minotaur's Song without thinking of Monty Python's Lumberjack Song.
I'm sure there are people who will disagree, and point me at the stunning instrumental abilities (no arguments there) or the originality (well, maybe, but not every original idea is a good one). But the fact remains that this is just not a very good record.
Having said that, if I had to choose between this and the latest hillbilly backwoods boy maundering on about his life and how he has only one pair of dungarees for the road (Hayes Carll, you are guilty), I'd choose this one.

It's a Beautiful Day

2008-12-01T09:22:00.001Z

On a whim, I looked up the US group It's a Beautiful Day on eMusic. I remember one of my school friends having one of their albums back in the early 70s. WOW! How have I managed to not have anything by this band all this time? Simply stunning. I only had vague memories of their classic song White Bird, but the rest of it is amazing as well. Suffice to say I ended up downloading everything that emusic had by them. And it is all brilliant. Sorry if this all sounds a bit gushing, but it isn't often that one makes a discovery (or, more accurately, re-discovery) like this.
And, yes, the introduction to Bombay does sound very like Deep Purple's Child in Time. Which, I believe, came later.

Right to bear arms

2008-11-14T14:52:00.003Z

OK, this is way off-topic, but on a recent forum there was a discussion of the US Constitution's 2nd amendment "right" to bear arms. This is what one poster wrote:

But you're wrong in thinking that the 2nd amendment is about militias. The amendment reads: "A well regulated militia being necessary to the security of a free State, the right of the People to keep and bear arms shall not be infringed."

The actual law here is the second part, the first part should be seen as an explanation of why the law was introduced. Basically it says "Because X we do Y". So the 2nd amendment is not about militias, it's about the right to keep and bear arms.

This is clearly a misinterpretation. A logical reading says if "X" then "Y". If "X" is no longer the case, then "Y" is no longer necessary. Also, if there is some other way to achieve "X", "Y" may not be necessary. If the amendment had been written as: "The right of the People to keep and bear arms shall not be infringed because a well regulated militia is necessary to the security of a free State.", then this would have been clearer. It is also clear that "the People" have the "right... to keep and bear arms" within the context of a "well regulated militia", not as individuals. It's "the People", collectively, not "each Person". So the 2nd amendment is not about the right to keep and bear arms, nor even really about militias, it's about the security of a free state.

So the NRA and similar believers that the real right is that to bear arms are, frankly, wrong. Whether this is an honest mistake or a way of covering up their deep insecurities leading to the need to carry lethal weapons is a different debate.

What the agile community doesn't do with requirements

2008-10-13T17:11:00.001+01:00

I posted this in a response to a message on the Requirements Engineering mailing list 081012. It has been mildly edited for the blog.

Here are a couple of examples of things that the Agile community tends to ignore (or perhaps does not realise) about requirements:

Use cases (or user stories) are not requirements. Each can lead to many requirements, many of which are shared by other use cases.
Users often don't know what they want
What users want is often not what they need
What users say they want is often not what they really want
Users aren't the only stakeholders (nor are customers, the only other group commonly mentioned, nor is the combination of users and customers)
It is important to record the requirements, why they are there and where they came from. Joe at the next desk who wrote the code based on a user story may be working for a competitor in six months (as could the customer whose user story it was). Then you can't use the "wisdom of the team".

There is a lot of good in the agile approach, but we must not forget that it came from the coding and design community, who tend to assume that requirements are things done by other people, if they get done at all. Therefore, not unnaturally, it is light on requirements thinking.

ScribeFire

2008-10-10T12:57:00.000+01:00

This short post was made using ScribeFire, a way of creating blog entries directly without logging into the blog site. Maybe I'll actually post things a bit more often if it's easier!

Post in Requirements Engineering mailing list

2008-10-01T22:22:00.002+01:00

This is a response to a post on the Requirements Engineering mailing list about the need to understand what the customer wants to do. My comments are embedded:

Roger Cauvin wrote on 01/10/2008 16.08.02:

> "Richard Zultner" (Richard@Zultner.com) wrote:
>
[snip]

>> needs of the customers (or business)? If you don't know,
>> or clearly understand, the customer needs, then you
>> cannot know if you are building the right system -
>> which then makes the technical correctness of the
>> functional spec (what we intend to build) or the
>> design spec (how we think it should work) a moot point.
>
> Yes, the only thing truly "required" is that the system, in conjunction with
> the users interacting with it, solve certain customer problems. Product
> managers and designers spend most of their time designing solutions (such as
> detailed user interactions with, and functional behavior of, the system)
> without ever clearly understanding and specifying what problems to solve.

Roger has hit the nail on the head. Part of our problem, as engineers and software developers, is that we are problem-solvers. We are very bad at problem definition.
>
>> When I review functional specs, the first thing I check
>> is whether customer needs are clearly identified and
>> understood. If they aren't (the usual case), then you
>> can spend days examining one functional requirement after
>> another, and asking, "and why does the user need this?
>> What problem does that solve for the customer?" and
>> finding out that no one, including sometimes the user,
>> knows.

Exactly. I see this often.

> One major reason for this phenomenon is that, when the typical organization
> categorizes functional specifications as "requirements", it lulls its team
> members into believing they've understood what's "required" despite never
> having understood what problems they're solving.

Yes, again

> I propose that every team serious about requirements compose a conceptual
> model of requirements concepts. For most teams, composing such a model will
> reveal numerous ambiguities and contradictions in the way the team members'
> understanding of requirements concepts. See
> http://cauvin.blogspot.com/2006/11/requirements-concepts.html for model of
> requirements concepts that I believe is relatively free of such ambiguities
> and contradictions.

I like Roger's conceptual model, but I think it misses out one vital thing (and my apologies if I am mis-reading it). This is that it does not clearly distinguish between problem definition (stakeholder requirements) and solution definition (system requirements, many, but not all, of which are functional). In my view, it is vital to have stakeholder requirements defined before working on system requirements. And note to the agilists, I do not say that the entire stakeholder requirements specification needs to be defined, just enough to allow the risks to be understood well enough to make it worth spending resource (i.e., money) on defining a solution. And notice that I talk about defining the solution, not designing it. In crude terms, stakeholder requirements are about what they stakeholders want to achieve, system requirements are about what the system must do and the design is about how it does it.

Preparations and problems

2008-08-19T21:57:00.003+01:00

Short music related one this time. Our keyboard player has had to drop out (we hope temporarily), which means that we have had to rethink our setlist. Out go Riders on the Storm and Van Halen's Jump for starters. Real shame. We had dropped Cream by Prince as we didn't think we would get it ready in time, but I think I now have a handle on the bass line which was causing me trouble. Basically, I was over-thinking it before. Go back to basics, concentrate on the chords and with a bit of help from my bass tutor, I now know what I plan to do. Whether that is the right thing, or whether I can pull it off, only time will tell :-).

Oh, we might be changing the band name. Reheat is looking like a favourite for now.

Businness Analysts and design

2008-06-18T15:33:00.003+01:00

Sometime since I last posted, so one from the past:

This was originally posted about ten weeks ago on the Requirements Networking Group (RQNG 080320 "Does a BA do design?", http://www.requirementsnetwork.com/node/1117#comment-2132) in response to a post claiming that there is no distinction between requirements and design. I have mildy edited for this blog.

Of course there is a meaningful distinction between requirements and design! That doesn't mean that the distinction isn't sometimes more of a grey blur than a clear line, but it is nonetheless meaningful.

Requirements are all about definition, either of the problem to be solved or the solution. Design is all about, well, design - making decisions about what a thing should be as opposed to what it does. I can define a solution, that is, defining its essential external characteristics, without designing it, which is primarily about internal characteristics.

Do I think that BAs should be involved in design? It depends, at the least they should be involved in reviews to gain confidence that the design will provide the functions, and thus enable the capabilities, that are needed. Does that mean they DO design? No, it does not. If a BA does design, does that mean that requirements and design are not meaningfully distinguished? Of course not.

I suspect that a lot of such thinking comes from the common failure to distinguish between problem and solution definition. Countless times, I see or hear of BAs presenting functional specifications to users without understanding that the functional specification defines the solution, and hence without the actual problem being clearly defined anywhere.

On a related note, should BAs take into account design in the analysis? Of course they should! I often use the example of seats in a car. From a pure problem perspective, you should not include seats in the stakeholder requirements as they are a solution. But no other solution fits the constraints of the problem, so use them.

Welcome to IBM

2008-04-17T04:28:00.000+01:00

After a long, long time of waiting, the company I work for (Telelogic) has finally been taken over by Big Blue. We had our "Day One" today - this is IBM-speak for a mass induction day. Actually, it was pretty good. I know IBM has a reputation for being staid and boring, but at the moment it is far more innovative than a certain large operating system and office software vendor we all know. And it certainly gives me far more opportunities than I would have had.

Recording a demo

2008-04-13T20:34:00.001+01:00

The band I am in (Deja Voodoo, though that name may change as there are lots of bands with that name!) finally got around to recording a demo a couple of weeks ago. We took from ten in the morning until six in the evening to record four songs. The first couple of hours was spent just setting up - mostly getting the drum sound right. All credit to Richard of Plug'n'Play Studios (www.plugnplay.tv) who was our engineer for the day.

I have to say, it was hard work, but a tremendous buzz listening to the raw playbacks.

Laurent, our keyboard player, spent some time mixing down from the sixteen track originals to stereo, so far he has managed to get two of the tracks done and, though I say so myself, they sounds pretty darn good! OK, there are a couple of places we could have done better - I have already spotted one place where I can improve my bass line - but overall, especially considering we spent so little time on it, it is plenty good enough for what we want. Next we need to get the rest of the mixes done, burn some CDs and hawk them around local clubs and pubs.