Skip to main content

Posts

not what i meant (part two)

Currently, I'm staying in Bangalore and, as many of you may know, I like to keep myself presentable, so everyday I clean my shoes using the little tin of polish provided free by the hotel. Yesterday however, the housekeeping staff apparently didn't notice I'd used it and so didn't replace it, as they usually do when they make up the room. Now I could have gone, or called, down to the front desk to have them send me some up but it isn't really a big deal and it won't hurt my shoes to have them miss a day's polishing, so I just left a note on the bed this morning saying, "Shoe polish please." Imagine my surpise when I returned from work today to find there was still no sign of any shoe polish in the room but there was a very highly polished pair of trainers sitting where my grungy old gymn shoes had been this morning! Written requirements, eh? How can they not work? :)

not what i meant

Had a really good session with the developers while delivering the two-day TDD course at a customer site recently.  During the course I had quite a long discussion about Bob Martin, et al's concept of 'Clean Code' and recommended that the attendees each buy a copy of the book as I consider it one of the most important books on modern software development.  Later I spoke to their manager and he agreed to purchase a copy of the book for everyone.  Two weeks later I saw him reading a copy and asked him what he thought. "Well, I'm not really a coder but I see what he's getting at and it seems quite reasonable" was his response.  "Did you get copies for the developers?" I asked.  "No!" he replied, "I got  a copy for everyone , like you said. They can take it in turn to read it when I've finished"   Oh dear!

pygmalion water babies

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

jedward

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..."

bad science

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

eating it all?

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

certification?

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