What Myths Can Cost You
Myths can help explain why things are the way they are. But myths can also be wrong or outright dangerous for you. Myths can convince you that you shouldn’t change a bad behaviour, that you can continue doing things the way they have been done for ages. At worst, it can put you out of business.
The process of buying a complex proprietary system is often shrouded in great mystery. In the commercial market it usually starts with meetings between a customer and several contractors. Eventually these meetings lead up to the production of an RFQ (Request for Quotation) or RFP (Request for Proposal). The RFQ/RFP is in basics the first (and not seldom the last) attempt to write a Requirements Specification. The RFQ is sent to each potential contractor, who replies with a SOC (Statement of Compliance). In the SOC, the contractor complies with each requirement as he thinks is best, which can be “fully compliant”, “substantially compliant”, “partly compliant” or “non-compliant”. The distinction between “substantially” and “partly compliant” is pretty cloudy, to say the least. The contractor usually writes more technical documents to ensure that their solution is the best. Finally, the contract negotiations start, and the contract are signed. Sounds simple enough? Well, lets take a hard look at how things are really done.
Often, a customer is not clear over how a new system can fully benefit his own business. From a technical point of view, he knows that he needs the system. But how the system should be built or integrated to best serve his commercial interests is not clear. Lacking specific technical and operational skills with the new system, the customer is forced to contract a consulting firm to write the RFQ. The consulting firm happens to know even less about the operations of the customer, but they do possess a technical knowledge of similar systems. So they write an RFQ, based on a product they have worked with earlier. And just to be sure, they add phrases like “flexible system”, “robust functionality”, and “easy to operate”.
When the contractor finally receives and reads the RFQ, he understands very little. Getting an insight into how the system best can serve operational and business goals of the customer is nearly impossible. Not to mention that the RFQ doesn’t fulfil fundamental quality properties, such as testability, clarity, or completeness. So everything is focused on the technical solution. Besides, shouldn’t the customer know these things anyway? After all, he is the one who byes this cra- sorry, excellent system.
The real problem starts when the project uses the RFQ as their only Requirements Specification. Requirements that are unclear and not testable are the foundation of the whole project. Up till now, everyone has agreed that the system should be expandable, fast and generally excellent – well, why shouldn’t it be? When the project reaches acceptance test, it gets critical, because you need acceptance test criteria that are clear, precise and waterproof. What you didn’t do with the requirements in the beginning, you are now forced to do with the acceptance test cases. And you have spent all those hours not knowing these things. Isn’t life wonderful?
Large companies are rigid, bureaucratic hierarchies that make you do things you don’t understand, right? Words like creativity imply freedom, and rules and processes restrict freedom, don’t they? We all know Dilbert, and some of us have seen movies like Office Space. We recognise the foolish and silly things, and we laugh at them. But maybe Dilbert tries to tell us something more. Managers use rules and policies to control people, because their power relies on this. Social control is fundamental in keeping power. Managers can even criticise your personality to get that control. Who wouldn’t be defensive and quiet in those circumstances, even if you know you have a valid case?
In truth, external control over markets, customers and their business is vastly more important from a profitability point of view, than internal control over social structures. Companies that don’t have control over external conditions will not survive in the long run. And there are companies that don’t even understand what is happening out there, on their own market.
To be honest, processes are also about gaining control over internal and external conditions that are critical to your success. Processes do control people’s behaviour, but they are not interested in power, and they will not muffle your creativity, because creativity is not the same as freedom.
Do you really think that great artists don’t have methods and recipes for their work? Think again. They may not have the words to describe what they do. They may use words like “it comes from God” or “it is just there”, but you can be sure they have certain ways of doing it. Their creative decisions are not random but based on experience, gift and other things… Picasso is supposed to have said: “good artists copy, great artists steal”.
We know very little about the creative process. One thing we know is that creativity feeds creativity – music can also stimulate it – but above all: the creative process is iterative. You will return many times to what you have already done, improving it over and over again. No artist would say that good tools are bad for their creativity. If you asked, they probably would tell you the opposite. Good tools enable them to put more time in the creative process, thinking creative thoughts. For a programmer this may be equal to having a good compiler, a fast linker and a powerful editor. But it can just as well be a good product structure, a structured way of handling changes, and good requirements.
Reviews
People may tell you that if your project only made document and project reviews, all your problems would go away. In reality, the organisation must be experienced in using such tools to deal with all its quality problems. If you are experienced with reviews, all these benefits will come true. But most organisations are not. It is not uncommon for people to spend 30 minutes or less preparing for a review on a 30-page document.
Not having the experience should not, however, put you off. The best thing you can do is to put inexperienced reviewers to learn from experienced ones.
The secret of your success
The secret of your success is not to deliver the right solution. The secret is to understand the problem, to formulate the problem, and to ask the right questions. Thinking that you can deliver a solution to a customer without knowing their problem is – to be frank - plain stupid. But everyone does it, all the time, so you can do it too – right?
In school we are trained to solve problems, not to formulate them. As engineers we are trained to solve equations, not so much to put them together. The problem is always given. But the world doesn’t look like that. The customer is not going to hand you a problem statement that lets you come up with a perfect solution. At best, the problem statement is flawed, at worst it is simply wrong. Solving the wrong problem is a waste of time; in worst case it could put your customer out of business.
I am a programmer!
Some programmers may tell you: “I don’t do documentation, I code.” The truth is that people who can’t write complete sentences in a document are not good programmers either. If you don’t understand why testing is done, or why you need to write requirements, you will probably not understand the need for a consistent error handling strategy, a memory management strategy, or a performance and reliability strategy either.
You may think of testing as an activity to uncover bugs and elevate the quality of your product. Testing is unquestionable an important part of Quality Assurance, but not the way you might think. Instead, testing shows you the quality you have.
The level of quality is actually specified when you write the requirements. It is built when you do the design and implementation. It is demonstrated when you test. If you don’t address quality during the requirements work, the quality is unspecified. You may talk about quality, and have certain expectations of it, but in reality you don’t know what quality the product should have, and there is no way you can demonstrate it during testing.
Testing is about demonstrating the quality you have, not about finding bugs. If you end up with 50 serious faults during test, you can only suspect that there are more bugs in the system, and that quality assurance has gone badly wrong during implementation. The lesson is: you cannot trust testing to give you the quality you want.
