The Code Whisperer

Let me say straight away that, outside of unit and system testing, I’m not an experienced tester. I believe you have to have a certain mindset to be really good at it and, although this may seem harsh, a passion for breaking things rather than building things, albeit all for the greater good. I met a number of exceptionally good testers in the past and they all share similar approaches, plus a slightly mistrusting look in their eyes.

The amount and quality of testing developers will carry out varies greatly. Putting aside any lack of enthusiasm for breaking their own code, other factors such as the architecture of the system, the quality of the test plan, if produced, and whether automated tools can be applied will influence the number of bugs remaining after system testing.

Many years ago I went to a short seminar about testing. It sounds boring but the managing director of the company leading the seminar was so enthusiastic about testing I came out enthused. He spoke in depth about a concept called the engineering V, where you have business requirements at the top of the V and development almost at the bottom. The design and development part of the project runs along the left side of the V, top to bottom and the testing part on the right hand side from the bottom to the top of the V. The idea was that you tested against the opposing specification, so unit and system testing would be against the technical design, user acceptance test against the business requirements and so on. The odd thing is that this concept is so clear in my mind over 15 years later but I can find no reference to it anywhere.

This concept does rely on top quality requirements and design documents being produced and test plans directly from these documents.

Personally I like the idea of being able to automatically test applications, so that the same tests can be easily applied against each build and release. Sometimes this consists of bespoke test harnesses testing software components, sometimes automated test tools attacking the entire application. I also favour having test plans for unit and system testing written as part of the technical design, with an indication of the plan’s successful completion forming part of the code
review.

Above all I value a user acceptance testing team that lives and breathes testing, but it’s important not to allow an “us and them” environment to exist between the development and test teams. I did hear a story about one company that attempted to improve the quality of its software by paying the test team a bonus for each bug found and the development team a bonus for each bug fixed. Needless to say the number of bugs found by the test team and fixed shot up dramatically helped by an “agreement” between the two departments, and the scheme was quickly dropped.

If you look at the collection and documentation of requirements for a software application as the foundations of a building, it’s easy to see why any weakness here has a major effect in the delivered item, whether functionality that can’t be implemented fully or delayed time to deliver.

Requirements gathering and documentation fail for many reasons, and each company and application will be different, however simply put you need to have business analysts doing this work that understand the business and know how to document business requirements and processes to people who don’t. It’s imperative that the business analysts write in a clear manner, clarifying complicated areas. In my view it’s better for the business analyst to spend more time producing a more understandable document than the developer thinking her or she understands it but wasting time developing in the wrong direction.

In all documents, not just business requirements and processes, I like to apply Rudyard Kipling’s epigraph from his short story The Elephant’s Child, which has become known as Kipling’s Six Honest Serving Men.

I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.

This on its own isn’t going to produce fantastic specifications, but I find it useful particularly when I know the subject matter well and need to provide documentation to people that don’t, whether it’s business requirements, technical design, user manual or operations manual.

Use of peer reviews on business requirements will improve their quality particularly if it includes reviewers that aren’t familiar with that part of the business or industry.

In my experience a significant amount of the difficulties caused by business requirements (and technical design) is that the author assumes that the reader has a higher level of understanding than they actually do. In a small company with a low turnover of staff you can get away with this, but in any other case it’s a recipe for disaster. If you are outsourcing work then business requirements and, particularly, technical designs must be of the highest quality to prevent a large number of test/correct cycles.

One last point is to do with testing, in particular user acceptance testing (UAT). I would expect UAT to concentrate on testing the application against the business requirements. In a sensible development the customer would have sight of the business requirements documentation and signed them off, or provided their own “list”. Issues found in the testing should reference the business requirements and some form of reference number. If that reference number hasn’t been followed through into the technical design and actual coding, then the ability to quickly identify the location of the problem, based on the business requirement, is lost. In additional any ability to measure the time and/or cost of developing different parts of the business requirements are just about impossible. I highly recommend that some form of reference to the business requirements is carried through technical design, coding and testing.

There are books and books about planning projects, and I’m not going to attempt to replace them in one short posting!

I have a few observations over the years I would like to share.

Planning not taken seriously. For a plan to be of any use it has to be thought out, realistic, published and have tracking of time spent and progress of the task. In my opinion task need to be split down to a daily level for the plan to be worthwhile, otherwise it’s harder to know if the progress is behind the plan. If any of these don’t apply, and normally it’s most of them not just one, the planning process isn’t being taken seriously enough for it to be a worthwhile exercise.

Tasks missing. It’s easy to omit tasks from a plan and often they are common run of the mill activities that would take place as a matter of course. However omitting them from the plan has an effect - it’s time spent not allocated, which could cause the project to slip. I look at a plan as any other project document and have it peer reviewed and/or reviewed by the project team. If tasks are identified later in the project it’s crucial to add them in for three reasons. 1, you are more likely to remember them next time; 2, it allows you to adjust the plan and, if required, delivery dates; and 3, there’s an indication the task has been carried out.

Not revising estimates. Often estimates are carried out by the wrong people - sales staff, senior managers or customers. Estimates produced by developers sometimes are under the actual time required. We all know this, but revising estimates and the plan is very rare. Why?

