I will start by making an assertion that will annoy some people: the quality of much commercial coding is a disgrace.
Over more than thirty years, I have seen code, running critical services on production systems, which relies on the knowledge held by the original programmers for maintenance. When those individuals leave the organisation, the code becomes un-maintainable, often at a huge cost to the organisation. Worse still, these programmers, while still within the organisation, actively resist efforts to alleviate the problem. Although it is human nature to resist change, often in the belief that the change is a threat to job security, it represents a major hazard to the organisations using these applications.
What follows, then, is intended to prevent the situation arising and provide a plan to rectify the situation if it already present.
No coding should be undertaken in the absence of clear requirements for the product. These requirements should state…
The order in which these goals are established is deliberate.
There has to be a clear owner for the product. If the business allows several people to compete for the coders' attention the product will be, at best, a muddle. If there are competing business demands, which management cannot resolve, the best solution is to split the project into separate products and give each product its own coding team. Identifying the owner for each product is the most fundamental role of the project manager.
The coders need to understand the underlying reason for their work. Without that knowledge, they will not be able to develop the solution that the business requires. There is no need for a detailed understanding of the business, just a clear statement of why the product needs to perform in a particular way. The business analyst must provide this information and keep the coders up to date as the requirement changes, which it inevitably will.
Business people seldom understand the difficulties of creating software systems. Things that seem simple to them are often very difficult to achieve in reasonable timescales and the opposite is also true: they may shy away from stating a requirement because they think it beyond the abilities of the technology, when it is actually quite trivial to implement. The system designer must mediate this process and provide a realistic plan to the coders.
Delivery times are a balance of resources against demands. The more information that emerges from the previous three requirements, the more realistic can the schedules be made and the more chance there is of the project being delivered on time. This is seldom a problem for the coders, it being the main reason why project managers were invented!
These are the most basic requirements to which all source code must conform, if it is to be considered of production standard. Some basic rules that a project may lay down are:
Achieving this requires discipline and that discipline has to be enforced by the coding team's leader. It is all but impossible to establish and enforce standards that are introduced after a project has started. For this reason, a coding standards document must be part of the project's initial materials and coders must be made aware that adherence to those standards is mandatory.
It is worth considering that, if a coder is unwilling to adhere to the project's standards, their fitness for the project is immediately questionable. A successful software product is not just something that works on delivery, it is a product that continues to work reliably, long after the original coding team have moved on.
Management must accept the challenge of providing proper standards, which all code must meet and policing those standards. It was common, forty years ago, for managers to admit their ignorance of programming. It should not be acceptable in the 21st century for any manager, who is responsible for IT systems, to make such an admission.
That is not to say that managers are expected to be programmers or even IT professionals. They must, however, possess a clear understanding of what their organisation requires of critical systems and if necessary, call in outside help, to ensure that those requirements are being met.
The following is a list of things that coders should not do, while accepting that, sometimes, rules may be broken for good reasons…