An Open Letter to Telstra regarding your customer service

Mon, 21 Sep 2009 19:35:09 +1000

To Whom it may concern,

I am writing to describe the experience I have had with Telstra over the past 3.5 months.

For the past two years I have had a telephone service through a local infrastructure operator, TransACT Capital Communications. With their services becoming increasingly less competitive I decided to move my home telephone back to Telstra, and on June 9 ordered a home connection. This connection was to be established on July 3.

On June 29 I received a voicemail message from a Telstra representative who told me that my order had been ‘lost’ and asked that I phone Telstra connections to resolve the problems.
Later that day I spent 80 minutes on the phone to a Telstra representative, yet was disconnected in the middle of the call and unable to place the order.

Several days later I successfully made the order to connect with Telstra, with a scheduled connection date in mid July. The day after the scheduled connection, when I confirmed that my home connection was still with TransACT, I phoned Telstra to find out why my connection had not been made. I was informed that my connection had been made, and after a lengthy discussion determined that the new number had been ‘connected’, but that the connection had not been made to my home. This component of the connection was due to occur on August 3.

On July 28 I received a bill for one month’s line rental. This was for the connection that had (technically) been made, but had not been provided to me. At this point I again phoned Telstra, requesting that the bill be withdrawn. The operator said that she would cancel the connected service, and confirmed a number of times at my request that this cancellation would not effect the connection due to be made on August 3, also stating that my home telephone number would not change.

On the evening of August 3 I attempted to phone my home to verify that the connection had been made. A recorded message advised that my old phone number was being forwarded to the new number, and a second message advised me that the number had been disconnected.

On August 4 I once again phoned Telstra to find out what had happened, and the operator I spoke to arranged for a technician to visit my home on August 11 to verify once and for all that the connection would be established.

On the evening of August 10 I received an SMS from Telstra advising me that the connection would be ‘auto-activated’ and that a technician would not be visiting the next morning.

On the morning of August 11, just as I was leaving for work, a Telstra technician arrived at my home to make the connection.

At last - At mid-morning on August 11 - more than two months after ordering a Telstra connection, I had obtained it.

On August 12 I received two bills, one for call forwarding from my old number to my new number and the other for line rental from 23 July to 10 August.
Regarding the latter bill, as described above I did not have a telephone connection during this time, attempting to bill me for the absence of a telephone line is reprehensible.
Regarding the former, of the five times I spoke with Telstra to arrange this connection, I was offered number forwarding only on the third occasion, which I declined. I did not request, nor desire, forwarding of my previous phone number to my new number. Furthermore, I was advised on the fourth occasion I spoke with Telstra about this connection that my old number would be retained.

On the afternoon of Friday, August 21 ADSL was activated on the line. I returned home later in the evening to discover that my phone line was no longer operational because a mistake had been made at the exchange. This was resolved on August 23.

Since that time I have received four additional bills from Telstra, three of which were for the ‘number forwarding’ account which I did not request and asked to have cancelled as soon as I received the first bill for it.
The third and fourth bills both included charges for line rental from August 11 - September 10. Because of the substantial amount of time I have spent to date endeavouring to resolve your billing inadequacies, and the inconvenient opening hours of your billing department, I am still attempting to resolve this issue.

In summary, the level of service you have provided to me has been worse that abysmal. I have invested well in excess of 10 hours of my time attempting to firstly obtain a telephone connection and secondly be charged correct amounts for this connection.
In addition to sharing my experiences I am seeking recompense under the terms of your Customer Service Guarantee, and summarise with the following key dates:

June 9: Ordered connection
August 11: Obtained connection
August 21: Lost connection
August 23: Regained connection

Disappointedly yours,

Chris Bennetts-Cash

Back to tech - Using perl to import Lotus Notes calendar to iCal

Sat, 18 Jul 2009 15:35:35 +1000

The last few hours has seen me back to my coding roots (yay!). I recently discovered that Lotus Notes 8.0, which is used at work for everything other than lunch, has the ability to export its calendar in iCalendar (.ics) format.
This set me thinking about how wonderful it would be to be able to have my work calendar on my iPhone, removing the necessity to rush from meeting to meeting via my desk to double-check where I’m meant to be going.

So I excitedly exported my Notes calendar to a .ics file on my corporate USB stick (that’s a story for another time), popped it into my my Macbook and imported the file into iCal.

Only to see no additional events in my calendar. I restarted iCal to see if it had gone crazy. Unfortunately not.
“Not to worry, I’ll do it via Google Calendar”. Looks like Google Calendar can’t read Lotus’ interpretation of the iCalendar “standard” either.

Bugger.

So I spent a couple of hours on Saturday morning fiddling with the contents of the calendar file to see if I could make it work.
Notes included a large number of timezone definitions. That probably makes some sense, but might not help matters. Then I discovered there were almost a dozen separate calendar sections within the XML file. Definitely not right. “I need to reformat this” I thought, firing up XCode and trying to think of the easiest way to implement it in perl.

I ended up with this, which works mostly - Although for my very large calendar (5 years, not 1) required an additional tweak. So if you’re suffering the same problem give it a go!

!/usr/bin/perl -w

use strict;
my $line;
my $event = 0;
my $endEvent = 0;

