Mark Robinson is a senior software consultant at TMC.

13 May 2016

For many companies software creation is not their core business, and so they don’t know how to create quality software on time and in budget. Mark Robinson, a consultant at TMC, shares his experiences.

When it comes to software, customers know what they want but not what they need. In my many years as a software consultant I have dealt with numerous companies of various sizes. These customers make cutting-edge products and many of them are household names in embedded software. They are world leaders in their fields and in the products they make. However, making software is not their core business. Their core business is making their fantastic, innovative products. Software is ‘a necessary evil’. This is especially true of small companies, which typically have just a handful of developers. For them, software is a part of those fantastic products, but not the reason they got started in business. So they’re not software experts; their expertise is in another field.

As a result, they simply don’t know how to write good software: high quality and on time. They don’t know how to write good, testable requirements. They don’t know how to create a solid, continuously improving test process. Nor do they know how to organize a software team for maximum efficiency and the best possible communication with management. And they don’t know that they don’t know this. They know their software is buggy and late, but they don’t know why.

Many of you will immediately identify with this situation. You’ve been developing software for some time and yet you know your process is ‘suboptimal’. When you do a release, you’re not confident of its quality; quite the opposite – you expect to hear about the first big bug any moment. Or you’re concerned that you haven’t correctly understood your customer’s wishes and will have to do a major rework. Or morale is low in your software team: they’re constantly working long hours to put out fires – and it’s been that way for far too long.

TMC Consultant Custome
Great software consultants infuse new knowledge into a company. The company knows its own domain intimately but has little knowledge of software development. This knowledge may be a deep understanding of Agile, test process automation or documentation tooling; ideally, it’s a combination of multiple skills.

Three-day scan

When companies become aware of the problem, they may try to solve it using knowledge they find in books. For example, they may read about Agile software development and try to implement it accordingly. This typically leads to disaster. Rigid implementation can create a process that is far too cumbersome for small development teams. And too often the team concludes: ‘Agile is not for us.’

BCe24 save the date

In my experience, the only way to create lasting improvement is to hire someone with a broad knowledge of how software is created. A top-notch software expert will contribute experience that the customer will instantly realize is completely different to its in-house knowledge – and therefore very valuable.

I was once asked by a company to assess its Agile software development process. Something in the team was not right, and team members were demotivated. My customer had concluded that Agile was not working for them and said they needed an expert to fix it.

I offered to do a three-day scan. On the first day I would interview all the team members and the manager – about ten people in total. On the second day I would prepare a report off-site. On the third day I would present that report to the whole team.

During that first day I realized something I hadn’t expected: there was nothing wrong with the customer’s Agile process. It was actually pretty good. I had some tweaks to suggest – for example, during the daily stand-up meeting the team should stand in front of the whiteboard and physically move the tasks onto sticky notes as they discussed them. But overall, the Agile process was working well.

The actual problem turned out to be a surprise: their test process was so bad that about half their development effort was spent fixing defects. This wasn’t because the people weren’t smart or willing to aim for quality in their software product. Indeed, they were aiming for quality in every sprint (and missing the target by a mile). It was simply that they didn’t know how to set up a rigorous, self-improving test process.

They didn’t know how to set up a test strategy or perform a risk analysis. They didn’t know how to hire, motivate and keep good testers. They had no idea how to report on the quality of their software to management. They didn’t even know what the quality of their software was.

Again, this wasn’t because they were stupid – they were very smart people. But software creation wasn’t their core business and so they didn’t know how to create quality software on time and in budget. And they are by no means an exception.

A more fundamental problem

Not long ago I had almost the exact opposite experience. A company that had just started developing software in the previous two years told me its software was very buggy, which it was. They’d had a lot of customer complaints and needed to take drastic action to improve their testing.

So I started a three-day scan. On day one I realized they had bigger problems than simply their software quality. They had no version control software, no test cases and no written requirements. They had multiple projects running at the same time with no clear agreements on what should be delivered. And tensions between management and the developers were building. Fortunately, the cause was simple – they lacked good software development processes – and therefore fixable.

On day two I prepared my presentation. In addition to recommending a quality improvement programme, I would be recommending they start using Agile software development. This would be a first step in defining clear agreements between developers and managers: what should be delivered when. It would also, if well implemented, give them a way to make constant, tailored improvements to their development process. And the regular demos would improve communication between the developers and the software’s stakeholders.

On day three I made my recommendations to the group. At first they just wanted to hear how to improve the software’s quality, but I told them they had a more fundamental issue. As I showed them my findings they gradually began to appreciate the enormity of the problem. So when I explained how they could implement Agile, they readily agreed.

My point is that these customers, and many others I have met just like them, didn’t know what they needed. They knew that something was wrong but didn’t know what the underlying problem was, much less how to solve it. They were like people who experience chronic pain and try to self-medicate rather than calling a doctor.


On multiple occasions I have seen customers throwing away money simply because they didn’t know a better way to create software. And even in the high tech industry there can be a fear of change. As US Rear Admiral Grace Hopper, the software pioneer, said: ‘Humans are allergic to change. They love to say: ‘We’ve always done it this way.’ I try to fight that. That’s why I have a clock on my wall that runs counterclockwise.’

I agree. I try to fight a fixed way of thinking and a resistance to change every day as well. And companies that embrace change will always outpace their competition by delivering quality code, on time, with motivated employees. It simply requires fearing change less than fearing standing still.

Edited by Nieke Roos