Datareign

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.

Establishing Coding Goals

No coding should be undertaken in the absence of clear requirements for the product. These requirements should state…

  1. who wants it
  2. why they want it
  3. what they want
  4. when they want it

The order in which these goals are established is deliberate.

Who Wants It

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.

Why They Want It

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.

What They Want

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.

When They Want It

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! ;-)

Basic Standards

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:

  • Code must be fully documented.
  • Code must be properly segmented.
  • Code must use informative variable names.
  • Programmers must maintain a proper change history.

These and other standards are discussed in the sections Documentation and Code Segmentation.

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.

Preventing Bad Code

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.

Forbidden Things

The following is a list of things that coders should not do, while accepting that, sometimes, rules may be broken for good reasons…

  • Use the same variable name inside a sub-segment as is used outside of it.
  • Reuse the same variable name for two different purposes, even if in separate segments.
  • Change pointer variables into other types, while retaining the same name, for any reason.
  • Use floating point numbers in loop control statements.
  • Hide processing inside loop control statements.
  • Use multiple pointers to one object.
  • Fail to end a test with a default value or operation.
Last modified: 2014/07/09 18:05