print<<END_PRINT;
BEGIN:VCALENDAR
X-WR-CALNAME:LotusNotes
PRODID:-//Apple Inc.//iCal 3.0//EN
CALSCALE:GREGORIAN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:Australia/Canberra
BEGIN:STANDARD
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
DTSTART:20080406T030000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
DTSTART:20081005T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU
TZNAME:EST
END:DAYLIGHT
END:VTIMEZONE
END_PRINT

while (<>) {
if (/^BEGIN\:VEVENT/) {
$event = 1;
} elsif (/END\:VEVENT/) {
$event = 0;
$endEvent = 1;
}
if ($event or $endEvent and not ( /^BEGIN\:VCALENDAR/ or /END:VCALENDAR/ )) {
$line = $_;
$line =~ s/\;TZID=(.)+\:/\;TZID=Australia\/Canberra:/g;
print $line;
}
$endEvent = 0;
}

print "END:VCALENDAR\n";

Simply run it from a terminal like so:
perl fileNameWithPastedCode.pl brokenNotesCalendar.ics > fixedNotesCalendar.ics

I mentioned a problem earlier - When run over my entire calendar file this didn’t change the effect of an import (even though it worked fine with a 12-month snapshot of my calendar). I don’t understand why, but when I opened the resulting file in TextWrangler the resulting file was double-spaced. Here’s what I did:
Changed the character format using TextWrangler to “Unix (LF)”:

Saved the file
Opened a terminal and ran the following:
grep -ve ^$ fixedNotesCalendar.ics

And it all worked!

"How do we sustain improvement practice in our section?"

Tue, 19 May 2009 07:10:39 +1000

I took a long weekend last week, and returning to work on Monday found an email in my inbox from a colleague who is venturing into the BPM waters. Needless to say I ignored it until I’d gone through the rest of my inbox.

Then I came back to it. “How do we sustain improvement practice in our section?” Of course we need to - we are all still aiming for the nirvana of business processes that are actively managed and continually-improved, aren’t we?

Here are some options I’ve put forward. What would you recommend?

1. Measure measure measure.
This is an area where we both aren’t very good and have the capacity to become very good.
If we capture measures of the effectiveness and efficiency of our processes and monitor them over time we can identify activities whose variation changes these measures & standardise activities to optimise our measures.
A very highly-recommended resource is Stacey Barr, her newsletters & articles at http://www.staceybarr.com

1. Apply Process Improvement methodologies such as Six Sigma, Lean, TQM, CMMI, ... that guide process improvement activities
These have a lot of potential but also potentially require a lot of effort to start & continue. The Six Sigma methodology is similar to what I’ve described in (1), define metrics that measure quality of any processes that contribute to outcomes & work toward reducing variation in these measures. Lean is about identifying & removing different types of waste in your processes, and I think is a very useful framework to guide process analysis - “what do we currently do that doesn’t add value?”.

1. Forget the frameworks and use the wisdom of crowds
Toyota, in addition to having led the world in process improvement methodologies (often being held up as examples of what we’re trying to attain with lean & six sigma), have developed an organisational culture where all staff are expected and empowered to improve business processes. They receive millions of employee suggestions every year, and (so I was told) around 40% of these suggestions are implemented, at least for a time. With employees knowing that they’re able to influence & improve all facets of the organisation (including influencing the nature of their work) people actually spend time thinking about how to do things better - And who knows better than people involved in the process what doesn’t work well and how it might be improved?
This option really excites me, I think it has a lot of potential if we can move past the cliché of ‘suggestion boxes’ and move toward a culture that strives for change and improvement.
And while changing culture is probably the most challenging option to pursue, I think it is going to be the one that best stands the test of time (provided it’s done successfully).

Enterprise-wide BPM in analytical services

Thu, 2 Apr 2009 15:36:11 +1100

It’s been six months since I last blogged. This has been for a number of reasons, but the biggest is that I’ve been so consumed between work and my hobbies that time spent at home has been filled with - incredibly - relaxing!

But I’ve come to the point where I need to tease out some ideas that are tugging at my brain, see if I can build them into a coherent picture, and solicit feedback from anyone who is interested (that’s you, right?!).

For this, I want you to imagine a hypothetical organisation of considerable size. This organisation is engaged in collecting, aggregating and analysing large amounts of data, across a number of quite different subject areas.
Over the decades of its existence each subject matter area within the organisation has developed independently from the others. With the current push to reduce costs and improve productivity there is now a recognition that these differences need to be united.

This has been attempted (or begun) a couple of times to date, with the involved parties soon floundering for want of direction. It is now beginning again, and with this work tying into the periphery of the BPM programme I’m currently leading (and for which the end of my involvement is in sight) I’m taking an interest in this project being successful so that it can envelop mine, taking responsibility for the “continuous improvement” phase of the BPM endeavour.

The progress to date
A high level process architecture has been defined for the organisation in focus, with all stakeholders agreeing to the architecture. This is at the level of “Acquire data”, “Process inputs”, “Aggregate data”, “Analyse & explain”, etc. Pockets of technology have been produced to meet various business needs within each high-level process, but no common methodology exists to guide people in the implementation of this process.

The progress from here
The programme leader is convinced that a business process improvement project is needed to define lower level process maps and ... improve productivity.

This screams out to me as missing a few steps, with no clear plan for how mapping lower level processes (which will be quite different for each subject area involved) will result in improved productivity. Pointing this out had two consequences:
- A number of people were annoyed at my challenge of their plan;
- I became responsible for ensuring there was a coherent plan for identifying (realistic) process improvements.

So here’s the plan - Please leave a comment to tell me what you think!

