Fox on Software

The Question

2011-10-10T17:53:00.017+01:00

I know why you're here. I know what you've been doing... why you hardly sleep, why you live alone, and why night after night, you sit by your computer. You're looking for him. I know because I was once looking for the same thing. And when he found me, he told me I wasn't really looking for him. I was looking for an answer. It's the question that drives us. It's the question that brought you here. You know the question, just as I did.

'Why do so many Software projects fail?'

Two weeks back, before I moved house, I gave a presentation to the London Agile Practitioners 20x20 meetup about the "Dark side of metrics" which I've uploaded to the new Slideshare-y site SpeakerDeck here.

I realised by the time that I got to slide 4 that I was giving the wrong presentation, and yet in an ironically un-agile fashion I continued to give the presentation anyway. This was echoed by another presentation, in which the presenter showed a cheetah (more irony, this is the mascot of Pentaho's 'Agile BI' initiative), and argued that whilst most people viewed this as agile, in actual fact the gazelle is more agile because although not as fast in a straight line it is more manoeuvrable and can out-turn the cheetah. His point was that many people now equate 'agile' with 'velocity' (hence the popularity of the term 'sprint'), rather than the more correct 'responsiveness to change'.

To my defence, being a Pecha Kucha night the emphasis is on 'rush rush hurry hurry', no interruptions, the clock is running, no more than 20 seconds per slide, no less than 20 seconds per slide, so the pressure was on. But I learnt something that night, apart from the fact that Pecha Kucha isn't very 'Agile'! That is that no matter what the pressure, we must have the courage to use Jidoka or 'stop the line' in Lean terms.

The reason that the presentation in its current form is 'wrong' is that it tells the following story:

Beginning: We need to plan, so we use software metrics
Middle: Software metrics have unintended pernicious side-effects. Software development is hard, and success is unpredictable. Software is fundamentally different from Science, Engineering and Manufacturing. Algorithmic Complexity research shows that actually the problem of complexity estimation is insoluble, and hence so too are effort and cost estimation!
Ending: If accurate estimation is an insoluble problem, the only rational course is to abandon predictive methodologies for reactive ones, hence the ascension of Agile. QED.

I realised that everybody already knew Big Planning Up Front was bad, nobody in the room had the misfortune of working on government or other public-sector contracts, and everyone was using Agile planning and estimation methods.

Agile has 'crossed the chasm', it is now old news; but still it is quite misunderstood as we have much 'cargo-cult' Agile (the subject of another presentation: 'Agile considered harmful'). The focus of a presentation on metrics should instead have been about what is wrong with Agile and software metrics as we currently have them, and why the emergence of a 'code agility metric' is "a bad thing", like "don't cross the streams" bad. There is currently a whole topic on it on LinkedIn's Agile Alliance forum, people have blogged about it and one guy even has a whole article entitled "Metrics Driven by Agile Values and Principles" on Agile Record magazine.

The issue here is that as soon as there is a weight of opinion behind a metric, people will start using it, managers even, and giving a manager a metric is a bit like juggling chainsaws: whilst initially it seems impressive, it's really not clever and it's only a matter of time until someone gets hurt. Case in point: when I spoke to a senior manager at the BBC they admitted that the only time they use software metrics is when they want some ammo to help back up the decision to fire someone.

Douglas Hoffman in his 1999 article on "The Darker side of metrics" documents many cases of organisational pathology arising from the measurement effect, that the act of measuring the system, changes the system. As Hoffman says: "Whether or not our models are correct, and regardless of how well or poorly we collect and compute software metrics, people’s behaviours change in predictable ways to provide the answers management asks for when metrics are applied" - they create self-fulfilling prophecies. He tells how in countless organisations, software quality metrics cause deleterious and often bizarre behaviours e.g. using 'ready to release' metrics based upon the ratio of bugs found / bugs fixed causes the following to happen:

To reduce the number of defects, twenty-five reports against a subsystem were all marked as “duplicates” of one new defect. The new defect report referred to each of the twenty-five for a description of the problem (because the only thing the twenty-five had in common was that they were reported against the same subsystem)
In an organization where defects didn’t get counted before initial screening and assignment, a dozen defects that hadn’t been resolved in more than four weeks were assigned to the developer “Unassigned,” and thus were not counted
In one case the testers withheld defect reports to befriend developers who were under pressure to get the open defect count down. In another case the testers would record defects when the developers were ready with a fix to reduce the apparent time required to fix problems
A test group took heat for not having found the problems sooner (to give the developers more time to fix the problems)
Developers only reported problems after they had been fixed (thus never making the ratio worse)

He writes: "Every software organization I have observed that has used metrics for more than a few years has had bizarre behaviours as a result. There is a decidedly 'dark side' to these metrics programs that impacts organizations all out of proportion to what is intended."

Hoffman uses research by Cem Kaner Ph.D. on measurement factors to highlight what we need to think about whenever we make a measurement:

The purpose of the measure. What the measurement will be used for.
The scope of the measurement. How broadly the measurement will be used.
The attribute to be measured. E.g., a product’s readiness for release.
The appropriate scale for the attribute. Whether the attribute’s mathematical properties are rational, interval, ordinal, nominal, or absolute.
The natural variation of the attribute. A model or equation describing the natural variation of the attribute. E.g., a model dealing with why a tester may find more defects on one day than on another.
The instrument that measures the attribute. E.g., a count of new defect reports.
The scale of the instrument. Whether the mathematical properties of measures taken with the instruments are rational, interval, ordinal, nominal, or absolute.
The variation of measurements made with this instrument. A model or equation describing the natural variation or amount of error in the instrument’s measurements.
The relationship between the attribute and the instrument. A model or equation relating the attribute to the instrument.
The probable side effects of using this instrument to measure this attribute. E.g., changes in tester behaviours because they know the measurement is being made.

In my experience, you're lucky if one or two of these have been considered, let alone most or all, yet this is common in the Sciences, my Physics lab work at university would have received short-shrift if I hadn't calculated margins of error for all my measurements. How many times have you seen error bars on a Gantt chart work item effort or duration estimation? Thought so.

Although we naturally equate 'complex' with 'large' in terms of numbers of things, this is a misconception. The humble water molecule is achingly simple, just one oxygen atom and two hydrogen atoms, but it gives rise to extraordinarily complex behaviour as any chemist knows, the phase transition diagram for water shows no less than 21 forms of Ice (that we know about!)

Another example of hidden complexity is the three-body problem, namely: "the problem of taking an initial set of data that specifies directly or indirectly the positions, masses and velocities of three bodies for some particular point in time and then using that set of data to determine the motions of the three bodies and to find their positions at other times in accordance with the laws of classical mechanics: Newton's laws of motion and of universal gravitation."

For a video of this see here: three-body problem

This was first published in the 17th century by Isaac Newton; it turns out that for two bodies of a set mass and initial position, that the problem is generically solvable for all initial conditions, yet for three bodies there is no general solution, and even minuscule changes in initial conditions lead to wildly unpredictable fluctuations in outcomes.

This was the beginning of Chaos Theory, and it turns out that even something as conceptually simple as a coin toss, or three equal-sized masses in a vacuum can spawn undreamed-of complexity.

The problem is... management. Managers still see the world through the lens of causal determinism, and not just because that is what they've been taught, all the way back to Frederick Winslow Taylor and before, but because this is a natural function of the way that the human mind works. The human mind has evolved to see a cause behind everything, a bush rustles and we envisage a lion behind it, waiting to pounce! This is a function of evolutionary psychology, and is to be expected because of the imbalance of risk between the outcomes of:

False positive = we run from shadows, and waste a little time
False negative = we get eaten

Immanuel Kant posited Causal Determinism is a necessary prerequisite for all scientific discovery, and it has served us well in its way, we learn linear equations in school and they help us solve problems, but we don't learn non-linear equations, because they are too hard to solve!
But let us not blame Taylor, he was the product of a time when the predominant belief, quoted by Lord Kelvin in 1900 was: "There is nothing new to be discovered in physics now. All that remains is more and more precise measurement."

Yet Kurt Gödel knew in 1931 that there was trouble afoot, and his incompleteness theorem paved the way for a troubling new branch of science which had inexorably to admit that there were problems that even the brightest minds could never solve. Like ostriches we pushed these to one side, brushed them under the carpet to concentrate on problems that we could solve, and for decades the scientific community regarded this as a mere curiosity, like Fermat's Last Theorem (ironically itself solved in 1994).

No-one cared for the unsolvable, and this class of problem languished in the scientific doldrums, yet Nobel prize-winning Physicist Richard Feynmann believed that the class of insoluble problems was actually not a mere footnote or curiosity, but actually composed the vast majority of all problems.

Gradually dynamical systems theory, chaos theory, social complexity theory and a variety of other 'complexity sciences' have sprung up to cover the gap in our knowledge, and even Stephen Hawking has referred to the 21st Century as the 'century of complexity'.

As Frederick Brooks wrote in "No Silver Bullet", software is inherently and essentially unpredictable, and no amount of 'Computer Science', or 'Software Engineering', or 'Software Metrics' (e.g. six-sigma) is going to change this. We've proved this already, whether by the Chaitin incompleteness theorem, Network Theory, Dynamical Systems Theory, Game Theory or Social Complexity Theory.

Now it is time for Management to catch up.

Welcome, to the real world!

Onboarding, right and wrong ways to do it

2011-06-30T15:19:00.001+01:00

Something I came across a long time ago, but still brilliant:

My friend Peter started working at EvilEmpireSoft on the same Monday that I started at Geekaplex. That Friday, over beers, he told me that he had spent most of his first week waiting for his laptop to show up. When it finally showed up, it had an outdated version of the development environment installed which couldn't compile the code he was supposed to be working on. On top of that, Outlook was misconfigured and wouldn't even think about connecting to the mail server. He spent an afternoon figuring out the configuration only to discover that his email account hadn't been activated yet! "It's as if they were surprised when I showed up for work on Monday. Maybe they forgot that they hired me? I spent the first morning waiting in HR until someone was available to give me paperwork to fill out. After that," he went on, "I spent the afternoon wandering around looking for an empty cube to claim."

I felt bad for Peter, and I was almost embarrassed at how different my first week had gone. My office was just down the hall from my boss's. There was no mistaking that it was mine, as my name was on the plaque next to the door. Inside, I found a shinny new ThinkPad with a docking station and a pair of flat-screen monitors. The drawers in the desk were filled with new pens, pencils, paper, a stapler, and even a box of freshly printed business cards. My boss sat down with me and walked me through my first week, pointing out the various meetings and training sessions that were already on my calendar. There was even a welcome email from the president of the company waiting in my in-box.

"Wow!" Said Peter, "You're like a VIP over there! I feel like most folks don't know I exist, and if they do, they are just hoping that I won't bother them. It really sucks. EvilEmpireSoft seemed so cool and together when I interviewed, but now I'm wondering how they get anything done. They aren't the elite, well-oiled organization that I imagined them to be. I feel like I made a big mistake accepting their offer."

What a big difference attention to detail and a little preparation made. By simply taking the time to provision my office, my boss sent me a strong positive message about the company, and how much they valued me. Additionally, by making sure that I had all the tools I needed to be productive, they let me know that they expected me to be productive. I felt like Geekaplex had it together, and that they would expect me to have it together as well. I felt welcomed and challenged.

Originally posted here:
blog.technicalmanagementinstitute.com/

Value, productivity and metrics

2011-06-24T16:12:00.004+01:00

This is a response that I made to Ravikumar Mohandes on the Software Engineering Productivity forum of LinkedIn, on the topic "How do you measure (software) engineering productivity?". Ravikumar wrote:

Ultimately productivity has to be defined in terms of the dollar value created. Organizations or groups that can map their contribution to a project to the company’s bottom-line are usually found to be highly productive.

In other words, measure a group's productivity by the profits generated and the business opportunities created.

You can find the whole thread (114 comments) on LinkedIn, and there was much to-ing and fro-ing about the value or otherwise in software metrics being used to measure, well, pretty much anything. There was a very heated debate with Capers Jones (a consultant who sells information to clients based upon metrics that he's been collecting for many years) arguing very strongly for metrics, and several others (myself included) arguing against. That part of the conversation by-the-by, I'd like to highlight my response to Ravikumar, as the statement:

"Productivity should be defined in terms of the dollar value created"

is accepted as a god-given truth in most business and project management circles (at least in my experience), and whilst I think that the merit in this is generally accepted in the manufacturing world, things are very different in the software world, and this is something that is often overlooked.

So without further ado, my response:

---
The problem is that you are now in the realm of accountancy, and as any decent accountant will tell you, there are many different ways of measuring profit, and even a simple to measure "revenue minus cost of sale" may not be a very good measure of "value to the business".

Leaving aside for a moment the selection bias present in the choosing of "profit" as a measure (it is possible for a business to be bankrupt even if profitable, as cash-flow is often more important, for instance), it turns out that the two components of the measure: 'revenue' and 'cost of sale' are actually a bit more difficult to measure than you might at first imagine. For example:

Revenue - do you only count the money that the customer pays you up front? Do you count any service agreement amount? How is this amortised over the duration of the service agreement? All up front? Evenly over the course of the contract? Only accounted for on contract completion? Discounted over time on a risk-profiled basis? Are you taking into account TVM coefficients? What about repeat work? (as the cost of acquiring a new customer is often many times higher than selling to an existing customer) are you factoring in the value-add that producing a high-quality project will have in getting repeat business? If so then how are you calculating this? How do you measure quality and customer satisfaction? Over what time period is it necessary to wait for a customer to make another order in order that it is counted as a 'repeat sale' and hence factored into the calculation of business value for the previous project, rather than a new project? ...

Cost of sale - Are pre-sales activities factored into cost-of-sale? Are general business expenses factored into cost of sale (e.g. business rates, payroll cost etc.)? If they are, then how are the CapEx and OpEx split between different projects? Evenly per project? Proportional to final value? If so then how is final value calculated? If you have projects that re-use components from other projects (and this may be learning and knowledge, rather than hard code for instance e.g. product training), then how is this accounted for in your cost-of-sale calculation? If this is a sale into an existing customer, how much of the cost-of-sale value is accounted for as being due to the successful outcome of a previous sale, and therefore shared between the projects? If not, then how do you compensate for the artificial inflation of 'first sale' project costs? Are we taking into account taxes? (i.e. difference between EBITDA and NOPAT) If NOPAT then if a project spans accountancy periods, how do you determine which period it is included in in order to determine what it's tax liabilities are? ...

This is just skimming the surface of what corporate accountants deal with every day. The reality is that 'profit' can mean pretty much whatever you want it to mean, and every answer to every question above affects how it is determined, and how your projects will stack up against one another. The reality of running a business is that you can never truly know the exact state of the accounts until the business is wound up, everything else is surrounded by guesstimates (e.g. deal closure rates), assumptions (e.g. tax banding by operating profit on next fiscal year's books) and fudge factors (e.g. payment default rates and average invoice payment delay).

My message here is really: "think very very carefully before suggesting metrics like 'profit', because although they seem simple to calculate to the lay observer, the reality is very very different".

4x4xFoolish

2011-05-24T18:27:00.000+01:00

Apparently the Which? Car Magazine seems to think that VOSA is 'toothless', and that unlike it's US counterpart the NHTSA (which issued 118 recalls last year) VOSA has not issued a single recall. The report then goes on to lament the terrible lack of focus on consumer protection and health and safety that this lack of action has on VOSA's part.

The story reads like a typical 'average man in the street' consumer interest story, we should apparently be outraged that our ever higher taxes are paying for a government department that, for all intents and purposes, seems to be doing nothing.

As always, it pays to look behind the immediate story, and see what the actual picture is, rather than the lazy journalist's mindless regurgitation of a PA or Reuters news feed, and the avaricious editors choice of those stories that they think will grab eyeballs. Back in 2010 I wrote the following piece about Which? in the US creating a kerfuffle over an alleged safety issue with Lexus's SUV. If this is the type of recall being routinely issued by NHTSA in the US, then perhaps we can be reassured by the fact that VOSA is obviously investigating and filtering out this kind of nonsense before it hits UK shores. Of course, it could also be delinquent, but then I don't see any actual investigation by the journalists, as that's not what we pay them for anymore...

In news today, the US equivalent of Which? (Consumer Reports) tells us that the 2010 model of the Lexus GX SUV is dangerous (see here)

They advise not to buy it until Toyota (owner of the Lexus brand) fix the 'problem'. Needless to say CNN, the major news channels and even the BBC (linked here) is echoing the report, without managing to lift their brains out of neutral to actually analyse the source material. /facepalm

If you actually watch the Consumer reports video below, you can clearly see the test driver enter a turn at far too high a speed, then panic and lift sharply off the accelerator - exactly the behaviour that we are taught not to do as it destabilises the rear of the car and can cause it to spin. So, basically the tester is driving like a numpty. The Lexus's electronic stability control intervenes, and the car neither spins nor rolls over. Marvellous.

You can watch the YouTube video yourself here.

So hang on a minute, why is Consumer reports saying not to buy the car as they think it is dangerous? Well folks, they say: "We believe that in real-world driving, that situation could lead to a rollover accident, which could cause serious injury or death."

Did they manage to cause the car to roll over? No.

Did they manage to cause the car to have any sort of accident? No.

Have any deaths, or even serious injuries been reported in accidents involving that make and model of car in similar circumstances to the test? No.

Have they ever heard of any accident AT ALL happening to that model car similar to the scenario that they are postulating? No.

So basically: No, No, No and No.

The reason? Because when you go too fast and sharply lift off the accelerator, the back end of the car steps out. Any car. All cars. Hell, there's even an entire sport devoted to doing exactly that, it is called Drifting!

Let's look at some of America's popular SUVs doing exactly the same thing that the Lexus does:

Mercedes Benz G55
Ford Explorer
Audi Q5
Jeep Cherokee

Etc. etc. I think you get my point. In the software industry we have two terms for this:

WaD = 'Working as Designed", and
PEBKAC = Problem Exists Between Keyboard And Chair

:-)

How many monkeys do you have?

2011-04-06T16:15:00.005+01:00

A colleague yammered today that he was off to see OutSystems® tomorrow, and wondered whether we had any comments; for the uninitiated, OutSystems® make a 4GL-style tool called agileplatform™ that reminds me very much of PowerBuilder or Visual Basic from the Good Olde Tymes©.

I've often talked over the past couple of years of the devaluation of the 'Agile' currency, in no small part due to the Scrum Alliance's commercial model and the programme that has been put in place to monetise the Certified Scrum Master™ title. To quote one well known super-villain:

I'll sell my inventions so that everyone can have powers. Everyone can be super! And when everyone's super... [chuckles evilly] no one will be!

Now in an ideal world, everyone would be a great Agile developer, but a one or two-day course does not make one Agile, nor does stand-ups, iterations or story cards. This combination of primitive understanding with the mimicking of Agile's external forms is a form of Cargo Cult, which has become so widespread that now only a small minority actually know what it means to be Agile. This devaluation is why I don't refer to what I do as 'Agile' anymore, because it is not only effectively meaningless, but also 'tarnished' with the brush of failure in much the same way as the TPS 'Lean' practices have been.

If we look at the core of what it means to be Agile, the Agile Manifesto, we see that:

"We value individuals and interactions over processes and tools"

The headline item! Now I have no idea about whether agileplatform™ is actually a good tool or not, but I do know from perusing their website that:

It is being sold to budget-holders as a mechanism to deliver faster, at lower cost
It is being marketed as 'Agile'
It is very glossy
"Develop an app in 4 min with minimal training"!

This is the Visual Basic (or PowerBuilder, for those of us who remember that far back) approach, dumb down the application development process to the point where you can employ more (code) monkeys to throw at the task.

Of course, those of us who were around back then will remember just how much of a pain VB or VBA development was, once your problem started to get just a little bit hairy, or strayed just outside the comfortable boundaries of what VB allowed you to easily do. The reason that graphical programming environments haven't replaced text-based ones is quite simple:

Human Language

We humans communicate in spoken language. When we have no access to spoken language, we communicate with the written word. We have been doing this for over six thousand years. Let that sink in for a moment...

Humans do not communicate in sign language, except when other constraints (physical disability, environmental inhibitors) force us to. We do not naturally communicate by drawing pictures and diagrams (no, Kanji doesn't count, it's just text in a different package). Where we do communicate with pictures, we need text to interpret, disambiguate or elucidate the pictures (e.g. viewing notes under pictures in galleries). Human language, the spoken and written word is what we are wired to understand. Until computers can reliably understand the spoken word, the written word is how we will best communicate with computers.

I don't need to look at academic studies to know that using the keyboard is faster than using a mouse and WIMP interface, my own experience and that of many thousands of highly-skilled professional developers around the world corroborates this fact. So if writing is a faster, and less error-prone way to communicate, then why the quest for the Holy Grail of programming in symbols and graphical IDEs?

Children learn first with pictures. So do monkeys. The obsession with graphical IDEs is all about dumbing-down programming (some would say 'democratisation') in an attempt to make the highly complex and error-prone task of software development amenable to the kind of management practise that throws ever more resources at the task. This is about the commoditisation of our craft, the creation of 'software factories' - nothing more than William Blake's 'Dark Satanic Mills' - and the destruction of local industry and the enslavement of the workforce. Socialism aside, this is directly in contravention to:

Agile principles, which value "individuals ... over process or tools", and
the principle of software development as a skilled profession (not even considering the lofty heights of 'computer science' or 'software engineering')

So just like children with picture books, graphical programming is an excellent way to learn as a beginner, but like picture books is a training tool that is quickly outgrown.

However, oppressive management would rather that software developers are kept dumb and cheap, disempowered and limited to being 'plug-compatible units' (as IBM famously referred to us). This is not a future which bodes well for either the professional software developer, nor industry or the global economy as a whole. The inflection point at which software costs started outstripping hardware costs happened in the 1970's, software, and the intellectual capital encompassed by an organisation's knowledge workers are the true wealth of the 3rd millenium's global economic engine, without our ability to innovate and rapidly deliver information-processing solutions, businesses falter and wither.

As such, it is important that we software developers recognise that we are not factory workers, we are highly skilled professionals, and our craft is one at least as dynamic and demanding as the legal and medical professions. If we settle for being the lowest common denominator, then we will have sealed our own fate as the wage-slaves of the new millenium. To that end I espouse not some kind of neo-Luddism, but rather a celebration of what makes us special: the ability to reason and analyse, to innovate, to program with skill and care, and the ability to continuously learn and improve, embracing the Agile principles and contributing to our own and other's welfare through Open Source contributions. In this way we will always rise above the sea of mediocrity, and hold our heads proudly aloft as the adventurers of the new digital frontier!

"...a person needs new experiences. They jar something deep inside, allowing him to grow. Without change something sleeps inside us, and seldom awakens.
The sleeper must awaken." -- Duke Leo Atreides

Thanks:

1. David Green for making this connection to Richard Feynmann's Caltech commencement address about Cargo Cult science.

2. Frank Herbert for 'Dune' and my closing quote.

Mismanagement of publicly-funded projects on an Olympian scale

2010-04-09T16:12:00.000+01:00

Today I read the following article: London Olympics Says 'No' To Open Source | eWEEK Europe UK http://bit.ly/9kfZ9x

The article is a short account of a talk that Gerry Pennell (CIO of the London Organising Committee of the Olympic and Paralympic Games - LOCOG) gave at the Green IT 09 conference in May last year. I know, I know, a bit behind the times; maybe I should get out more instead of hiding under this dark rock. You kind find a speaker profile of Gerry Pennell here: http://bit.ly/cIsECG

Mr. Pennell before his current appointment worked as CIO at Co-op Financial Services (CFS) and before that at PWC and Barclays. His previous experience as technology director for the 2002 Commonwealth Games (generally considered to be a success, except by the local residents, who complained that the promised 'urban beautification' of Manchester city centre turned out to be nothing more than the temporary hiding of unsightly views by erecting hoardings and banners) is obviously what put him in the front running for the role in the LOCOG. His experience with Co-op seems to have been centred around cost-cutting measures by supplier contract consolidation and renegotiation - Case study: Gerry Pennell Co-operative Group - 20 Jul 2006 - Computing http://bit.ly/aUE50H

His career began after graduating with a maths degree as a project manager with Barclays (source: http://bit.ly/bH5uVS) so like most CIOs he's never had a technical background.

The article basically talks about one simple thing: should the IT infrastructure of the London 2012 Olympics run on Windows or Linux servers. Well, obviously Linux right? Right? Nope. Mr. Punnell says that he couldn't consider Linux as "Open Source software represents too much of a risk in terms of application compatibility", which by 'compatibility' he means presumably 'runs Windows apps'?

Which is a bit like when being asked what you would like for dessert, and given a choice of cheese or fruit saying that you wouldn't consider fruit, because it doesn't taste of cheese.

Except that it's worse than that, because Linux DOES run Windows apps (WINE, the WINdows Emulator: http://www.winehq.org), but obviously Mr. Punnell hasn't learnt this in his many years of running successful IT projects. Or asked anyone technically competent on his staff. Which either makes him a liar, or surrounded by idiots. Neither option sounds terribly flattering.

He further says that he doesn't believe that Linux is more efficient than Windows: "I doubt it drives any huge difference in terms of the number of servers involved” - hmm... obviously he hasn't read the TPC's benchmarks that show that the top 10 performers are, wait for it, all Unix variants (4 of the top 10 are Linux). None of the top 10 performers run Windows http://bit.ly/3sBFQr

Well, it's easy to be confused by Microsoft's FUD I suppose, I mean it's obvious most of the world's servers run Windows, right?

Even Steve Ballmer (CEO of Microsoft) said in Sept '08 (http://bit.ly/9544md) "Forty percent of servers run Windows, 60 percent run Linux, how are we doing? Forty is less than 60, so I don't like it. ... We have some work to do." You can pretty much guarantee that the figures were actually higher than that then, with the creative use of statistics. Remember that this is all server use, including every tiddly little company MS Exchange and network share server not 'server use by significant operations'. For that you could look at say, Top500.org which monitors the 500 most powerful computer systems in the world:

Operating system Family share for 11/2009 | TOP500 Supercomputing Sites http://bit.ly/kNmx1

What is Microsoft's market share here, where it is free to exercise it's corporate muscle for the biggest computer projects in the world? Surely much higher than 60%? 80%? 90%?

Try 1%. Yes. One percent. ONE freekin' PERCENT.

89.2% of those are Linux.

So if 99% of the 'serious' IT projects in the world don't use Microsoft Windows Server, you would want to use it over a FREE alternative because? Come on, help me out, I'm struggling here...

Bear in mind this is public money that we're talking about here. My money. Your money.

It is interesting to compare his recent comments with an interview he gave Computer Weekly in the run-up to the 2002 Commonwealth Games, about precisely the same thing: http://bit.ly/bRO6ZY - in this article he also states the same rationale. He quotes the example of the Sydney 2000 Olympics (an IBM/Linux solution) and says that despite considering this solution, which was proven, he went with an all Microsoft solution because "some of the specialist applications were only available on a Windows platform" and "Multiple platforms would add to the complexity". When the only tool that you have is a hammer, then every problem begins to look like a nail, perhaps?

But when we delve into this a little further, we learn that two specialist companies were involved with the timing (Swiss Timing) and results (Delta Tre). Delta Tre produces results services that run on their MAGMA platform, which is powered by Red Bee's (formerly BBC) Piero product, which runs on... wait for it... Linux!

Technical Information | Piero "The operating system is Linux based which has excellent performance and also has the advantage of being more stable than other operating systems. " http://bit.ly/cFeiw7

Swiss Timing on the other hand appear to use their own proprietary protocols and systems. So no Microsoft solution here either. So if the 2002 Commonwealth Games systems had to integrate with Delta Tre and Swiss Timing's systems, neither of which use M$ standards and protocols, the advantage of using a wholly M$ solution is... obviously not the stated multiple platform complexity argument, but something else entirely.

So here we have one CIO doing what comes naturally: shaking a familiar hand at Microsoft for the London 2012 Olympic procurement just like he did for the Manchester 2002 Commonwealth Games. Except that the difference here is that there is a new government policy ("Government levels the playing field for Open Source" http://bit.ly/ku6DJ) that states that Open Source alternatives must be considered, and discounted before a proprietary solution can be procured. Personally I suspect that these policies may have arrived too late for this procurement (unfortunately) or the outcome should have been very different.

Why would anyone that has nothing to gain from a tender for a procurement that is funded with public money want to spend millions fattening the wallet of M$ shareholders? I cannot say.

Twitter 'stalking'

2010-04-09T10:39:00.010+01:00

The Metro paper this morning had a half-page article on how a young lady 'stalked' Crimewatch TV presenter Rav Wilding. On Twitter. Think about that for a moment.

The Random House dictionary defines 'stalk' as 'v. to pursue (game, a person, etc.) stealthily.'

So that's 'pursue' as in 'follow', right?

And that's what Twitter is all about. It allows you to 'follow' what other people write. There's even a button that says 'Follow' on it. Perhaps Twitter ought to re-label the button 'Stalk'. Or perhaps not, as the dictionary definition is 'to pursue stealthily', and it's not very stealthy to follow anyone on Twitter, as you can see every last one of the people that are following you!

So by definition, on Twitter you cannot follow anyone 'stealthily', and hence by definition 'stalking' in the correct sense of the word is impossible.

It also mentions that the 'stalker', 24-year old Toneeta Beckford, sent "lewd pictures of herself posing in her underwear" to the obviously traumatised victim, Wilding.

So what kind of person is this shy retiring wall-flower?

Let's look shall we? According to Wikipedia he is 32 years old, an ex-police officer and ex-paratrooper who looks like this:

Oh-kay.

According to Wikipedia "he has appeared in various magazines and publications, including full page pieces in numerous editions of Heat magazine, and an appearance in the gay monthly Attitude."

Right. Shrinking violet, obviously. Perhaps there is more to this case than meets the eye?

Personally, I don't care about what the sordid details are with the interpersonal relations between Ms. Beckford and Mr. Wilding. No, what really aggrieves me is the terrible standard of reportage in the British press.

You cannot 'stalk' someone on Twitter, as we've proven above. The courts obviously agree, as the Ms. Beckford was found guilty of harassment, not for 'stalking', or even 'cyberstalking' as the article subheading states. You can 'follow' someone, but hell, that's exactly what Twitter was designed for. If you don't want to be followed, don't use a web service that has 'following' people as its sole purpose! Doh!

It really irritates me when journos think that because they use technology everyday, that this somehow makes them an authority. This is similar to me professing that I am qualified to write about genitourinary medicine because I go to the toilet regularly. Perhaps if a story contains an element of technology in it, whether it's social media, the Internet or even something less mainstream, the journalist should have the good sense to speak to an area specialist on the publication's staff, rather than assume that their own expansive knowledge of the subject (i.e. consummate to the challenge of telling the world what they had for lunch in 140 characters or less) is the be all and end all.

I'll make this offer to any journo I meet: I'll help you with your appalling lack of knowledge of Technology if you help me with my similar lack of knowledge of style and grammar, KKTHXBYE

Labour computer blunders cost £26bn

2010-02-25T15:03:00.005Z

The following comment was made to the article:

Labour's computer blunders cost £26bn

"The trouble is to our political elites, science, engineering and technology, are all foreign languages; poor simple souls they think mathematics is arithmetic. Manufacturing and science are no longer labour intensive activities, but rely on highly educated and skilful personnel; are no longer in the business of mass production but make high value, advanced technology devices using advanced manufacturing processes. They have nothing to offer organised labour, which is why under a Labour administration; manufacturing has fallen from 20% of the economy to 12% of the economy. And the trashing of our financial services will do even more damage to manufacturing. That anybody cannot see that we need both, suggests a monumental ignorance by our politicians of world beating proportions.

The political aristocracy have run out of ideas. They are like First World War Generals of Cavalry, struggling to come to terms with poison gas, aeroplanes and tanks. They are poor dears, blundering about in a world that they do not understand. When mathematicians within financial institutions came up with financial models using the Black-Scholes formula and the Gaussian copula function, the non-mathematical bankers and politicians did not understand the limitations of these models and assumed naively that everybody knew what they were doing; after all everybody was making money so nothing could go wrong.

It has to be a function of a political class that is drawn from such a narrow set of experience that they do not understand that an enormous part of our life is now controlled by mathematical algorithms, once set in motion chunter on until they reach their conclusion. The inability to understand the implications of this is a failure of governance and a failure of leadership at the highest level; financial, political and intellectual. How right C P Snow was when he proclaimed in his lecture The Two Cultures; "If the scientists have the future in their bones, then the traditional culture responds by wishing the future did not exist."

It is the smallness of vision, the narrowness of intellect, the simple lack of courage and curiosity that shames us."

I couldn't have said it better.

Be alert! We need more Lerts!

2010-01-05T10:42:00.006Z

Just before Xmas the New York Times posted an article about how industry was having problems attracting good 'hybrid' knowledge workers, and how the problem was really that we're not getting enough graduates out of the education system with technical skills:

http://www.nytimes.com/2009/12/21/technology/21nerds.html?_r=1

In response to which we got this:

http://sengseng.posterous.com/the-5-quintessential-qualities-of-a-cool-nerd#

I must admit Amy is pretty on the button, but there's something missing. The original article hides the premise 'geeks are not cool' ('geek' please, 'nerd' is so 80's) following it up with 'we need to con kids into thinking that geeks are cool in order to get them to take on technical skills that our society (and economy) will badly need in the future'.

The problem with this is (as usual) the underlying presuppositions.

Computing, and by analogy all technology skills are not cool
Many kids are not interested in tech skills because the are not cool
Portraying tech skills as cool will get more kids interested in tech

Let;s take these in reverse order:
Item 3: the assumption that you can hoodwink kids into thinking something is cool when it isn't is something which is doomed to failure (as kids are a lot sharper than adults give them credit for). Look at what happened with the UK government's 'science is cool' marketing campaign in the 90's, which had little effect other than to convince parents that their government was willing to spend lots of money to get them convinced that they should tell their kids that science was cool.

Needless to say if you tell your child that X is cool, he or she is most likely to believe that it isn't because: a) parents are not cool, ergo anything that they think is cool must a priori not be, and b) sheer bloody-mindedness.

Item 2: I challenge the assumption that kids only learn stuff at school that is somehow 'cool'. Kids are interested in all kinds of diverse things, and it rarely comes down to what is 'cool', as this invariably means something entirely unconnected with school like pop music or pop culture.

Item 1: Tech *is* cool. To those that matter. What I mean by this is that the kids that are interested in tech see it as cool, they want to learn about it. Trying to somehow convince kids that tech is cool when they're not interested in it, in order to get them to learn it is a deeply flawed strategy. Instead, how about showing them how diverse, deep and wonderfully beautiful tech can be, and letting natural wonder and curiosity do the work?

The question as stated in the article amounts to 'how can we crank the school educational handle in order to change the ratio of kids coming out of school with tech skills', which is a bit like the tail wagging the dog - there are deep flaws with the current educational system that will not be solved by hoodwinking pupils with some kind of marketing campaign for tech.

Instead, how about:

Teachers in every discipline start showing how technology affects their own discipline, and teach kids about how technology works as a lever for almost all forms of human endeavour.
For classes in essentially technology oriented disciplines like Math, hard sciences and IT, start showing the inspirational side of Tech, from NASA to Nature, it isn't hard to find stuff that provokes awe and wonder, real SciFi.
For IT in particular, start with getting kids doing creative stuff, not MS Office and 'Theory of Computing 101'. Kids need to start with interest, not history and first principles.

By way of example, how about these:

http://www.nasa.gov/mission_pages/kepler/news/kepler-5-exoplanets.html
Life on other worlds? Awesome! Tick! Cool? Tick!

http://www.scientificamerican.com/article.cfm?id=vegetable-racing-car
Racing car made from recycled vegetables? Wacky? Tick! Cool? Tick!

In this way kids will get a chance to experience the 'WOW' factor of technology, and give them some aspirational material. Without a goal, it's very difficult to sit through a 101 class and actually learn anything, other than how to send txts to classmates without being caught by the teacher...

BT, FOSS and the National Programme

2009-10-06T12:38:00.005+01:00

Yesterday I attended the BT half-day conference "Accelerating Enterprise adoption of Open Source Software" in London attended by such luminaries as JP Rangaswami, Chief Scientist of BT and Mark Shuttleworth, CEO of Canonical.

The conference as a whole was a qualified success, but the thing that gave rise to an eyebrow was the heckling by the audience during the panel session of BT's mis-handling of the London LSP project for the NHS's National Programme.

What has Connecting for Health (CfH) and the National Programme got to do with Open Source Software (Free or otherwise) I hear you ask?

Absolutely nothing, I reply.

Disclaimer: I spent 5 years working on the National Programme, right from the very start, first with BT and then with GE, so I know a thing or two about the whole débâcle.

Now, one may well argue that our government should consider it a duty to investigate all open source solutions, before proprietary ones, as a matter of urgency given our current economic climate. That is by the by, the National Programme contracts were awarded to their respective prime contractors in 2002, arguably before OSS was ready for enterprise adoption, certainly before the time of OSS gaining a significant mind share. That is all water under the bridge.

Would the outcome of the National Programme have been different if prime contractors like BT and CSC had bid FOSS instead of proprietary solutions? No, but then that is not really relevant to the point here.

The reality is that once a project exceeds some arbitrary figure (let's say £1bn) it ceases to become an IT project, and becomes a political issue. Putting aside the fact that the National Programme was never an IT project, but rather a massive change management project masquerading as an IT project, the politics of large government projects become the major forcing factor in the success equation e.g. the opposition party has recently declared that they will 'dismantle' the programme in response to the 'Independent Review of NHS and Social Care IT' report. Originally budgeted as a £2.3bn project, the National Audit Office in 2006 estimated costs to be in excess of £12.4bn - that kind of political hot potato is a weakness that will always be exploited, and disaster stories are always good press.

So bearing in mind the politics, it's not surprising that some people would want to grandstand the panel and pillory BT over it's poor performance with government IT projects, specifically the National Programme. Much more interesting is the idea that OSS could help enable a leaner, meaner, lower-cost and decentralised National Programme.

Great idea, but another non-starter. Healthcare is still a big money business, and OSS has made little inroad here in the land of the giants. Whilst organisations like Tolven, OpenEMR, Mirth, GlassFish and OpenGalen are all great efforts, their impact on the Healthcare IT (HCIT) world is on the order of magnitude of a rounding error on the big Healthcare provider's sales ledgers. I foresee change, but it will take time, probably another 10 years, before we see any great advances - Healthcare is one of the most conservative fields in the world after all. You only have to look at what is happening with Obama's healthcare reform bill in the US right now to see just how difficulty-prone the interface of government and HCIT is.

I see BT's approach here as the right one - look to pioneer FOSS solutions in other business areas, build business ubiquity. When everyone else has made the shift, then healthcare will follow. So the logical next target on the road to get into healthcare in the UK is local government, leading to the much more interesting question that was put to the panel of 'why is government, particularly local government, so slow to adopt OSS in Britain whereas some other EU states like the Netherlands and Spain have been so fast to adopt it?'. Unfortunately the panel had a bit of difficulty with this one. I suspect that the reason for this is that in actual fact, there is already quite a bit of OSS in local and central government. True, we don't have the big headline-grabbing rollouts like Spain (Extremadura) or France (Open Office for Schools) have, but according to a survey by PSF (q.v.) 13% of councils are using OSS for their intranet, 11% for WCM, 12% for blogs, 17% for RDBMS and 19% for Web Servers. That's not peanuts. True, the largest inroads are already in the typical Linux/Apache/MySQL infrastructural areas, but Portals and other forms of Content Management aren't far behind. 5% of councils are using StarOffice or OpenOffice, which is already a healthy start.

The UK has already produced a policy document promoting the use of FOSS within government, but the 10-point action plan contained therein has yet to make it into OGC policy. When it does, the inclusion of things like exit plans into proprietary software solution bids will greatly help to level the playing fields for TCO between proprietary and OSS solutions.

With the burgeoning OSS activity in other (less wealthy) EU states like Poland and Spain, the number of published success stories will only rise - and with 30-40% of local government's IT budgets being currently taken with licensing costs (according to a survey by PSF) that leaves a very healthy market opportunity for Open Source organisations to exploit. Local governments are apparently eager to pursue OSS solutions, 64% of respondents said they were looking to increase their use of OSS (only 3% said 'decrease'), and 51% thought that their budget spend on software licenses was too high (only 21% thought they were 'reasonable').

BSI and the OGC are actively encouraging local and central government to prefer tenders from SMEs (see 2008 budgetary report "Accelerating the SME Economic Engine") and have even set up a b2b portal specifically to promote SMEs bidding for smaller procurements (see Supply2Gov).

In short, after the conference I was going to write a piece on the dire situation of OSS with respect to government procurement, but all of my research actually points to this being a healthy growth area that the UK governing bodies are actively seeking to promote...

VoIP on the iPhone

2008-07-31T17:35:00.000+01:00

It's now 3 weeks since we released the world's first VoIP application on the iPhone, there at day 1 of the App Store, and what a wild ride it has been. The application (free to download on iTunes) has brought in as many paying subscribers in 3 weeks as our previous Nokia smart-phone application has in the past two years! Anyone who has tried to develop software for the iPhone/iTouch during the Beta SDK period will empathise with just how hard this has been, and just how intransigent and unhelpful Apple have been to the developer community during the course of the Beta.

Back last late July I saw that my CTO had one of those new-fangled iPhoney-thingies, so I schmoosed on over to have a look. It was fresh back from the US (the iPhone wouldn't launch in the UK till Nov) and espoused the typical Apple design philosophy. I noticed that the Jobs' mouse manifesto of 'one button is all you will ever need' had manifested itself yet again with the conspicuous 'home key' design, nevertheless the hardware designers had still managed to create a stylish and modernist device even when hamstrung by the evangelical zeal of their CEO.

I managed to convince our gullible CTO that if I could take the sexy new toy away for the weekend, then I would produce a native 'Hello World' app to prove that there was at least a shadow of a possibility that we could launch a real native VoIP application on the device. Remember that at this time we were being told that that there would never be native software development allowed on the device and that web-apps were the future; 'embrace the future, citizens!' - ironic how Apple has gone from being the underdog in the seminal 1984 Superbowl advert to the Evil Empire it railed against.

Of course, little did our CTO realise that all I wanted to do was get my grubby little mitts on the virgin device and would only return it once it had been digitally abused in every possible way you could imagine. Needless to say, with the help of NerveGas and the iPhone dev team's hacked toolchain I jailbroke the device, cross-compiled a simple app and even minicom'd into the baseband in order to SIM unlock it - ah, those were the days. Now it's all UUIDs, provisioning profiles and official SDK releases, ho hum. So I managed to convince my CTO that we should launch a product on the iPhone, and that I was the right person to lead the development. IWIN button!

We did a proof-of-concept at DemoCon 2007, then another for VON. Then the official SDK was released and we went all corduroys and sensible shoes. Then the steady leaks of the 3G iPhone began to build up, and at WWDC all was revealed, and the world and his dog were marvelling at the 'revolutionary' iPhone 3G. But really, how revolutionary is it?

I was reminded of the Mayor of New York's profound prediction on being shown the first telephone by Alexander Graham Bell - 'What a marvellous device!' he exclaimed, 'I can foresee a time when every city will have one'. For me the really revolutionary thing about the iPhone 3G is not 'the internet in your pocket' (although this is persuasive) nor the 'trouser-based computing' argument of computing power at your fingertips whenever you need it. Nor is the convergence of photography, telephony, GPS and internet the most revolutionary aspect - anyone remember the Nokia N95?

No, the revolutionary aspect of the iPhone v2 (rather than 3G, as I'm referring here to the firmware release rather than the hardware) is the iTunes App Store. The App Store? Bear with me on this. In the past the process of buying software has been a fragmented and somewhat user-unfriendly distribution model. If I want to buy professional software I must buy it in a shop, or buy it on-line from an 'e-tailer' and wait for it to be shipped to me. If I'm lucky then I can download a trial version whilst I wait for the real software to be shipped to me, which may take several days to a week or more depending on package stocks and where it's being shipped from - a classic example being from Amazon (not even the marketplace) where although an item was marked as 'shortly available' I waited 3 months before being eventually told that my order had been cancelled for me as they could not source stock, and I had joy-of-joy been refunded. Thanks. Perhaps Amazon would like to refund me the interest, or even 3 months of my life. No, I didn't think so.

One of the really nice things about Open Source software is not so much that it is free (as in beer) but that being free I can download it, install it and run it NOW, not wait for my payment to be authorised and an activation key to be sent to me. Yes sir, it's in the post. Post?!?!?! Yes, you know who you are Orange. The success of direct2drive and other paid-for downloading services is a testament to the 'instant gratification' generation that our corporate masters and their media slaves has programmed.

People ask why I add cold water to my coffee - my answer: to cool it to a comfortably drinkable temperature, after all there's no point in having a cup of instant coffee and then having to wait for it to cool down to become drinkable now is there? That's hardly 'instant'.

iTunes is the instant coffee of the music world - you programme it with your details, and your preferred payment method, and then whenever you hear something that you like, you can buy it. Instantly! Just click!

Of course, having to synchronise your iPod to you desktop/laptop ruined the whole instant gratification thing, so now if you have an iPod Touch or an iPhone you can just buy tunes straight from your pocket, and hear them straight away. Marvellous. See - buy - enjoy, all within the course of a few heartbeats. Instant gratification - just add water. This has, of course, been a huge hit, and Apple have, and will continue to, milk it for all it's worth.

The (evil) genius[1] is in applying the same model to software. Buying software is now as simple as buying a hit single, once click and it's yours. One click and your money is theirs - 'they' being Apple and the evil alliance of music publishers and distributors. The master stroke here is that with the App Store Apple cuts our the publishers and the distributors, and takes a straight 30% cut of the whole pie, which is a win-win for both the software developers and Apple over the old model.

Let's say your friend has found this really neat app, which has a social element built into it e.g. Spore - you see it on their iPhone and go 'Wow! that's really neat - I'd like to play with you on my iPhone!' - you just go into the app store, click and buy and a short download later it's on your phone and you're happily evolving away with your friend. How powerful a marketing model is that? No 'oh, I'll have to remember to download that next time I'm back at my PC', and certainly no 'that's cool, I might even pop in and buy a copy next time I pass a Virgin Megastore'.

Apple now owns your pocket - the money in it anyway - and that's the real meaning of 'trouser-based computing'.

[1] How Apple Got Everything Right By Doing Everything Wrong - Wired, April 2008

Demon ex machina

2008-07-03T11:19:00.000+01:00

Why are speed cameras like software metrics?

Here I should state that I'm referring to a huge subset of software metrics that rely, to some extent or another on LOC (Lines of Code). Speed cameras are (or so we are told in the UK) a 'Road Safety initiative' that is designed to reduce the number of fatalities and serious injuries in road traffic accidents. A software metric is measurement of a software system's properties that is used (or so we are told) to increase quality and decrease cost and risk from software development projects.

So what do 'Scam-eras' and software metrics have in common? Easy: both use measures that are easy to determine, but that extensive research tells us are *not* highly correlated to the programmes stated objectives.

Context: At Google's Open Source Code Jam last month I had the pleasure to present; the theme of the event was 'Productivity'.

There were many interesting and thoughtful presentations on technical matters e.g. Continuous Integration and Domain Specific Languages cropped up several times. Predictably there was a lot of talk about the 'what' and 'how', but little of the higher knowledge levels of 'when' and even 'why'. This is not unexpected in a profession that always hits the top 5 in evaluations of levels of workplace stress.

I thought it would be interesting to look at what exactly we mean when we use the term 'productivity' in the context of knowledge workers. Productivity is well defined for other industries e.g. manufacturing - 'units of output per unit of input', or 'widgets per labour hour'. The problem comes when we try and apply the same reasoning to knowledge workers, what exactly constitutes 'output'?

Much research has been done around the LOC measure and how it relates to system complexity, cost and reliability. Unsurprisingly, this research tends to be littered with caveats and fudge factors, if you want to see for yourself take a look at COCOMO, or SMERFS. My own investigation into the research on this topic whilst I was at Symbian (working to improve their code reliability metrics system) is that the only thing that the research *does* prove is the positive correlation between LOC added/changed and the defect injection rate, which is hardly an earth-shaking revelation.

The chief complaint when using LOC as a measure of output is that the measure is one of volume of output, and is not representative either of a) effort or b) of value. Let me explain: Let's say Gary Guru has a complex problem to solve, and spends hours thinking of the solution before writing a small, elegant module with 1000 LOC. Now compare this with Archie Average, who only superficially analyses the problem and spends all his time coding a suite of inter-linked modules that solve the problem in 10,000 LOC.

Both have accumulated the same T&M cost (assuming the same labour rates). If we were to use LOC as a measure then Archie would seem to be an order of magnitude more productive than Gary. However, as we know LOC is positively correlated with defect injection rate, we know that we will spend at least ten times as much fixing Archie's code, and the TCO will be much higher after release as it will take considerably longer to diagnose and fix problems in Archie's rambling code-base than Gary's.

It gets worse as soon as the knowledge leaks out that developers know that they are being evaluated on the measure, as now they will attempt to game the measure. If a goal of the organisation is to encourage reuse (and what organisation wouldn't want to encourage what has become the 'holy grail' of software development?) then the implementation of LOC as a productivity measure positively discourages this, as every time I reuse someone else's code I appear less productive!

My own experience over my two decades of software development experience mirrors that of Douglas Hoffman who wrote the excellent paper: 'The Darker Side of Metrics' (Hoffman, 2000) which can be found here:
http://www.softwarequalitymethods.com/Papers/DarkMets%20Paper.pdf

He eloquently states that whenever you introduce software metrics to an organisation, there is a hidden 'dark side' effect based on how human beings will game with the metric to their own perceived advantage. Hoffman notes that if we predict that testing will find 100 bugs in the next testing period, this will become a self-fulfilling prophecy. If there are less than 100 bugs found then it will appear that the testing team are not working hard enough, and if much more than 100 bugs are found then it will appear that the development team are producing shoddy work, and as the testing and development teams work closely together in most organisations this would be bad for the interpersonal relationships of the teams. Consciously or sub-consciously the 'bugs found' metric will converge on the prediction, bugs will be split or rolled-up arbitrarily, reclassified as 'working as designed' or 'not to be fixed in this release' or any one of a number of other strategies to allow the prediction to be correct and achieve the 'win-win' situation.

Hoffman notes that the research seems to show that the only thing that the 'defects found per unit time' metric actually positively correlates to is 'testing effort'...

If you want to see a wonderful discourse on LOC as a measure and basis for productivity metrics in software development then you have only to look here:
http://forums.construx.com/forums/p/186/498.aspx#498

This was a piece that I found in my research for improvement of the 'codechurn' system at Symbian, and was highly topical as I had just come from GE, an early adopter and keen proponent of Six Sigma. The more experienced and erudite of the contributors voiced an opinion that mirrored my experience at GE, that whilst Six Sigma can and does do wonders for manufacturing companies, it's employment in software development organisations is problematical and anything but straight-forward.

With this in mind, let's return to the theme: 'measuring the output of knowledge workers'. We could posit that some sort of 'function point' or 'Use Case' based scheme of measurement would surely be better, the difficulty with this approach is that we need to normalise for complexity and granularity, as one 'function' is not necessarily as complex (and thus easy to implement) as another.

I remember asking my tutor during my post-graduate year doing comp-sci during a tutorial 'how do you measure system (rather than algorithmic) complexity?' and his answer: 'in inches'. Seeing my blank expression he explained that you took a ruler and measured the length of shelf space that the printed documentation took up.

It turns out that we cannot even measure (the much simpler) Algorithmic Complexity accurately, for anything above a trivial limit to system size, as the following paper 'Large Limits to Software Estimation' (J.P. Lewis, 2001) shows:
http://www.idiom.com/~zilla/Work/kcsest.pdf

Lewis uses an analogue to Godel's incompleteness theorem (Chaitin's incompleteness theorem) for Algorithmic Complexity to prove that it is impossible to objectively measure system complexity. This, at one stroke, makes a mockery of all those management methodology and software methodology zealots whose rationale for why their dogma does not produce verifiable, repeatable results is that 'the process was not followed diligently enough' or 'the measures were not made accurately enough' - the snake oil that they are pushing is simply *incapable* of delivering what it promises.

So the next time someone tries to foist their plan-driven dogma on you, you have some ammunition to counter them with! Hopefully we can move the industry away from the 'target-driven' mentality one project at a time.

Software storytelling

2008-05-22T11:09:00.000+01:00

Many cultures had, at their pre-industrial stages, a rich oral tradition of storytelling as a means of communicating knowledge, before literacy became widespread. Bards would gather people around the fire and tell rousing tales, inspiring and edifying a new generation of citizens with their practised craft of passing along knowledge, morals and cultural values using the medium of entertainment. It seems that now, certain sub-cultures have developed 'secondary orality' as Walter Ong [1] calls it, the creation of an oral transmission that exists alongside and is enabled by modern media, radio, television and the Internet. I propose that professional software developers can use the ancient art of storytelling to enhance their daily working practices.

I remember reading in Alistair Cockburn's excellent book 'Agile Software Development: Software through People' that Xerox discovered that their copier repair engineers didn't actually get most of their working knowledge from training or reading technical manuals, instead their operational knowledge was mostly gleaned from sitting around drinking coffee with senior copier repair engineers who would tell them tales of how they diagnosed or repaired difficult or obscure faults with particular models, whilst waiting for the next call-out.

When reading the original Gang of Four book on Patterns [2] I realised that a chord had been struck with my early teaching experience (I taught Computing at a local college of technology after finishing post-grad studies), namely that people learn better by example. I have not however noticed a particular culture of software professionals 'telling stories' or 'describing patterns' in casual conversation around the water cooler in many of the places that I've worked, as usually people are so pressured that they talk only about the current task at hand. Discussion of 'patterns' tends to be limited to a sub-set of concrete formalisations rather than a contributory or exploratory activity.

In the UK, particularly in London where I work there *is* however a culture of going out for a drink down the local pub with your work colleagues, and there we do start to talk about previous experiences and start to share knowledge by communal storytelling - but surely this kind of information exchange should be encouraged at work rather than being left to the ad-hoc and time-constrained nature of an occasional after-work outing?

As an example of how this might work, whilst I worked for 3 we had a weekly 'architecture group meeting' (there were >40 architects at 3 during the pre-launch build phase), organised during the lunch break, where we would bring our sandwiches and listen to a presentation by a different group member each week and ask questions, it was a good forum for knowledge exchange and one in which we could explore architecture patterns and discuss better ways of working.

In further posts I'd like to elaborate on how the craft of 'storytelling' fits in with the tool-kit of the software professional, and how we can leverage this skill to help us both become better individually and to increase the organisational capability of the team you work with.

[1] Oral_tradition: Walter_Ong
[2] Gang of Four: Design_Patterns