As you identify, the problem child is quality. Not just achieving quality, but getting an agreement of what constitutes quality. Even getting an honest answer from individuals about what they see as requirements to achieve quality is impossible, because people will say what they think is expected, regardless of whether they personally have found it useful, simply because no one wants to be seen as the cowboy.

Put 10 SEs in a room and tell them not to come out until they have agreed upon a definition of software quality, and you have a pretty good definition of that old engineering tool, a long weight. Unless of course it's Friday afternoon, in which case they'll be done by 4.30.

You do not achieve quality through process

All you achieve is process procedures compliance. And the diversion of energies away from producing the code. The arguments will be about the process; and how to achieve the process; and how to measure compliance to the process; and the generation, dissemination and interpretation of reports detailing that compliance. Or not.

And training courses detailing the process and it's procedures. And regular meetings to review the procedures and the state of compliance. And a department charged with measuring that compliance and producing graphs to show it.

How do you achieve quality?

Yes. That's a question and I do not pretend to have the answer. For a start, there are as many answers as there are projects. And what constitutes quality for a given project depends upon many, many things: lifetime, risk, cost-benefits, audience, the price the market will bear, etc.

But even if you had hard and detailed numbers defining all those things, (were that possible), there is still another factor. What is the required quality. Customers, be they internal or external, professional or public, do not expect the same levels of quality for everything.

We do not expect the same levels of fit'n'finish of the interior trim in a commercial vehicle as we do a private car. Or of a £7k micro-mini, as in a £40k luxury saloon. However, the brakes had better damn well work regardless of the cost of the vehicle. And it's probably best if the bonnet doesn't fly open when you're on the motorway.

In software terms that might mean that your home page is graphics heavy and carries information about special offers. But once the customer starts filling in forms to make their purchase, they're probably not interested in seeing fancy graphics and those same special offers on every darn page. The important thing here is to ensure that when they make a mistake on the forms, and they will, that they can back up to correct them and not get dumped back to the first form of 17 and loose all the input they already typed.

Processes tend to apply the same criteria to all projects and all parts of a project. And that's a recipe for generating the most procedurally compliant white elephant in history.

The first order of business is to make the software work. Now. Today. Tomorrow. Next week. But not 3 months or 6 months from now. Once the software "works", you can review it. Its functionality. The source code. The backup, maintenance and testing. You can highlight the weaknesses, prioritise them and fix them.

It doesn't matter how elegant, how well documented, structured, versioned, tested or reviewed your code is, until it works, your quality is 0, nil, zip, nada, non-existent.

So, make it work. First and fast. And then review it thoroughly from every aspect. Source code layout. External interfaces. Internal interfaces. Testing. Build processes. Effectiveness. Efficiency. In no particular order.

Then draw up a list of things that need to be improved. Put that list in order of importance. Work your way through that list as far as you can within the timescales available to you. Make sure that your program continues to work after each change. Back out the change and concentrate your resources on redoing that change, even at the expense of suspending other lower priority items on your list until you get it right.

None of this implies abandoning all good practices. You'd have a hard time pursuading experienced programmers to abandon those practices that they have personally seen benefit from over the years anyway. The experienced ones will follow their own set of best practices. They may not be the same set of best practices, but they will work; for them. Where conflicts arise between individual practices, in most cases they will be resolved without management or procedural intervention, but in the final instance a manager listens to the pro and cons of both sides and makes a decision. Less experienced programmers are mentored by the more experienced. They work to his standards until they've developed a set of their own that they can justify.

Make it work first. Everything else is just window dressing until it does.

Processes and procedures can be helpful, and cost effective, in getting projects to work. And in established, successful shops/teams, the established processes and procedures, born of evolution and necessity, are the oil upon which the work flows. But if the process becomes king, and it all too frequently does, especially imposed or adopted, theoretically wonderful processes, then abandon hope all ye who enter there. Because once the arguments become about whether the process is being followed rather than about whether the goals are being achieved, you might as well pack your bags and go home.