Members of the subject matter areas work together to identify a small set of alternative processes within each part of the process architecture that encompass the as-is processes being followed throughout the organisation.
This is the initial plan. At the end of this we will have a small number of as-is process maps for “Acquire data”, and for each of the other high level processes.

At this point the way by which each subprocess is implemented will probably differ throughout the organisation, perhaps significantly.

From here, measures will be identified for each subprocess of the above process maps to measure their efficiency, effectiveness and adaptability. Metrics will be collected to identify which processes are of the poorest health, and these processes - and these only - will be standardised throughout the organisation, with common techniques and tools defined as necessary to resolve the pain.

The result of this will be organisational business processes that are somewhat standardised - Processes that don’t cause problems will continue to work as they always have, implemented differently throughout the organisation; but processes that are points of pain will be fixed, standardised, and adopted throughout the organisation.

New stereo cables

Sun, 30 Nov 2008 11:40:50 +1100

A confession: This post barely qualifies to be part of this blog, but it IS about technology, just not the technology I usually write about.

But I recently got some new speaker cables, and they’ve made such a difference to the sound in my stereo that I feel the need to talk about them.

I got them all from Coem Audio Australia - A small store in Qld that specialise in high-quality Chinese hi-fi equipment. Their quality is great (but certainly not Van Den Hull), their service is incredible, and their cost is amazing by hi-fi standards (I paid about $300 for the four cables).

What I got:
Rose Voix DG1 75 ohm digital coaxial cable
This is a simple coax cable. Replacing this in my system and leaving everything else the same made a noticeable difference to the sound coming out of my DAC - the homemade coax cable it replaced was a relatively low quality cable because it seems impossible to find really high quality coaxial cable in Canberra.
This cable is now running from my Marantz CD7300 to my modified Lite DAC-AH non-oversampling D/A converter.

SoundRight SN2 interconnects (x2)
Twisted OFC cable. Got these because I wanted a comparison to my homemade interconnects (made by braiding two pairs of 12 gauge OFC wire for each cable). The twin shielding of these cables is great because of the stereo’s proximity to my Mac Mini.
These cables are now running from my DAC to my homemade audio switching box and from the box to my Sonic Impact Super T-Amp.

SoundRight LN2 Speaker Cables
These guys are shown in the photo above, and they’re absolutely huge. Replacing plain old CAT5 (two sets of four 12-gauge OFC twisted) cable they make a massive difference to the sound. My previous speaker cable was three CAT5 cables braided together (4 wires for each pole of treble, 8 wires for each pole of bass) and that was good. This cable goes a step further in bringing out the subtleties of my music. Connecting them up and playing what happened to by in my CD player at the time - The Left Side of The Fragile by Nine Inch Nails - revealed instruments, beats and nuances that I’d never heard before in my 8 years of listening to this album somewhat religiously.
Definitely the biggest change to my system from this shopping expedition, these are letting me rediscover my music collection.
Connected from my T-Amp to my Monitor Audio Bronze B2 bookshelf speakers.

Aside from the amazing sound, the other result of this little shopping expedition is that my speakers are now well & truly the worst part of my system. Which mean I finally get to replace them with some homemade copies of the Konus Essence transmission line speakers.

Where does CMM fit into Business Process Management?

Sun, 30 Nov 2008 11:00:54 +1100

As you might have guessed from my recent post about CMM, my organisation is currently looking at CMM and whether/why/how we should be adopting it to improve the maturity of our software development processes.
Hand in hand with that someone has recently asked how CMM fits into our BPM strategy.

I need to take an aside here to say that we don’t actually have a BPM strategy, but we need one. We have an increasing number of BPM adopters throughout the organisation and our lack of clear strategy or governance exposes the risk of letting down all interested parties by letting them do their own thing without any clear guidance.

But back to CMM and its place in BPM...
Business Process Management is an approach to management that improves the effectiveness of an organisation. The graph at the top of this page shows ‘the world of BPM’ - BPM encapsulates the three types of activity that are a part of process management. The axes on the graph can be pretty much anything you like - cost, time, effort, risk, potential return, ...

Process re-engineering is large-scale change to an organisation’s business processes - Essentially throwing out what you’ve got now because it’s completely ineffective and starting over again. Very high risk, very high effort and very expensive.

Process renewal is the usual domain of BPM - Looking at how you work now and changing components of the existing processes to improve their efficiency, effectiveness or agility.

Process improvement is the lowest level (i.e. simplest) process change. Essentially this involves ‘tweaking’ processes so that they perform better and more efficiently, and does not involve making large changes to a process (although there may be large changes to the way the process is executed). Perhaps the most common methodologies for undertaking process improvement are Lean and Six Sigma, but this is also where CMM(I) fits in.
CMM is a methodology for software process improvement, providing guidance on assessing where your software processes are and what you need to do to improve on your current position.

So, CMM fits nicely within BPM - albeit in a specific part (incremental process improvement, targetted only at software processes) - but is also a standalone methodology, so does not require an organisational BPM strategy to be successful.

There is a second, unasked question, about where CMM ranks in comparison to the increasingly-common, and incredibly powerful, combination of Lean and Six Sigma.
Since Lean Six Sigma is something I’m still increasing my knowledge of that is a discussion for another day. My impression so far is that changes should be governed by the analysis that Six Sigma provides, but that CMM provides a great methodology for identifying the specific improvements that can be implemented to resolve performance problems identified by Six Sigma.

