David Putman

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

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

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