In Defence of the Albumn

Disclaimer
This post is written with the aid of a certain quantity of French brandy and in the ad-break of an Austin Powers movie. You Have Been Warned.

The world has abandoned the RIAA. Poor bastards. The major labels are seeing sales crash in ways that SCO can only dream of. So much of their sales, which used to be concentrated in albumns on CD or vinyl, are now in digital downloads. iTunes is the new CD store, at £0.99 per track.

And it's those last two words that worry me. When you can pay 99p per track, what are you going to do? Will you go buy a whole albumn, for about eight quid, or will you pick the two tracks you like at first hearing and buy them for £2?

Again, it's three words that worry me. The "tracks you like". The model of the digital download assumes that you will hear something and either like it, and buy it, or you will never listen to it again.

Is this your experience? It isn't mine. Take, for instance, the Coldplay albumn X&Y. When it comes to Coldplay albumns, everyone likes Parachutes. Why? Because it has Yellow on it. Let's face it: Yellow is a frickin' good song (remember, Austin Powers & brandy) and everyone wants it. It's got some other good songs on it, too; bonus!

Now, name a good song on X&Y. I didn't know of one when I bought it. Just after I bought it, my brother (sorry, Rick, it's all your fault) said, "Everyone says X&Y is their rubbish albumn" and so I didn't listen to it much. For two years I didn't listen to it and didn't like it. Then I started listening to it, just at random. It is awesome. This albumn has some of the best music I have ever heard on it. Swallowed in the Sea is presently the best song I have ever heard. Fix You comes a close second, Talk, Square One, What If, X&Y, A Message, Low, The Hardest Part, and basically the rest of the album are all up there.

The point is this: On first hearing, a lot of music is not what you like. On second hearing, you might start to consider it. On fifth hearing, it's familiar and you kind of like it. On the twentieth hearing, it might be your favourite song. Good music isn't necessarily what you like on first hearing.

What hope is there, then, for good music, in a culture that only listens to the songs they immediately like? If you only buy the songs that yoiu like based on the 20sec preview on iTunes, what will you end up buying? I know I would end up avoiding a lot of music I would otherwise end up liking, and so I remain a firm fan of the albumn.

The Web Is...

Wonderful definition of the web from the New York Times, referring to the ability to quickly find the results of years of research:

The Web is a tool that enables people who have a life to benefit from the efforts of those who don't.

Now go outside and play for a while.

Typical Liberal Junk

You may just have picked up that I am neither a liberal, nor much enamoured of liberals. If you haven't picked this up, I suggest you take a long, hard look at the title of this blog. Anyway...

Spotted this on Slashdot: Blogger Launches 'Google Bomb' At McCain. The gist of it is that some liberal blogger has decided to manipulate the Google PageRank system to make Google searches for John McCain return negative news stories. What had me particularly disappointed in human nature was this quote from the blogger in question:

Obviously, it is manipulating, but search engines are not public forums and unless you act to use them for your own benefit, your opponent's information is going to get out there. [As cited here.]

I hope we can all spot the rather blatant, cynical hypocrisy here. "Search engines are not public forums," he writes; then why do you consider them forums for spreading your own views? And, rather more disturbingly, "Unless you act to use them for your own benefit, your opponent's information is going to get out there." Right, OK, sorry for thinking that informed, respectful debate was important to our society. Yes, sir, I'l just shunt myself off to the gulag right now. No more spouting about those infamous right-wing ideals, like freedom of speech, or respect for people with differing ideas.

I think, funnily enough, that I am right about most things in life. I daresay I am actually wrong about a number of things, but I haven't been convinced of it yet; if I thought I was wrong, then I'd change my mind. I am so convinced that I am right, that I don't mind others hearing the other side of the story; I think that an informed debate will get us nearer the truth. I might even learn a thing or two from the other side. But this guy doesn't seem to think like that. His campaign is not to convince people that he is right, but to silence opposition: "Unless you act ... your opponent's information is going to get out there."

I guess I shouldn't be surprised; from the French revolution to the Stalinist purges, the idealism of the left wing has always turned to violent repression of anyone who disagrees. I don't say my side of politics is guiltless; Hitler is the right wing's skeleton in the closet. I think most on the right wing would agree that he was wrong, though; we would disagree with both his repressive actions and the motivation that lay behind them.