Capability Maturity Model - I guess I'm a cynic

Sun, 30 Nov 2008 10:09:38 +1100

Since I joined my current workplace I’ve been complaining pretty loudly about our lack of well-defined and consistent software processes, and equally loudly made the claim that we’re at level 1 of the Capability Maturity Model (characterised by ad-hoc processes, with successes due to the heroics of individual people).
After making this claim for four years I am - finally - becoming better educated and have spent the last few days reading The Capability Maturity Model and understanding what it involves at a more detailed level.
And you know what? I was right. We are a level 1 organisation. But - and this is what surprised me and made me realise what a cynic I am - Only barely. With some rigour and standard processes for software estimation I suspect the bulk of the teams and projects would satisfy the requirements for CMM level 2 and be exceptionally close to - if not at - level 3. This has been a nicely-reassuring discovery, and I now have a desire to launch a mission to push for us to reach some consistent point (because I’ve got so much free time [sarcasm]...).

What this consistent point is I think will be only a few small steps from where we are now, and will see us with
• Defined ways for attaining - or at least justifying - estimates
• Defined processes - at a high level - of how we produce software
• Advice on how to tailor these software processes to specific projects

I think that this will place us well with respect to CMM level 3, giving us a level of maturity in our software processes that will (in theory) remove the dependence on individual people and provide enough consistency to be confident that we’re doing reasonably good stuff across the board.

So how can I do that? If you’ve got any suggestions I’d love to hear them!

Why should programmers care about OH&S?

Thu, 6 Nov 2008 21:34:01 +1100

I’ve been fighting the good fight recently, trying to convince influential people within my organisation of the value of having - and applying - OH&S standards for software development. Useability has always been quite a passion of mine, and I think that this is as good a reason as any for me to rant about why this is something we, as developers, should care about.

So why should developers care about occupational health and safety?

To answer this I’m going to take a step back and ask why we write software.
We write it for people to use. As much as we hate to admit it, and as much as we might just want to write software for the sake of writing software, the reality is that if we’re going to make a living writing software then we have to write software that people will actually use.
So we write software for people. That’s a great start.
Let’s list some attributes that we know are true about the people we write software for:
- They have a short attention span
- They usually want the impossible
- If they don’t use our software very often they’ll complain a lot if it’s not really ‘intuitive’
- If they do use our software a lot they’ll complain a lot if it’s time-consuming to do common things (regardless of how intuitive it is)
- Their bodies are designed to hunt and/or gather
- Their bodies are not designed to sit at a desk using a computer
- Their bodies are definitely not designed to push a mouse around a desk a lot
- Their bodies are also not designed to carry out repetitive tasks

So, applying these facts in the context of software development, where does this leave us?
1. Frequently used things should be fast but not necessarily intuitive
2. Infrequently used things should be intuitive but not necessarily fast
3. Fast is measured in terms of
a. Processing time
a. Time to invoke
b. Amount of keystrokes and/or mouse movements required to invoke
1. Frequently used things should be available by both mouse and keyboard commands (this means letting people use either, not requiring them to use both)
2. Things are intuitive if they’re easy to find by an inexperienced person with the same characteristics as the intended user. Without training.
5a. The intended user is usually not the software engineer who developed the software.

That’s all pretty basic, isn’t it? HCI 101. So why go on about such simple things?
Put simply - most people ignore this. And as a result users are forced to do repetitive tasks, get frustrated (and hence tense their muscles), and spend prolonged periods either using a mouse or keying. And this leads to us developers indirectly injuring our users, which isn’t a good thing (despite how appealing it might be sometimes).

So next time you’re about to write some software, stop.
Think about who’s going to be using it, and how they’re going to be using it. Don’t just code it however is easiest for you, or let the user interface fall out of reckless coding, but sit down, grab a pencil and a piece of paper, and think about how you’d like to interact with the system if you were the user.
 Even better, pick up copies of The Humane Interface, The Design Of Everyday Things and The Inmates Are Running The Asylum.
Then read them.
And finally, apply them.

Please.

DBC vs. TDD Part 3 - Conclusion?

Mon, 27 Oct 2008 16:31:22 +1100

Finally - Part three of my internal debate about the differences between Design by Contract and Test-Driven Development.
This is a week late because I’ve been on training for the past week. In fact, by the time I manage to find internet access and publish this it’ll probably be a week and a half late because I’m STILL on training, but this time in a different city - which just makes things even more difficult.

This week I’m going to (attempt to) tie together the last two articles and draw some sort of conclusion about where I think DbC and TDD should live.

OK, now that we’ve explored the definitions of DbC and TDD where does that leave us?

Well, we have a clear understanding that DbC is a methodology to ensure that a given unit of a system will produce the output expected of it, provided that the information passed to it is fit for purpose. We also know that it is a tool to encourage developers to step back and look at the forest before they begin coding - That is, it requires the person responsible for the unit of work to clearly define what the unit will do, and in which circumstances it will do it.

With regard to TDD, we know that it is a methodology to ensure that a given project artefact is fit for purpose - that is, it has been verified by testing a sufficiently diverse sample of use cases to cover all possibilities.
Again, TDD is also a tool that encourages taking a broader perspective - Before you start working on something you think about what criteria define success for that piece of work, and you write tests to verify those criteria.

So far TDD and DbC are neck and neck - They both sound like they’re offering exactly the same benefits.
But there are a couple of less-obvious differences...

