Incredible String Band

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

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

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

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

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

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

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

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

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

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.