Pilate asked the rather excellent question, "What is truth?" Is truth that which is real? or that whiich you can convince someone to believe, even by such crass means as manipulating Google search results?

And Another Thing...

When filling out a passport application for said four-week-old child, they ask for her height. Do they think this will be useful in identifying her?

Like Pulling Hens' Teeth...

Ever tried taking a passport photo of a four-week-old child? The documentation says the child must be:

• Directly facing the camera;
• With both ears in view;
  
• Holding her head square on her shoulders;
• With her mouth shut;
• And her eyes wide open, so the colour can be seen;
• Not frowning;
• Not smiling;
• On a plain, light-coloured background;
• With no hands in view (mine or hers);
• Not too light;
• Not too dark; and
• Not too out of focus.

Sigh. There are maybe one or two here I can use.

Cricket and Why We Play It

Disclaimer: Americans can stop reading now. You will not understand. In fact, it might be best if everyone except Australians stopped reading now.

I am an Australian. If there is one thing that Australians are truly passionate about, it is not Vegemite, or Holdens, or Outback, but Cricket.

Opinion varies from Australian to Australian on why exactly we play cricket. There are two theories:

1. We play cricket to beat the English.


2. We play cricket to beat the New Zealanders.

I am a subscriber to both these theories, in the inverse order of that given above. The principal reason for playing cricket is to beat New Zealand at every opportunity available.

So you might understand if I am a bit tender at losing a one-day cricket series to New Zealand 3-0. I have a couple of things to say about this.

Any New Zealanders who read this will no doubt accuse me of sour grapes (especially when they get near the end). They are right. But they are therapeutic sour grapes.

Cricket and How To Lose At It

If Michael Hussey ever captains Australia again it will be too soon. Much too soon.

One of the fundamental characteristics of a good captain of a cricket team is that he knows how to create pressure. Some captains have it, some don't. The ones that don't will not last long. Hussey does not have it. Michael Vaughan has it. Andrew Flintoff is learning it. Ricky Ponting is pretty good at it. Steve Waugh was legendary. Michael Hussey couldn't create pressure in his car tyre, let alone on the cricket field.

It is absolutely critical that a team in the field be able to put pressure on the batsmen and dry runs up, at least for a little while. This is how wickets are taken - by pressuring the batsmen into taking risks.

Of course, every player in the field plays his part in creating pressure. But it is the captain who is responsible for it. He uses his bowlers. He uses his field. He creates pressure and he gets batsmen out.

During the debacle witnessed today, the New Zealanders only took risks because they got bored. There was not a moment of pressure applied to them at any stage of the game. The captain has to take responsibility for this.

Now some captains are really good and can defend almost any total, but these are few and far between. It helps to have a great team, of course. Only a very few captains will successfully defend 130 runs. There are some captains who can defend 220 pretty consistently. Most captains in international cricket can defend 290 without too much trouble. But any idiot with a team taken from the Dubbo animal shelter ought to be able to defend 346.

Fair enough, once you might have been unlucky. Sometimes the luck goes against you. Sometimes the other team just play blindingly well and there's nothing you can do. But losing two games in a row, one defending 336 and the other defending 346 is utterly inexcusable. No captain ought to keep his job after such a scandal.

Now there will undoubtably be some nancy-boy out there who wants to defend Michael Hussey, who will point out that New Zealand lost four wickets for forty runs in the first ten overs. Isn't that a sign that he can find wickets? No no no no no no no. That is a sign that there are some good bowlers in the side who can take wickets with the new ball. The failure to capitalise on that start is the truly staggering thing about today's performance. Anyone with a team from the Tanami Desert Home For Geriatric Persons Who Have Lost Everything Below Their Navals ought to be able to defend 346 from a start of 4/40 from ten overs.

Michael Hussey has got to go.

A Plea to the Australian Broadcasting Commission

The other thing to say about today's game is that the ABC needs to lift its game and get some commentators into New Zealand games.

Every cricket-plaing country on earth has produced commentators of a reasonable level of proficiency and professionalism, except New Zealand, it seems. India has produced the excellent Harsha Bhogle and Sunil Gavaskar. Pakistan of course has their own batting legend, Wasim Akram. Allan Donald very respectably represents South Africa. Jonathan Agnew of course is among the very best from the BBC.