1. When you’re following DbC and you think you’re finished you probably still need to write and execute tests (and then iterate). When you’re following TDD you only think you’re finished when all of your tests pass.

1. The paragraph on TDD isn’t talking specifically about units of a system, although it is including them. It is also including collections of units within a system, the entire system, and a collection of systems - TDD should be followed just as closely at every level within a project, beginning by defining the acceptance criteria for the project and ending by defining tests to verify the correctness of individual units within the project.

This really means - I believe - that DbC is a great thing. It’s a really great thing, and it’s probably not unlikely that it was a significant contributor to the development of TDD (I may be wildly incorrect in that statement, and I probably am, but you have to admit it’s possible!).
Just like all really great things, eventually something better comes along. Usually the something better is excommunicated or put to death as well, but eventually it comes to be accepted as better.

DbC offers so much benefit at the unit level within a software project, and TDD offers all of these benefits at all levels within a software project, from the unit level right up to the UAT level.

There are other arguments that are often used to justify DbC’s continued existence, and I want to run through them now because, frankly, I think they’re ridiculous.

1. Runtime assertion checking
Do you really want to do this? If you’re learning how to program at school then go for it, but checking your preconditions is just making work for yourself that you really don’t need to do. It’s also breaking the fundamental precept of DbC (or at least one of them) - That your unit has undefined behaviour if the starting contract is not met.
Throwing an exception isn’t undefined.

1. Contracts are general whereas tests are specific
True. How do you test your contracts?
Regardless of whether we’re DbC’ing, TDD’ing, or ABC’ing, we can only ever test specific cases. Our contracts might validate that our code works for the general case, but we only know that our contracts work for specific cases.
And while we’re on this point, once you’re happy with the specific cases in which you’ve tested your contracts you will disable any runtime, assertion-throwing contract checks for the reasons outlined in (1), won’t you?

1. Contracts discourage defensive programming
The thinking behind this point eluded me for awhile because the people who make the claim usually claim (1) first (which certainly IS defensive). But then a great colleague explained that defensive programming is discouraged because you’ve documented everything you expect to be true when your method is called, and you only write enough code to cater for this.
While I don’t believe that DbC discourages defensive programming, I do believe that it tries to, so I’ll put the difference between theory and practice aside for now.
This argument is 100% correct. Defensive programming means you’re doing more work than you need to, which is a bad thing.
However, I don’t think people need the reminder to be lazy anymore. We already have:
(a) Larry Wall’s three virtues of a programmer: Laziness, Impatience and Hubris.
(b) TDD encouraging people to stop coding as soon as their tests pass.
(c) Agile methodologies becoming increasingly-common and resulting in people running around saying “YAGNI”* rather than doing any exception checking at all - which is a much better thing to worry about than whether they’re doing enough.

1. Contracts encourage defensive programming
Yeah, go figure. I think this argument has something to do with runtime assertion checking so you can be sure that (a) your code has valid inputs, and (b) it does the right thing with them.
See (1).

1. DbC and TDD are complementary, damnit!
Maybe you disagree with my definitions of one or both of them, in which case that’s fine. But if not, this statement is right only insofar as it’s correct to say that lumberjacking and building timber furniture are complementary (I know that’s a terrible example - I’m sitting in a hotel without enough stimulus to come up with anything better. And I suppose it would be quite a convenient way to cut out the middleman if you were a furniture builder and a lumberjack. Damn. Let’s try again).

But if not, this statement is right only insofar as it’s correct to say that putting air into your car tyres and getting new tyres fitted are complementary - With one you get air-filled tyres; with the other you get air-filled tyres, new tread, a wheel balance, and you get it all done by Joe your local mechanic without lifting a finger yourself.

Anyway, if you haven’t gotten my point by now those two examples are certainly not going to help you.
In a phrase: The advantages realised by DbC are a subset of those realised by TDD, and a small subset at that.

* “You Aren’t Gonna Need It”. Like “TODO” but more agile, and hence more cool.

DBC vs. TDD Part 2 - Test Driven Development

Thu, 16 Oct 2008 22:15:56 +1100

This is part two of my DBC vs. TDD ramblings, where I’ll be describing Test-Driven Development and why it’s A Good Thing.
My ideas about what TDD is seem to vary significantly from what is commonly known as TDD. I think this is a result of tools being developed that make automated testing and TDD really easy, but these tools being used almost exclusively for automating unit tests because as programmers we find it very easy to focus on the details and forget the bigger picture - and as a result writing automated unit tests has come to be seen as the way to ‘do TDD’.

So here’s TDD in my eyes - Which I think is well-aligned with the ideas Kent Beck puts forth in ‘Extreme Programming Explained’ and ‘Test Driven Development’.

Each piece of functionality you’re going to implement has tests written verifying that it meets the outcomes required of it, before you even think about coding. What I want to point out here is that this doesn’t say “writing automated unit tests before you start coding”. That’s not TDD, that’s writing automated unit tests before you start coding. Maybe it’s ‘unit test driven development’, which is a subset of TDD - But this isn’t something you want to do at the outset.

We start TDD by defining the acceptance tests we’re intending to satisfy (i.e. the user stories we’re going to implement). We can automate these tests, or we can not. That doesn’t matter. What matters is that we’re using these acceptance tests to drive our development, rather than using what we’ve developed to write our acceptance tests. Doing this lets us know when we’re finished - The moment our acceptance tests pass we can confidently stop developing.
This is the part of TDD that is often forgotten, and which has started popping up under other names, including ‘acceptance test driven development’ and (I would argue) Dan North’s ‘Behaviour Driven Development’.