Abandoning the plan. I’ve seen this time and time again. A project is late or chaotic, so any attempts to maintain the plan or any measured progress of the project are abandoned. The project then goes out of control, with any delivery dates a stab in the dark. It is possible to regain control of a project in this state, but take a special project manager. I have met a project manager that recovered what appeared to be a hopeless project. Possibly the most irritating chap I’ve met, but at the same time was interested in one thing - delivery of the project in the shortest possible time. He wasn’t afraid to tell the customer it would be a week late, and he delivered it when he said it would be delivered. Pure genius.

I’m sure there are more. If you have any observations on planning failure, I would like to hear them, so drop me a line at nigel(at)code-whisperer.com.

Outsourcing any part of a project to a third party is a risk, but one that can be minimised. By careful planning and management. for example having good quality technical design documents and continual communication with the third party, it’s possible to benefit from the use of a third party software, whether bespoke or readily available software.

Outsourcing allows projects to have more personnel working on it than the company has. Outsourcing is sometimes used as a way of reducing the cost of a project, although, for a variety of reasons some of which are outlined below, the lower cost of development staff doesn’t always result in a lower overall cost. Generally outsourcing is carried out away from your office, so you need to plan for more time spent communicating that you would if the development team were in your office, simply because you will probably have one point of contact and your request for information may require a return call.

Personally I think it’s vital that outsourcing isn’t used as a scapegoat for a high risk project. I have seen this happen or more than one occasion and whilst a large consultancy firm was brought in that could absorb any financial penalties, the consultancy’s staff were under immense stress to deliver the undeliverable.

Managing third party development isn’t an area I’ve had a great deal of experience of, so I’ve dug out a few tips from various books as well as my own.

• Top quality design documents are key. The documents need to be well written, detailed and correct. Peer review all documents sent out and make sure the outsourcing company understand the work required sufficiently to estimate and plan the work. One major point of failure is the outsourcing company not appreciating the complexity of the work required. This can be the fault of either party. This is of particular importance if the work is carried out away from your office as the ability to communicate face to face over small items is greatly reduced. If you are receiving the source code and planning to maintain it yourself then you must supply your coding standards and consider performing a code review on the delivered code.
• Constant communication. Make sure you are aware of real progress against your plan, not just the time taken, and have clarification that the stated progress is correct.
• Risk assessment. You will need to include the outsourcing in your risk assessment, and possibly have a backup plan
• Frequent code drops. By having points in the development where code can be delivered and tested, you will have a measurable sense of progress, or slippage. Sometimes the code drop is combined with payment to the third party an incentive for working code to be delivered on the agreed dates.

I don’t want to give the impression that outsourcing is a bad thing, it’s not, provided it’s approached sensibly and managed correctly. Having said that a number of high profile public projects, for example the NHS patient record system, have been delayed due to contractual issues with the third party developers. The same issues that cause delays and problems with an internal project seem to be magnified when a third party is involved.

This topic pulls together several other of the 36 common mistakes, for example feature creep and the use of leading edge technology. Many books have been written on risk management and I’m not going to attempt to distill them down to one blog posting, instead some definitions and key points.

A risk is an undesired event that has a cause and a consequence. Risk management is the systematic process of identifying risk, analysing and either responding to it or planning to minimise or avoid it.

I heard of some astonishing, but quite logical, risk management at a meeting at IBM many years ago. They had a project on a client’s site that involved the teams driving a fair distance each week for a number of months. The project manager calculated the number of miles that would be driven and then looked up the average number of miles between serious road accidents. Statistically for the number of miles to be driven there would be one serious road accident. Fortunately all journeys were completed without incident, but there was a fallback process in place had there been. Whilst this may appear cold hearted, it doesn’t exclude caring for the team members involved in the accident, in fact quite the reverse. Just as we rely on the police, ambulance and fire services in a road accident, who have plan and train constantly for this sort of activity, so IBM was creating a process that would allow the project to carry on whilst caring for the team members. If an accident had have happened unplanned for, the project manager would have had to work out what to do on the spot and implement it. By having a plan someone else can put into practise, the project manager is free to concern himself with the well being of his team members.

There’s as many ways of handling risk management as cooking eggs, so I’m just going to touch on the general steps.

Risk identification - prepare a list as part of project planning, but also identify risks during the project.

Qualiative risk analysis - this is a prioritised list of risks, ranked by the cost of correcting the risk, which could be expressed in time or money.

Quantitative risk analysis - this is the likelihood of the project not achieving its objectives if the risk occurs or the probability that the risk will occur. The expected cost can be calculated by multiplying the expected cost from the qualitative analysis with the probability of the risk occurring.

Risk response planning - look at the ways the risk can be minimised or how it will be handled and cost, using the same units as before (i.e. time or money). Minimisation of risk can consist of work you will need to do to minimise the risk and work you will need to do if the risk occurs. The cost of dealing with the risk (if it occurs) and the cost of minimising the risk can be compared and a decision made on more scientific grounds. For example, if a project was using a new database technology, you can calculate the cost of changing the database technology late in the project if a problem was found in the new technology and compare it against isolating the new technology as part of the design and having to change a smaller amount if a problem arises.

Risk monitoring and control - as the project progresses the possibility of a risk occurring may rise or fall and other risks may be identified. Just as the project plan is adjusted as it progresses, the risk management steps here should also be constantly revised and adjusted.