Even our very own K.J. O'Keefe, despite being a one-eyed lunatic (one-eyed in the metaphorical sense) with a snort for a laugh, at least has insight into the game, realises that he's one-eyed, is self-deprecatingly humorous about it and gives the other side a fair go.

The best New Zealand can produce is Bryan Waddle. The best Bryan and his fellows can produce is six hours of theorising on how New Zealand might still win the match, no matter how dim it might look. I just want to go and be sick after the first innings of it, even when Australia have put on 336 and look unbeatable (not a typo, I didn't get to listen to the first half of today's game).

Even the pretence of even-handed commentary is absent, as made all too plain by the rather-too-audible wild cheers from the back of the commentary box during the last two overs of today's game. This, it seems, is the height of New Zealand professionalism.

A Piece of Prose from Yesterday

There comes a time on a Thursday afternoon, before Friday is imminent and when Saturday is as yet only the first blush of dawn on the horizon; when no email is arriving, when the notice board has nothing new; when the internet has been read and re-read, but the American and European news sites have pulled the covers up tight and gone to sleep for the night; when the investment made at lunch brings its drowsy return, and you realise that there are only so many cups of tea that can usefully be drunk in one day; and then you enter the long, dark tea-time of the soul.

Credit, of course, to Douglas Adams for the idea.

It's Been a Long, Long Time...

I know it's been a while since I've blogged. So I'm about to post a couple of articles to keep you going, and this one is really just to pad it out and make it look like three. There may be more coming soon...

What's Required

This post is probably not interesting to many people. Only to certain specialisations of engineers, in fact. But I think it is an important document nonetheless.

One of the things we engineers are required to do, from time to time, is to write a requirements specification. For those who aren't engineers, this is a document that tells you what a particular thing is supposed to do. Everyone who hears about this for the first time always thinks, "So how hard can it be?" Well, it turns out it is very easy to write a requirements specification, but very difficult to write a good one.

I am currently working as a test engineer. What that means is that I take a requirements specification, and a system that has been built to meet the specification, and I devise ways of prooving that the system does or does not do what the specification says it does. I am, in this role, a consumer of requirements specifications. And I am fed up with what I'm seeing. There are far too many engineers who have no clue about how to write a good requirement, let alone a good requirements specification, and an almost equal number who have no idea how to take a requirement specification and design or test a system based on it.

So this post is a short(ish) guide to how to write and interpret a good requirements specification.

Writing a Specification

There are a lot of different attempts to explain what makes a good specification floating around, and there seems to be a lot of variance between them. I am going to present a selection of characteristics of a good specification. It is a not an exhaustive selection. I suspect most of the lists around reflect the pet hates of their authors, and this one is no different. For the most part, the advice in this document is the direct result of bad experiences I have had.

So, a requirements specification must be:

Clear

This is absolutely critical. When someone reads a specification, they should be left with no doubt about what is required. There is a good way to judge clearness: Ask yourself, "If I gave a subcontractor this specification and nothing else and told them to go away and build it, what is the likelihood that I would get what I wanted?" Be appropriately cynical about your subcontractor when you make this assessment, ie. assume they are idiots. They may not be, but make the assumption anyway (note that this does not form the basis of a good relationship with your subby; it is only for the purposes of the exercise).

There is a well-established dialect of the English language used in specifications, and you should stick to it strictly. This can hardly be emphasised enough. If something is a requirement, then shall is a verb that must appear in the sentence. If something is not a requirement, then shall is a verb with no place in the sentence. Requirements must all be assigned a unique identifier, and you must not renumber your requirements at any stage of the project.

There are a few ways to achieve clearness. Some important ones include:

• Get the spec reviewed by someone who has had minimal contact with the project. If they are left with questions, your spec is not clear.
• Use notes and non-requirement text to give context to the requirements and help your reader get in the right frame of mind. Care is needed here, because the requirements must still stand on their own. But because requirements are usually brief, and phrased in fairly formal language, it can be hard for the reader to understand them without some help. I find that I generally write every requirement twice in the spec: Each section of the spec starts with some non-requirement text that explains what the section requires in general, non-binding language. Then the requirements restate that in formal language. The formal requirements are there to be tested against; trying to test against informal language is impossible. The informal text is there to help the reader understand what's going on, how the requirements interact with each other and with the wider context of the system.
  