Once we’ve defined our acceptance tests we can start to think about implementation. When we do that we’ll probably want to write unit tests for our modules before we start writing them. Just like with design by contract, this helps us to step back and understand exactly what we’re doing as well as providing a way to know when we’re done.
This - the final part of TDD - is what now seems to be considered as the whole of TDD, and this is where we use defined (and perhaps automated) unit tests to drive the development of individual modules.

Next week I want to bring together TDD and DBC to see where they intersect and what, if anything, is offered by one methodology but not the other.

DBC vs. TDD Part 1 - Design By Contract

Thu, 9 Oct 2008 21:13:30 +1100

I’ve just finished reading ‘The Pragmatic Programmer’, which has one section devoted to the merits of Design By Contract. I came out of university four years ago with the idea that DBC was A Good Thing, and was using it for around six months before I began supplementing it with Test Driven Development techniques. This gradually turned into using TDD and forgetting all about DBC. Reading The Pragmatic Programmer has made me think about this in more detail, and made me wonder whether Design By Contract even has a place in software engineering now that TDD has become well-known and is fairly widely used.

This is the first of three articles where I wanted to explore this idea, find out what you think, and see what conclusions I end up reaching. This article goes into Design By Contract - What it is and why we might choose to use it. The second will cover similar aspects of Test Driven Development; with the third article comparing the two to see where they intersect and what (if anything) is offered by one technique but not the other.

So, let’s get started with Design By Contract.

Each piece of functionality you write has a ‘contract’ specifying what must be true when the method is called, and one specifying what will be true after the method has completed provided the initial contract is satisfied by the caller.
A class may also have a ‘class invariant’ specifying things that will remain true throughout the existence of a particular class instance.

The notion is that, before you start coding, you step back and think through which situations your method should operate in, and which it should not. Then you write these down as your initial contract. Next you think about what will be true upon completion of your method and write this down. These contracts might be automated or they might not be, that doesn’t matter. The point here is that you have documented all conditions your method must be successful in, and all conditions your method must satisfy upon completion.
Once you begin actually implementing your method you then have a reference point to look back on to ensure that you do everything you need to for all the conditions you need to cater for. This ensures that we’re focusing on what we need to be focusing on, acting as a verification and validation mechanism while we’re coding.

Why are software requirements difficult?

Fri, 1 Aug 2008 12:06:36 +1000

One of the new activities I included in the requirements capture course I wrote for work, and which is presented to both technical and non-technical staff within the Bureau, is an ice-breaking activity looking at why software requirements are difficult.

What is your favourite pen?
Why?

In comparison with a complex piece of business software a pen is a pretty darn simple thing, but even defining the requirements for a pen can be darn difficult.
Here are some suggestions to get you started:
• Diameter
• Weight
• Balance of weight
• Friction of ballpoint
• Viscousity of ink
• Drying time of ink
• Suitability for left-handed people
• Composition of ink (Allergies, ethical or religious opposition to the use of animal products)
• Colour
• Comfort when using for long periods of time

Risk management

Wed, 30 Jul 2008 23:06:35 +1000

I thought I had a pretty good knowledge of the standard for risk assessment (AS4360) until this afternoon - I was editing a risk assessment paper and it was pointed out to me that the approach I’d described (in the picture above) differed from another standard in the Bureau that also purported to be an implementation of AS4360.
A quick google showed me four more examples of a risk rating matrix, but rather than tell me who was right I’d ended up with six quite different approaches.

And so I discovered that the standard doesn’t actually promote a single approach to rating risks, which makes a lot of sense in hindsight. In the end I used the same approach as the other ABS standard because I felt it took into consideration our moderate, but not extreme, risk aversion.

Catching up

Tue, 29 Jul 2008 21:12:34 +1000

For the past six months I seem to have been doing the job of three people, and it’s led me to think about a few things (in the rare moments I haven’t been thinking about work).
Firstly about the terrible opinion people have of public servants. We’re not all lazy OK?

But I’ve also been thinking about how fascinating it is being able to develop a really close relationship with clients.
I’m a software engineer. I started programming when I was six (BASIC on a Radio Shack TRS-80). Earlier today I was giving a code walkthrough on the C++ automatic address coding application to a couple of the guys from Census; being able to think through and explain the custom memory structures and funky pointer arithmetic after not seeing it for two years filled me with an odd sense of joy.
But the guts of my work for the past six months has been getting a good understanding of how National Accounts Branch work and how they could work more efficiently or effectively, then setting a vision for change and leading teams within the branch through change; as well as looking for opportunities to make Prices’ work easier by spending a lot of time with them understanding all about the CPI.
Dear God that paragraph sounds wanky. Next thing you know I’ll be talking about synergies...

But my time doing things that sound like clichéd buzzwords have had an interesting effect. I’m surprisingly enthralled with the work these branches do, and am even a little tempted to move to the statistical side of things.
Having the opportunity to work really closely with your clients means you’re constantly learning new things, challenging yourself and developing relationships. And, even better, you’re doing all this while delivering better value to your clients - Having an intimate understanding of your clients’ business will often allow you to predict problems before they occur.

And so I suppose the point I’m trying to make is that being a software engineer in a non-software organisation is really interesting.

Till next time...

User Stories - An Introduction

Tue, 18 Mar 2008 20:26:36 +1100

