David Putman

Some years back Colin, our intrepid consultant, needed to recruit a coach to help with the transformation at a customer site. On this particular day, he was interviewing what he thought would be an excellent prospect and had booked an interview room for the day so he could have some privacy. The candidate entered and Colin spent a little time chatting with him to put him at his ease. Once he felt the candidate had settled down he said, “Why don’t you tell me a bit about yourself and what you’re looking for in this engagement.” “Well,” said the candidate, “If you’ve read my CV, you’ll know I’ve been a coach for many years and have worked for many blue-chip companies. I’ve thought of myself as successful but, to be honest, I’ve always been a bit disappointed, too” Colin was curious and wanted to hear more about this. “So, tell me what you’ve been disappointed about.” he said. “The one thing that’s really disappointed me as a coach,” replied the candidate, “Is that so far, all of my custo

A prevailing Agile myth is that we don't do design but as I pointed out in a recent class, design should be continuous throughout development. One of my favourite areas of design occurs between defining the acceptance criteria for a story and going to code. It is here that the team needs to do: J ust E nough D esign W ith A ll R equired D evelopers to make sure that we have a shared vision of what it is we are going to build. We call this the JEDWARD stage... ...cue Doris Day, "Oh, the JEDWARD stage is a-rollin' on over the plains..."

My business is change. I like to think we help people to change for the better and improve by introducing tools and techniques we think are good practice. To do this, we rely on our own research but we also encourage our customers to do their own research, too, and for the most part what they find backs up our suggestions for improvement. Imagine my surprise, then, when a customer recently sent me a link to some 'research' from a company billing itself as a 'Research Lab.' To give it even more credence, the company trumpeted its very own 'Chief Scientist' complete with PhD. The 'research' was pretty standard stuff, they'd done some static analysis on a bunch of systems from large companies and had found out pretty much what many of us already know - most computer systems aren't written very well and there is an awful lot of technical debt around. There are many reasons for this, which, again, many of us are aware of, so I won't bore you by ev

It wasn′t that long ago when king-sized value packs were in fashion. Led by a trend for consumerism, it sometimes seemed the only way you could buy anything was in large or family size, big was beautiful and economy of scale was the order of the day. This still holds true, just as there will always be those who prefer to buy in bulk, there will always be products that are cheaper and easier to produce in batch quantities. However, the food industry, for one, has come to realise there are sections of our community who, for whatever reason, do not wish to purchase large quantities of their goods. These are not just people who don′t have the space for storage or the facilities to keep perishables in tip-top condition. More and more members of society are becoming aware of the health issues concerning the over-consumption of food and are turning away from consumption for consumption′s sake. Obesity has become a major threat to life in the western world. High-profile court cases, mainly in

You hear the cry all too often. ″Our employees are our biggest asset″ This is usually issued as a proud boast intended to indicate the high level of ability within the braggart′s organisation. We are meant to infer from this that the high levels of individual skill are, in some way, due to good management on his part and his organisation is one worthy of the highest esteem. But there is a lie here! What the boaster is really saying is his company relies heavily on individual knowledge and skills because they have not been able to figure out a way of capturing tacit knowledge, making it explicit and available to everyone. Results in his organisation depend heavily on individual effort and any success they have has nothing to do with good management at all. Most of us in software development have probably been there too. This is the code-and-fix organisation where everyone is responsible for their own section of code, where knowledge exists in silos and is jealously guarded. As far as CM

I was at a customer site not so long ago giving a course on Agile Software Development and part of the course was an introduction to test-driven development. (TDD) TDD is a process whereby the requirements are specified as a set of tests and the developers use the number of tests passing, or failing, to measure the amount of progress in the system. In the middle of one of my talks, the head of testing rose from his seat and asked; "So you′re saying that we should let the developers know what the tests are before they even start coding?" After I replied in the affirmative he responded with, "That would be cheating! If we did that, the developers would then only write code to pass the tests!" That particular manager′s opinion is one I′ve found to be reasonably common among testers and it′s one I′ve always found difficult to understand. There seems to be a general rule in some organisations that once the requirements have been captured, there should be no communication

We′ve all seen that scene in the movie where the family all gather round to hear the reading of the will. As the solicitor reads each name aloud, the expression on the corresponding face is a signal as to how welcome the bequest is to the recipient A smile, a gasp of pleasant surprise or, maybe, a frown of disappointment. A legacy is something that is left or given by someone who is now at a distance, making communication with the donor difficult. It is also an ′aide-memoire′, something to remember them by. Recently though, the term ′legacy code′ has come to mean code which is difficult to work on, partly because it can be difficult to communicate with the originator of the code but mostly because it is difficult to communicate with the code itself. This strikes me as strange because that is the very essence of the programmer′s task. We are not ′problem-solvers′, as some would have it. Calculating the V.A.T on an invoice or working out how to draw graphics on a screen are not ′problems