Clarke Ching's Rocks and Snowballs

Scrum mention in NYTimes

Scrum is mentioned New York Times article comparirng Google and Yahoo.  The whole article is interesting, but scrum is mentioned right at the end.

[via shmula]

Proof: sleeping with women makes your stupid

http://news.bbc.co.uk/2/hi/health/5197440.stm

Sharing a bed with someone could temporarily reduce your brain power - at least if you are a man - Austrian scientists suggest.

When men spend the night with a bed mate their sleep is disturbed, whether they make love or not, and this impairs their mental ability the next day.

The lack of sleep also increases a man's stress hormone levels.

According to the New Scientist study, women who share a bed fare better because they sleep more deeply.

Note to self:  Must improve “dream recall” skills.  Focus. Focus.

Barry Boehm Tattoo

I got a tattoo last week with Barry on one buttock and Boehm on the other. 

You may have noticed that I’m quite a fan of Barry Boehm and his work.  The software development industry, and the world really, owes him a beer or two.  He did the original cost of change research and explained that incremental development was a great way to reduce the slope of the curve.  He invented the spiral method for developing software which gets mentioned briefly in university course before they switch firmly into waterfall mode.  He’s published zillions of articles, many of them classics.  All of these things considered, I figured my wife would understand, but I didn’t tell her until the deed was done and there was no going back.

So, I took an afternoon off work late last week and popped into a tattooist in Edinburgh.  I explained what I wanted – nothing elaborate, just Barry on the left buttock and Boehm on the right buttock.  I took my time explaining my requirements and I made extra sure that he understood that I meant MY left and right, not HIS.  How embarrassing would it be to have “Boehm Barry” on my bum?  I suppose putting a comma after the Boehm would make it look a little better – academic even – but since the tattooist charged by the letter and I was eager to keep costs down, I felt it more important to get the specifications correct.  To help me out he did a wee prototype with a pen.

In fact, it was the cost that drove me to my next decision.  It turned out that I could get a very large B on each cheek for much less than it would cost to get both words spelt out in full in smaller characters.  The tattooist also said it would less painful and in a way more classy – he said, I’d keep my “mystery” which was something my very catholic mother-in-law had encouraged my wife to do, so it must be a good thing.

So, I took the tattooist's advice and although it hurt a little, within a week I was ready to show my wife.  So, one night after dinner, with the kids put to bed, I put Barry White on the stereo, and did a little strip tease for my darling.  I had contemplated having a Pole put up in the lounge – there’s a surprisingly large Polish community in Scotland these days – but I knew my wife would disapprove and it would spoil the moment.

So I did the strip tease and for the finale, I whipped my under pants off, threw them up in the air rather erotically, turned, bent over and asked her “what do you think of that then babe!????”.

Her response?

“Who the hell is Bob?”

Gliffy.com - nice online visio replacement

Just testing out this new online Visio alternative called Gliffy.com.  Seems easy enough to use.

Here's a picture I drew.  Click on it to see the full size.

Weird news

These made me smile:

• As a New Zealander I should be horrified, by the story in this article: Australian video of All Black haka with players wearing handbags.
• Nepotism anyone? Polish President wants to swear in his identical twin brother as Prime Minister.
• According to Irish Health: Women could soon make sperm.
• This one should scare parents of boys: WASHING young boys with shampoos or soaps containing lavender or tea-tree oils may cause hormonal changes and breast growth, says a small study by the US National Institute of Environmental Health Studies.

 

 

Chicken

Help!  It's been a long time since I've developed code, so I need some help. 

Chapter 27 Chicken

I memory from teenage years popped into my head when I’d very proudly roasted a chicken for my parents and nearly given them food poisoning. I had promised everyone dinner would be ready at 7 but being a beginner, I’d forgotten to warm up the oven and I was running a half hour behind schedule. When it reached 6:50 I checked the chicken and it looked cooked. So, even though it was supposed to cook for another 30 minutes according to the cookery book, I took it out of the oven. But luckily my mum had been keeping a subtle eye on me and caught me.

'You can't take the chicken out until it’s properly done', she’d said. 'You'll have us all in the loo or the hospital'.

Being a teenage boy I didn’t react well to being told what I was supposed to by my mother.  I mean, what did she know? - and I sulked defiantly as she made me pull the leg away from the body and pierce the thigh with a sharp knife. She asked me if the juices were running clearly. They weren’t. They were red. She told me that the way to tell if the chicken was "done" was if the juices ran clear. Otherwise, she said, at the very least I’d ruin the dinner, at the worst, we’d all end up in hospital with food poisoning.

Nowadays, I use a meat thermometer to check when a roast is done, but I still habitually checked that the juices run clear, just in case.

I glanced out the aircraft window. I could see the coastline and the sea through the gaps in the clouds below us.

-oOo-

But, I thought, how did our developers know when the code they were working on was "done"?

...

Can you help?

How do YOU know when YOUR code is "done"? 

Can you automate this, like with the meat thermometer?

Or, do you need to pass another human's eyes over it?

What might tempt you to, figuratively, take the chicken out of the oven before it's properly "done"?

Slow Learners

Barry Boehm wrote an illuminating article in 1979 called "Software Engineering - As It Is".   It is interesting to read it over a quarter of a century later.

Here're a few snippets.

Recently, I reviewed a paper which succinctly summarized many of the software engineering lessons we have (hopefully) learned over the past few years. Here are some excerpts:

1. Testable Requirements

"As soon as specifications for a system program are definitive, contractors should begin to consider how they will verify the program's meeting of the specifications. In fact, they should have had this in mind during the writing of the specifications, for it is easy to write specifications in such terms that conformance is impossible to demonstrate. For example: 'The program shall satisfactorily process all input traffic presented to it.' "

Then we skip on a bit :

Let us compare the above lessons learned with some samples of current software engineering practice gathered from a set of 50 term papers from a software engineering course I gave at USC earlier this year. The examples are drawn from recent government, industry, and university software projects in the Los Angeles area, and should form a reasonably representative sample of "Software. Engineering, As It Is" as seen by the workinglevel software engineer.

1. Testable Requirements

"A requirements spec was generated. It has a number of untestable requirements, with phrases like 'appropriate response' all too common. The design review took weeks, yet still retained the untestable requirements."

"The only major piece of documentation written for the project was a so-called specification. Actually, the specification was written after the program was completed and looked more like a user's manual."

I was 10 years old when the paper was written. I'll be 37 soon. But it doesn't sound like much has changed in the interveening 27 years.

I first read about this idea of writing testable requirements in the late 90's from either a Tom Demarco or a Gerry Weinberg book. I've tried it since and it is very hard and time consuming to do. Especially on big projects with lots of change - it's far less efficient, but much easier, to just build the code then spend ages reworking it later on. I've spoken to a lot of people over the last few years about the value of writing test cases but apart from those already bought in to Agile (where it is easier because of the small, finite scope of each increment), I've only ever met one person who was using it on big projects. In other words, few people are using this technique.

But, wait, there's more:

It would certainly appear that the paper quoted above speaks directly to the current problems faced by software engineering practitioners. Its advice is timely, topical, and evidently much-needed today. It would appear, for example, to be a good candidate for the Proceedings of this Conference.

Unfortunately, the paper has already been published. In 1961.

It is "Pitfalls and Safeguards in Real-Time Digital Systems with Emphasis on Programming," by W.A. Hosier. It appeared in the IRE Transactions on Engineering Management in June, 1961. It is based on the software engineering experiences accumulated on the U.S. SAGE amd BMEWS command and control projects in the late 1950's.

That's right.  The article was written in 1961.  My Mum and Dad hadn't even met back then.