I’ve been spending a bit of time lately writing new material for the requirements capture course we run at work as part of an attempt to revise the course to make it reflect modern techniques and best practices. While I was doing this I found an introduction to user stories that I wrote during my previous project when I began pushing an agile approach to get us to moving forward.
Reflecting on it, it seems like my approach to user stories is influenced mostly by Kent Beck (eXtreme Programming) and Alan Cooper (Interaction Design), and ends up much more verbose than the behaviour-focused style of Dan North. With this verbosity comes a finer level of detail, and I’m beginning to really see how complementary these techniques - specifying behaviour at a high level to guide the project and creating detailed user stories just-in-time - are. With that in mind, and given the current interest in BDD (If you haven’t heard of BDD check out Dan North’s articles at http://www.dannorth.net), here’s my diatribe on user stories.

The development of user stories from our requirements gathering meetings is an attempt to capture typical patterns of usage; I am not necessarily attempting to capture every possible pattern of use, nor am I necessarily attempting to enunciate every system response. The goal of my user stories is to allow me to identify the major entities in the Respondent module and the major activities performed on them, and to begin developing the Respondent module based on this knowledge.

Once this effort has resulted in an initial prototype of the Respondent module, it is anticipated that the application itself will serve as the main vehicle for identifying the outstanding requirements - When it is released it should fulfil its major functions (as specified during previous meetings), which industry studies suggest to be around 80%. From this point a number of incremental releases can be used to:
- Identify what is lacking. It is typically easier to identify what is missing from a product than to identify what is missing from a description of a product (and then to hope that your perception of the description matches with that of the person building it);
- Provide feedback on interface design. With a number of releases planned within a short space of time there is much more scope for making both large and small changes to the design of the application;
- Provide additional scope for defect identification, defect removal and regression testing. Providing a number of releases will provide the ability to release bugfixes alongside additional functionality, which provides scope for both verifying that the defects have been resolved and ensuring that this has not introduced additional issues;
- Prevent 'analysis paralysis'. A common occurrence during the requirements gathering phase of any complex system is an extended length of time being taken to finalise requirements because - since
the system is complex - we want to get them right. This is a major cause of failure in IT projects, and the use of 'lightweight' development techniques is one way to prevent it. Because we intend to release a number of versions of the Respondent module, each delivering incremental improvements over the last, at any point we can decide we've expended enough effort on the module and cease work on it - with a completed (although not necessarily 100% completed) application to show for it. This incremental approach is based on the common application of the Pareto principle to IT systems (that
the first 80% of the functionality requires 20% of the effort, and the remaining 20% of the functionality requires 80% of the effort); and
- Provide scope for changing requirements. Because the initial releases of the Respondent module will be focussed on delivering the most commonly-used functionality (which, by its nature, is less
likely to undergo change than the less-core parts of the module), requirements for peripheral parts of the module will be free to undergo change at no (TA) cost until their requirements are defined.

This concept of "Just-in-Time Requirements Analysis defines requirements only when they are needed – and only at the detailed required. It is an iterative process that expects and embraces change and makes it easy for requirements to evolve over time ... This allows development to begin with incomplete requirements and also provides a mechanism for incorporating feedback from actual development into analysis. The end result is a shorter project life cycle, better requirements, less risk, and an evolving baseline that meets the changing business needs of customer." (Michael Lee, The Agile Alliance).

The Business Process Management Framework and Business Analysis

Tue, 18 Mar 2008 19:10:55 +1100

Continuing with the theme of requirements capture, I’ve been writing some course material describing how the outputs produced by Roger Burlton’s Business Process Management Framework, when it is used, can be valuable inputs to requirements gathering activities. The BPMF can provide not only requirements, but users (I feel dirty using that word), priorities, and key performance indicators.
Here’s what I’ve written...

In situations where the Business Process Management Framework has been applied much of the work undertaken by the process analyst(s) can be leveraged to aid requirements gathering activities. This section briefly describes outputs of the BPMF that will assist requirements gathering.

Stakeholder Analysis
The stakeholder analysis phase of the BPMF results in a detailed study of all stakeholders in the system being studied. Referring to the stakeholder analysis will often reveal a number of functional and non-functional requirements, and can also be used to identify the names, roles and types of stakeholders without needing to cover ground that has already been covered as part of the BPMF.

"To be" Process Maps
Once a renewed business process has been defined as part of the BPMF detailed process maps are created to describe the renewed process. These process maps can be used as one tool to identify functional requirements - discussing the process maps with stakeholders is a useful method for deciding which parts of the process should be automated as part of the development project.

IGOE Diagrammes
IGOE (Input, Guide, Output, Enabler) diagrammes are created for each process analysed as part of the BPMF, and these diagrammes can be used as an information aid during requirements gathering activities. Because they provide information about what is used by a process, what is produced by a process, what guides the process or dictates portions of the process, and the systems and stakeholders that support the process they can be invaluable in directing requirements gathering activities and ensuring that key parts of the are process being developed are not forgotten.

Pain/Gain Analysis
One artefact often produced by the BPMF is a pain/gain analysis. This is usually represented as a scatter graph of processes with 'pain' (effort) depicted on the X axis and 'gain' (value) on the Y axis, and can be exceptionally useful for prioritising requirements.
When prioritising requirements using a pain/gain chart priority should be given to those processes whose renewal will provide the largest gain. Additionally, it is usually a good idea to prioritise the more complex processes over the simpler ones so that they can undergo longer periods of testing before the end of development. This will result in us prioritising the high pain-high gain processes first, followed by the low pain-high gain processes, the low pain-low gain processes, and finally the high pain-low gain processes (in reality these will often be identified as delivering too little value at too high a cost to be developed). In situations where stakeholders need to be 'won over' by seeing some quick progress made, some of the 'quick wins' (low pain-high gain activities) can be undertaken first to deliver actual business value in very little time.

