Skip to main content


The Customer Paradox

We all have customers. Some of them are real live customers, people we deliver a tangible product to in return for financial reward and others are merely the next link in our production chain. Testers, for example, are customers to developers. The one thing all customers have in common is they are happiest when they are given exactly what they want. When I think back to the times I′ve been a customer, be it in a shop or maybe a restaurant, I remember how annoyed I was when given something I didn′t ask for and didn′t want. Even more annoying though, were the times when what I was given wasn′t what I wanted and it was what I asked for. This brings me to the customer paradox, which can be stated as, "the harder you try to define your customer′s requirements, the less likely you are to deliver what he wants." This is especially true about software development and, in my opinion, it′s largely to do with the way we approach project management. Yes, you′ve guessed it, I′m having a d

i do declare

Years ago, when I was a development manager one of my biggest problems was that nobody ever seemed to be able to tell me exactly where we were in the project! If I asked the developers, they would only ever tell me they were either 20% done or 80% done, even right up to the week before the work was due. Even when they were finished, there was no way of knowing the quality of the product until after it had gone through Quality Assurance. The other big problem was the Managing Director (we didn′t have CEOs, CIOs and CTOs in those days) hijacking developers to work on his own personal projects. Promises of a bonus combined with a warning not to tell anyone else occasionally left me bemused as to why things were taking so long. In those days I used traditional PM techniques and a well-known brand of project management software but even then couldn′t tell whether work was on track on a day-to-day basis. I would usually only find out work would be delayed on or around the due date, when a de

automatic coders

″We have separate analysis, design, coding and testing departments and most projects follow the corresponding phases in a more or less standard waterfall pattern″, said Jim, the operations manager. ″It mostly works well but we do tend to find a lot of defects at the testing stage and because of tight schedules we often have to ship before the defects are fixed, supplying patches to the customers later.″ It was no surprise to hear that the company was rapidly losing its reputation and its customer base. The sales and marketing department were constantly complaining of abuse and ridicule from the customers during contract negotiations. In response, as I often do, I drew a little picture of a project timeline, from project inception to product delivery and asked him, ″Where on this line would you least like to discover your defects?″ Occasionally, a respondent may claim that he never likes to find defects anywhere but the overwhelming majority say, ″Just before product delivery″ as did Ji

a testing time for all

The problem is not the defects themselves, although, admittedly, they are a problem. The problem is recognising where the defects come from and what causes them, I′ve found that opinions on this subject can differ quite widely. For example, I once worked for a boss whose argument was that defects can only ever come from a programmer. For him there were no two ways about it, only programmers wrote code and so only programmers could create defects, in his mind defects were a problem for programmers and programmers only. He believed the one and only cause of defects was bad workmanship on the part of programmers and even proposed a league table so we could identify (and remove) the worst offenders. The funny thing is, this same company had a very strict recruitment policy, putting candidates through a long interview process and quite extensive technical tests so they only took on the very highest calibre of developers. I would be surprised if more than one in a hundred applicants actually

merit badge

Duvet-Days! Ever heard of these? It′s a scheme that was popular in the USA a few years back. In it, employees were allocated a number of days where they were entitled to call in and not turn up for work without having to give any reason. They could just stay home in bed, under their duvet, hence the name. I remember it because a company I was working for decided to implement a similar scheme in an attempt to combat absenteeism. Prior to the scheme, employees were trusted to manage their own attendance and any persistently absent members of staff should have been dealt with individually by their line-manager. The average number of sick-days taken the previous year per-employee was calculated and this was allotted as the duvet-day quota for each employee. The employees were to use the duvet-days whenever they felt unable or unwilling to come into work, for whatever reason, remembering, of course, that they need not give a reason. Once the duvet-days were used up, any further absenteeism

the evil that men do...

Society has changed, is changing now and will change yet again soon. It is always in a state of perpetual flux and yet we always think of it as a static, fixed and unchanging constant. Culture is the expression of society and the culture of any society leaves its mark on the world in the form of the artifacts it produces. Our definition of a culture is largely shaped by the legacy they leave behind. The Coliseum is one of the great legacies left behind by the Roman civilisation of two thousand years ago or so. It acts as a vivid reminder of a society that endorsed slavery, public displays of bloodletting, and many other forms of excess with a regularity almost unparalleled in the rest of human history. Mention the word Roman to anybody today and you could lay money that the first thought to enter their head would be Gladiator, always a popular subject for films too. Of course the Romans had a gentler side as well and produced much literature, poetry and other forms of fine art. In the