Here are some points which I believe are so fundamental to software development as to be almost self-evident. However, because they are not founded in the belief that a system alone can guarantee quality, they are often ignored by large corporate departments who choose to focus instead on bureaucratic procedures and superfluous paperwork which provide little more than false confidence.
The points set out below may seem overly simplistic, but there is therefore all the more reason not to lose sight of them.
Development methods should recognise the following difficulties:
- It is not easy to find high-quality developers.
- It is not easy to integrate developers into unfamiliar practices, particularly when it does not represent a long term investment for the developer.
- It is not easy to measure other developers' progress on a project. And only experienced developers can give accurate estimates of time required on their own projects.
- It is not easy for a customer/requester to explain what he needs, and it is not easy for a developer to understand.
- It is not easy for many developers to work together on a single project.
Use Mentoring (Helps with 1, and 3).
Mentoring continually improves the skills of developers. It also involves someone who can give an accurate time-to-completion estimate, and who can watch out for potential problems.
There is a tendency to promote the most technically-skilled developers into non-development management roles. Therefore project managers should attempt to spend some of their time directly involved in a project as mentors. This will help to pass on their skills and will give them the information they need to manage the project.
Use Mainstream Tools, and Techniques (Helps with 1, 2, 3, and 5).
The use of mainstream tools means it is easier to find staff. Adopting simple development methodologies from the mainstream means new developers can be brought on board faster. Using methodologies associated with the chosen tools will increase the chances that developers are already familiar with them.
Specifically, using mainstream Object-Orientated techniques will help to break a project down into measurable parts, and will make it easier to integrate the work of several developers.
Create Reusable components (Helps with 3).
When planning a project, we should always attempt to find reusable elements within that project. Future projects will be completed in less time, with less bugs, if some parts of the project already exist. This helps with 3.
Because we can never know what will be needed in future, we should be careful here. A safe rule is that, if making parts reusable increases the development time of a whole project by more than 50%, then you should decide either decide not to bother with the reusability, or to create a new project for that purpose. Different departments may, of course, use a different percentage, but they should agree on some limit.
Use Feature Lists (Helps with 3 and 4).
Before a project is begun, there should be a Feature List. This is a list of requirements for the project/system. It should be based upon the discussions with the customer/requester. It should be approved by the customer/requester. It may, of course, change during the course of development. It will probably change most after the first prototype is shown.
As each feature is completed it can be checked-off. This serves as a basis for both the developers and their managers to measure a project's progress. It also eliminates the inevitable disagreements at the end of the project about what exactly was promised at the start of the project.
Managers may decide to mark each feature with a percentage, but in practice this will rarely be accurate. When these percentages are summarised into a single percentage, or time-remaining, for the whole project, the number will look very accurate but will be mostly without meaning.
Develop Incrementally (Helps with 3 and 4).
It is impossible to get everything right the first time. All projects will have at least a second phase, or they will be abandoned. If this fact is not acknowledged then all estimates of time to completion will be inaccurate and all expectations of customer/requester satisfaction will be without foundation.
It is OK to give a rough estimate of the the time required for all projects, but we must recognise that time is required between phases for user feedback, and that the estimates of later phases are likely to be less accurate.
Recognise that Customers/Requesters are the best testers (Helps with 3 and 4)
If you have the staff then it is, of course, helpful to do in-house testing. Of course, at least some testing should be done in-house during the course of the project. But it is unrealistic to assume that in-house staff will be able to offer as much information as the customer/requester. They will inevitably require changes so it is best to tell them that this is normal.
Constantly Share Code (Helps with 5).
By using a source code management system, problems with integrating the parts of a project can be dealt with when they happen. This also allows all developers to learn from each others' code and provides examples of the prescribed methods.
Documentation (Helps with 4 and 5)
Developers are notoriously bad at producing documentation for their code. When management does not demand and monitor documentation then it will rarely be produced voluntarily. However, attempts at dictating specific documentation methods are often useless because they simply reformat important parts of the code into different formats. This kind of information is rarely kept up-to-date, and can be better presented by using a source-browser tool, such as that in VC++.
It is of the most importance to demand clarity in the code itself, along with some broad explanations of the techniques involved.
A simple visualisation method such as the UML can be of great help in the design stages, but managers should be careful that, by enforcing it use throughout a project, they do not create an unproductive bottleneck in the development process. Managers should realise that it is a collection of tools, not a solution. Its purpose is to complement the development process where appropriate in order to aid internal communication.
The Mythical Man Month, Frederick P. Brooks Jr. - Very dated and points out the obvious, but is a widely read point of reference.
Dynamics Of Software Development, Jim McCarthy - A little new-age in places, but otherwise very pragmatic.
UML Distilled, Martin Fowler - Useful development techniques and abstractions.
Copyright © Murray Cumming. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
