Posted by: Shilpa Venkateshwaran
The IT Files
The first person to be interviewed for “The IT Files” is James Christie from Scotland. He is a freelance Software Tester and has more than 24 years of commercial experience ranging from test management, information security management, project management, IT audits, systems analysis to programming. To know more about him and his work please visit http://clarotesting.com/index.htm.
James is currently working as a freelance consultant through his own limited company, Claro Testing Ltd. In 2007 he successfully completed a full-time MSc in IT at the University of Abertay. His master’s project and dissertation, for which he received an A grade, was “Integrating usability testing with formal software testing models”. He is particularly interested in how the quality of applications can be improved by incorporating usability engineering and testing techniques.
What were some differences you found between consulting (freelance) and working for other companies?
There are so many, though perhaps the biggest difference is between different types of freelance work. I don’t think freelance is a synonym for consulting.
I’ve worked as a freelance test manager, and that’s not much different from being a permanent test manager. Sure, the money is better and there’s no security, but the work itself is very similar. One significant difference is that a freelancer has less influence. They are brought in to do a specific job, on a certain project, and there’s little interest in hearing their ideas about how the world could be a better place.
A permanent employee will probably be around for the next few years. Their career and their future are hitched to the company. They’ve got skin in the game, and they will be listened to. A freelancer might offer ideas that others will pick up on, but if any action is taken it would be an entirely different project, and contract, and it’s quite likely that it will be others who get the work, particularly a specialist consultancy.
The freelance test manager has been hired simply because there are not enough internal bodies to do the work. The company already knows what they want, and how they want to do it.
However, permanent employees can also get frustrated at their lack of influence. Sometimes companies underestimate the talent and initiative of their employees. They don’t have enough confidence in them.
Often companies take on board criticisms and recommendation from expensive consultants, unaware that their staff have been saying the same things. Consultants know that. Part of the job is going round speaking to people trying to spot the ones that have had the crucial insights about what’s going wrong. Cynics say that this is just plundering the bright ideas that the company could have had for free – but the point is that the client has missed the opportunities, and the consultant is forcing them to focus on what was in full view, but invisible to them.
So the best place to have influence is to be a genuine consultant, not just a freelancer. I enjoy that. The money’s not nearly as good as freelancing. The rates might be great, but the work is almost inevitably patchy. You have to be prepared to go for uncomfortably long spells without being able to bill anyone, and you have to accept that sometimes you’re going to have a great idea ,and your client will decide to implement it themselves, on the cheap, rather than give you the work. Don’t go for consultancy just for the money!
What is one of your favorite books on Software Development or Software Testing?
I’m going to mention three books that I’ve found very helpful. Weinberg’s book is a great introduction, and refresher, to help ensure people “get” testing. The Poppendieck’s book provides a very readable analysis of what’s gone wrong over the years with software development, and Cooper helped me to look at software and the development process in a different way. I’m not sure about all of his detailed recommendations, and some of his criticisms were a bit emotive, but basically he was on the money.
Gerald Weinberg, “Perfect Software and Other Illusions”.
Mary and Tom Poppendieck, “Leading Lean Software Development: Results are not the Point”.
Alan Cooper, “The Inmates are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity”.
What is a skill or strength that sets you apart from other testers?
That’s the sort of question I find hard to answer. It’s easiest to refer to what other people have said about me. When I worked for IBM, I was chatting to the programme manager over a beer at the end of a project about what the future held in store for us. He said that I was a rebel, an iconoclast and that I was prepared to challenge existing practices, sometimes forcefully. We got on very well, and in the context of the successful project we’d been working on it was clearly a compliment. However, he wasn’t sure it was a quality that would give me a happy long term future in a big corporation.
More recently another consultant with whom I’ve been working said he liked working with me because I’m “an ideas man”. He thinks I come up with bright ideas that wouldn’t have occurred to others.
Being a bit of a rebel, and having the reputation for being an ideas man are great assets for a consultant, so I guess these are the strengths I need to emphasise when I’m trying to sell myself.
Cloud is the buzz word in the software development industry. Are you in the cloud yet?
No, definitely not, but it’s a fascinating development. To be honest, I’ve not seen any evidence yet of it taking off, but I’ve probably just been mixing in the wrong circles. I’m sure it will be huge.
For people who don’t know Agile, how would you define it for them?
This isn’t a definition, just a helpful way of understanding what Agile means.
Agile is a return to the natural way for developers to build systems. It’s a way that works, because it fits the inclinations and abilities of developers, and it fits the technology. If developers haven’t been indoctrinated in traditional techniques and heavyweight, document-driven methodologies, then their instinctive approach will be multiple, relatively small scale iterations.
It was a tragedy for the software development profession that they headed down the Waterfall, structured techniques route, assuming that building an application was essentially the same as building a bridge. if it wasn’t, then it had to be mutated into a form more like construction engineering.
Recently I had an informal chat about Agile with a senior development manager with a large IT services company. He said that most of the big clients he came across were still wedded to the Waterfall. I said, “it’s easier to manage the contractual relationship, isn’t it?”. He said “that’s it exactly”.
Basically, the whole profession went down a route for decades that was dictated by the needs of lawyers, accountants and contract managers. They’ve all got important inputs, but it was an appalling, fundamental mistake to pay attention only to them and ignore the realities of software development.
Quality was sacrificed on the altar of predictability. I believe strongly that compromises and trade-offs are often necessary. You don’t always get what you want, and smart managers have to be able to manage those trade-offs intelligently. You have to be honest and objective in admitting that you’re making these compromises. The great sin of software development for a generation was to pretend that these compromises weren’t there. As a result, they usually got neither quality nor predictability. For far too long the answer was to assume that they’d been unlucky, or (worst of all) people had just screwed up, and it would be ok next time. It’s a pity it took 30 plus years for the penny to drop.