Balancing the Triangle

Thu, 31 Jan 2008 20:28:26 +1100

In my experience, one of the things old software engineers like to do to pass on their infinite wisdom to young software engineers is draw a triangle on a chalkboard (a whiteboard would be more apt in these days where agile and its associated whiteboard-philia is all the rage), write 'time' at one point, 'scope' at another point, and 'cost' at the third.
The old software engineer then says "Now, young padawan, you must be firm against the dark client side who will try to sway you away from the truth. Tell them that they may control two of these factors, but that their choice in those two will dictate the third."

Apparently that's the extent of the wisdom a software engineer develops in their life. And nobody's quite sure what the point of the triangle is(1). But it's good advice nevertheless.

There's also a popular misconception that you can add a fourth factor - quality - to the triangle so that it becomes a pyramid, and allow stakeholders to select three of the four. But since all good programmers have hubris(2), that'll never work (although battles have been fought over it).

(1) OK, in actuality there is a point behind the triangle. The point is that there are three variables on a two dimensional space, which means that your client can pick any point inside the triangle and by doing so selects two of the variables and has the third determined for them.
(2) The three chief virtues of a programmer are: Laziness, Impatience and Hubris - Larry Wall, Programming Perl

The Road Less Travelled

Sun, 16 Dec 2007 20:30:43 +1100

So my next post was going to be all about the metrics I’d selected, why I’d selected them, and how I was going to go about analysing the results, wasn’t it?

Well it’s a funny thing. Everyone’s fretting right now because the good Mr. Rudd (our newly-elected Prime Minister) has made a two point something percent reduction in public service expenditure one of his first moves; and unfortunately when our clients were told (yet again) that they’d either need to commit to this project or abandon it, they took the latter option.

Scepticism

Tue, 27 Nov 2007 20:32:10 +1100

As I continue reading the PSM Guide I’m continuing to keep the targets of this study in mind - the entire technical services division within my organisation. The problem here is that, if history is anything to go by, what we will need is a methodology that is dead easy to follow and produces quick and easy wins.

Which is beginning to strike me as problematic, at least when it comes to metrics. The more I take in the less it seems like it can be done without the person/people doing it being willing to invest effort in a few different areas:
•Understanding the methodology
•Determining what should be measured
•Determining how things should be measured
•Measuring
•Analysing the measurements
•Reporting on the measurements

Don’t get me wrong, this still seems great. But I’m becoming somewhat cynical that it’s a methodology that can be enforced across all projects because, just like any other process, people who don’t care or are insufficiently committed can scrape by with the minimum effort to make it seem that they’re following the methodology and produce no benefit whatsoever.
Of course, if measurement reports are deliverables mandated at regular intervals by the project board, and irregularities or indicators of poor performance investigated when they arise, there is the potential for tremendous benefit.

The time for measurement selection grows nigh.
Stay tuned...

Practical Software Measurement - What Am I Doing?

Mon, 26 Nov 2007 20:33:58 +1100

So I’m in the process of going through the Practical Software and Systems Measurement Guide (http://www.psmsc.com/PSMGuide.asp) for the first time since university, and now that I’m actually doing it off my own bat I’m realising that there’s a crapload to read if you want to actually take something from it.
It’s quite unfortunate really - I’m reading a guide on how to implement measurement; reading how “measurement is good” is pretty much preaching to the converted.

But that aside, it’s nice to have a change and get back to my metrics-obsessed roots (see the archive for my previous articles/rants on estimation).

Why am I doing this? Well, we’re in the process of ‘redeveloping’ the system development process in my organisation because the one we currently have either doesn’t exist or doesn’t provide any benefit, depending on who you ask. The three options that really exist for a new process are:
•Define a set of outputs that must be produced (leaving the process up to the team);
•Define a small set of processes, any of which can (and must) be used; and
•Leave the process up to the team but define metrics that must be used so we can judge the relative success of different teams and processes.

Naturally I jumped at the opportunity to delve back into the world of metrics, and so it is that I am reading the PSM Guide, trying to refresh my memory but remain sane.

My initial thoughts when presented with this opportunity ran something along these lines:
1. It’s gotta be the PSM Guide or Humphrey’s Team Software Process.
2. Maybe this can help kick my dysfunctional project into line.

After verifying the first thought by a number of open-ended discussions (“if you wanted to collect metrics on how your project was going, what would you use?”) and, of course, Google; I decided that the best way to demonstrate the success (or failure) of a metrics-based approach would be to put them into play in my current project. All things being equal it should tell us that we spend too long making decisions, cannot gather requirements quickly enough to meet our production deadline, and cannot get acceptance testing completed early enough to have results feed into the next incremental release.

So here I am, trying to select a handful of the most appropriate indicators to use for my project and decide whether I should be measuring them monthly (recommended by PSM) or fortnightly (potentially more useful so I’ll have something to say about the process of collecting and aggregating measures in a month or two’s time).

Did I mention the time is currently 2359? I’m going to bed so I can claim I went to bed before midnight.

Stay tuned...