Concise

This is not so critical as clearness, but still important if the project is going to come off well: The spec must be concise. What's that mean? A few things:

• Don't include things that reflect your opinion on the system, but aren't really requirements. This limits the creativity of your design team, who are paid to be creative and to find creative solutions. You will often prevent them from finding the best solution by imposing unnecessary requirements.
• The phrasing of individual requirements should be as concise as possible. The more wordy they are, the more room there is for ambiguity, errors, contradictions and misunderstandings.

An interesting subset of non-concise requirements are ones such as this: "The system shall allow calibration of all equipment that can be calibrated." This is not concise; in fact it says nothing at all. If the system does not allow calibration, then the equipment can't be calibrated, and falls outside of the scope of the requirement. It is impossible to fail this requirement, and therefore it adds nothing to the specification to include it. This looks like such an obvious problem, yet this very month I have encountered two such requirements on a project; the example above is lifted almost verbatim from a specification I am testing against.

What the author meant, of course, is, "For all equipment that provides a method of calibration, the system shall make that method of calibration accessible to a user," or something like that. But that's not what he wrote, and now I have the job of explaining to the customer, not only why our equipment really does do what this requirement says, but also why the requirement doesn't really mean what it appears to say.

Consistent

A requirements spec must not contradict itself. This sounds blindingly obvious, but it's actually pretty easy for it to happen. Contradictions usually creep in where one engineer writes the initial draft of the spec, then another engineer comes along to update it with new information. He doesn't realise that another part of the spec already deals with the aspect of the project he is concerned with, and he introduces a contradiction.

Again, independent peer reviews are critical to getting this right.

Complete

This is the corollary to conciseness. A spec must cover everything you really require. Otherwise you will be delivered a system that meets your requirements specification, but does not meet your real requirements. Of particular help in this regard are the several standards out there that provide template document layouts, such as the older (now mostly obsolete) MIL-STD-498 and the newer IEEE-1220 series of standards. They provide a whole bunch of headings that requirements might fall under, and at least prompt you to think about them.

Functional

Where possible, the requirements specification should not tell the designers how to design the system. It should only tell them what the system needs to do, not how it should do it.

This can be hard, because many engineers writing requirements secretly wish they were designers instead, and have all these great ideas about how the system should be designed. They are often sure that their ideas are the best ones, and that the designers haven't really got a clue. If this is you, go get a job on a design team and stop stuffing up requirements specifications. You will make the world a better place in this way.

There are a few exceptions to this rule:

• The requirements specification should completely specify the external interfaces of a system. These need to be expressed in concrete, design-like terms. It's no good, if your system has to have an RS-232 interface, saying, "The system shall interface to system XYZ via a TTL-compatible serial protocol with handshaking," just because you don't want to dictate the design. If it needs an RS-232 interface, the requirements should specify an RS-232 interface. If the cable for that interface has already been decided, then the requirements spec should specify which connector the interface will use, too.
• If there is some external (ie customer, environmental etc) reason for using a particular piece of equipment in the design, then it should be included in the specification. If your customer wants Windows on Intel x86-64, it is no good putting in a requirement for a 'modern operating system on a 64 bit architecture,' because you will get Open Solaris on an AMD architecture, sure as eggs.
• If there is a good commercial reason for limiting the design, then that should go in the requirements spec too. For instance, if you have a special deal with Intel where you get processors and chipsets at 25% of retail, then you should specify Intel processors and chipsets. Some people will complain about commercial factors dictating design, but if you don't turn a profit then you don't have a job for long.
  

Feasible

It must be possible to construct a system that meets the requirements. Here 'possible' is a loosely defined term. It depends a lot on how much money you spend. However, if you are building a network between Sydney and London, for instance, it is no good having a requirement that says, "The network shall have a latency of less than 1ms." At first glance it might look reasonable, but the distance from Sydney to London and back is somewhere close to 140ms at the speed of light, and the information can't travel faster than that.

Verifiable

It must be possible to prove, in a controlled test, that a requirement is met. Some examples of non-verifiable requirements:

