Phase Variance
drifting aimlessly
Komplett Shite
Aug 17th
I recently decided that I needed a new hard drive and assorted other goodies, and so headed into the minuscule and overpriced world of Irish computer retailers. Were I to believe in God I would probably hold the assumption that He’s a bit miffed with me at the moment, as I ended up buying from Komplett. Actually, let me rephrase that – I ended up having money taken from my card without acknowledgement, and then got absolutely nothing for it. So then, I ended up being suckered by Komplett. As an online retailer, they have managed to get absolutely everything wrong and I would in all sincerity urge others to simply buy elsewhere.
Starting with the website, there were two problems: a third-party card processor; muppet coding. As I entered my payment details, the main page was not updated correctly and so no order was taken although the cash most certainly was, as I found out a few days later when looking at my credit card statement. It was me then who found the problem and had to instigate corrective action, not Komplett, and having paid through a third-party my position on making a charge-back is not as clear-cut as it might be. At this point though I was happy to overlook everything just to get my money back. Mistakes happen, and it’s often best not to dwell on them. They’re a well-known company, and I still had the naïve idea a properly-run one, so I looked to make a quick phone call.
That’s when I came across the third problem. The customer “service” telephone number is premium rate, and even when I decided to bite the pay-the-company-that-causing-me-hassle-to-sort-it-out bullet was automatically disconnected after two minutes. What this then means is that speaking with somebody is not only costly, but a lottery. Thinking of the hundreds of people everyday who will call at least once to speak with nobody, I wonder if a more cynical man than myself might be inclined to consider this not simply a means to control the rate at which problems must be managed but a bit of a money-making rouse as well.
In any case this did not concern me tremendously as an internet company suits internet channels, and so I sent an email to them. A couple of prompt mails later and I had my first promise of a refund. Of course, the money did not arrive but more conversation brought the assurance that the money was on its way. The money probably stopped off at the boozer and forgot all about me, so I contacted them again and that’s when I hit problem four – simply being ignored. The company had taken my money without letting me know and provided me with nothing, but felt it okay to ignore me following a succession of empty promises. It is at this point that you realise just how awful it is dealing with a shabby online business. When you can’t get through to them, what do you do?
In my case, I went to boards.ie. where they run a help forum – any reader should visit before considering a purchase, as at time of writing it is almost exclusively posts from people looking for money back with some having been kept waiting for months. Posting on here didn’t actually help me, but I did on the same day receive a call from the company. Given the sheer number of people to whom money was owed the “country manager” was going to speak with the people at the top, and it would all be sorted out in due course. Unsurprisingly, this came to nothing and I was yesterday forced to resort to the Small Claims System.
For a charge of €15 I have a chance of getting my money back, but it does grate that it has come this far. Why do I have to spend my time and more of my money chasing something that should not have been taken from me in the first place? I imagine that everything owed to all customers amounts to a tidy sum. As a lawyer, I would never wonder aloud if the company is hoping that those seeking return of smaller amounts will simply go away with nothing returned… but the cynical man I mentioned earlier might perhaps consider this in private.
For those finding their way here as being in a similar position, the company information you need is:
Company Number: 906016
Company Name: KOMPLETT BV
Registered Address:
UNIT 287
BLOCK G
BLANCHARDSTOWN COPORATE PARK 2
BALLYCOOLIN
DUBLIN 15
Review: Patterns for Fault Tolerant Software
Aug 11th
Wiley
Robert S Hanmer
ISBN: 9780470319796
Another in Wiley’s Software Design Patterns series, this relatively short tome is a concise and interesting development of a pattern language for fault-tolerant systems which the author argues is both functionally and morphologically complete. Hanmer’s style is as straightforward as I found in Pattern-Oriented Software Architecture Volume 1, and provides a solid introduction for those of us new to the area before moving on to present the patterns themselves.
The book begins by explaining the terms fault, error and failure and moves on to describe the mechanics of determining and understanding fault tolerance and its lifecycle: error detection, recovery and mitigation; and fault treatment. The chapter on development of a fault tolerant mindset is of particular interest as it, perhaps predictably, outlines many considerations which should be base-level for anybody carrying the title “software engineer”. A shared context for the patterns is defined, and we are introduced to architectural-level patterns such as Minimise Human Intervention, before continuing to review those grouped by the fault tolerance life cycle. Finally, Hanmer provides a brief overview of the interactions between these patterns before presenting the pattern language map.
This is another excellent book in the series, and another that I can highly recommend.
Rating: 
Backlog Fatigue
Aug 4th
I recently caused many of my front-line colleagues some degree of consternation, thanks to a tiny code change I made several months ago. In retrospect, it was a dumb thing to do as I had two choices and it was obvious that only one of them was correct. On the one hand, I could quickly patch a confusing section of undocumented and entirely untested code. On the other, I could spend an hour implementing a thorough design I had already prepared which would resolve the original problem intelligently, add useful functionality, add unit tests and refactor the mess into something better to boot. The first hand slapped the second out of the way, committed the change and and picked up a book. Now, I take significant pride in producing clean, maintainable and well-tested code and the book wasn’t even that good… so what happened?
Backlog fatigue, that’s what.
There are three backlogs in play at any one time: a product backlog, which details desired features in the long term; a sprint backlog, which defines requirements for the current iteration; and a bug backlog, which details changes required as and when possible. Managing the interplay of these over a number of iterations is the core of agile development, and the problem arises when the latter two merge into one and the product backlog is ignored whilst desired – albeit seemingly minor – features migrate directly to the sprint. The developer asks for more work and, with there being nothing new on offer, is directed to a list of ill-defined and ever-growing tasks which sit within the context of stories from previous iterations but have none of their own. The problems this raises can be immediate but are more readily seen over multiple iterations.
Firstly, the developer loses focus as he loses interest. He is no longer tackling substantive work with clearly defined purpose, but partial functionality which may necessitate ad hoc requirements gathering or – worse still – assumption. Secondly, this partial and ad hoc nature makes it increasingly difficult to estimate the overall testing effort required and this especially as more tasks are completed, or they become more splintered. This in turn leads to tasks being selected out of order and inappropriately, as the developer tries to juggle working time and basis of code change. Focus is then lost as confidence and direction wane in line with a reduced understanding of change impact. Increasingly work becomes about getting things done so that they are gone, and less about doing it right. It’s not good.
The solution here of course is relatively simple – don’t skip phases in the cycle, even when you feel that there is no new work to be done. Pull things back to the product backlog, reconstituted within or as new user stories which permit clear understanding and cover known scope. That is, try to make fixes and wants something incidental to continued development. Either that, or employ people to hit your coders over the head with a clue-by-four when they look like they’re about to make the same mistake I did.