• "The system's processing load shall never exceed 40% of available processing capacity." This is impossible to demonstrate in finite time, because it always might go over 40% just after the demonstration finishes. It might, in certain circumstances, be possible to prove this by analysing the code run on the processor, and showing that it will never consume more than 40% of the available capacity. However, in almost all systems the complexity of the code running prevents this. A better requirement: "During a ten-minute demonstration run of the scenario described in Annex A, the system's average processing load shall not exceed 40% of the available processing capacity." This demonstrates another couple of important points: You should already be thinking about how to test the system as your write the spec, and you should not be afraid of putting supporting data in annexes to the spec.
• "The system shall allow the temporary fitment of any test equipment required for developing future modifications to the system." Another example lifted almost verbatim from a project I am working on. How do I know what equipment might be required for future modifications? How do I know what modifications might be considered in future? Do you really want me to go buy a specimen of every piece of test kit available in the world and make sure we can fit it? This is actually an example of a real requirement that is quite difficult to express in a verifiable way; a requirement for a certain type of test point, or something of that nature might be more useful.
• There are plenty more of these; google for "unverifiable requirement example" and you'll get a selection.
  

Interpreting a Specification

Another tendency I have noticed among test engineers is a certain degree of cluelessness when it comes to interpreting requirements. This is particularly so when there is a badly written spec which has ambiguities. Often I will state the plain meaning of a requirement, only to have some git reply, "Ah, that's what it appears to mean, but you could interpret it to mean..." Fill in your own pointless, stupid, senseless interpretation here. I feel like responding, "Yes, you, could, if you were a retarded beetle, but this is the real world." That's no way to treat a colleague, but it's what I feel like saying.

It's late now, and I don't want to put as much effort into this section, but here are a few tips on interpreting requirements:

• If there are two possible interpretations of a requirement, and one of them makes no sense, then the one that makes sense is the one to choose. The ambiguity is a defect in the spec, but that's no reason for you to compound it by choosing perverse interpretations.
• The scope of a requirement should be limited by what makes sense. For instance, if a requirement states that, "The system shall provide calibration points for all COTS items in the design," then that should be limited to those COTS items that actually have some aspect that can be calibrated. The requirement is badly written, but that is no reason to require a mountain of work of the design team to provide "calibration" points for their power supplies, because that was the only candidate you could think of for calibration points.
• Where a requirement is ambiguous and neither of the above principles applies, the obvious interpretation should be the one chosen. This is just a logical extension of the previous points.
• The meanings of words should always be controlled by the context of the project, and especially by the surrounding context of the requirements specification. I go wild when a spec contains an ambiguous requirement, and a note explaining how to interpret the requirement to resolve the ambiguity, and some loser who just wants to make work for themselves says, "Ah yes, it says that in the document, but it's not a part of the requirement, so you shouldn't take too much notice of it." Sigh.
• It can be a useful exercise to analyse a requirement in detail. This can seem pedantic, but often helps you see what you need to demonstrate in your test. For instance, the requirement, "The system shall provide calibration points for all analog signals in the system's external interface," can be broken down into several points:
  • The requirement's scope includes only signals in the system's external interface.
  • The requirement's scope is limited to analog signals.
  • The system must provide calibration points for those signals that fall within the scope of the requirement. This is interpreted to mean that a suitably qualified user with appropriate test equipment must be able to measure the value of the signal as defined by the relevant interface specification to an accuracy sufficient to satisfy the calibration specification for the equipment.
    
  Thus you need to decide what signals fall in the scope of the requirement, using the criteria listed above, then show that for each one you can identify the value of the signal from the interface spec, and what accuracy is required by the calibration spec, then show that you can actually measure that value to that accuracy.

That's enough for now. I'm sure there is other stuff, but I've at least worked off some steam.

Makin' Music

I have just bought one of these:



It is a Fender BXR-60, which I bought second-hand for AU$220. The BXR-60 stands for Bass eXtended Range, 60W RMS. Pretty much says it all.

Although I've been playing acoustic guitar for about ten years now, and bass for about five, this is the first amp I've ever bought. I know, slow off the mark, aren't I?

So far I've only tried playing my acoustic through it. Of course, it's not meant to be a guitar amplifier, so I wouldn't be surprised if it sounded awful, but it actually sounds OK. The tone starts to get a bit hairy as the volume goes up, but that could be because I'm playing it in a fairly small room with solid brick walls - not exactly an ideal acoustic.

For any interested, that is my acoustic guitar (which I've posted raved about before) in the background. It's beautiful. I love it.