Today we have a guest editorial as Steve is out of the office and traveling.

The thing with agile is that it is often abused. Agile is a set of principles to encourage rapid, uninhibited progress with the ability to readily change direction in order to meet actual needs when they differ from perceived requirements. In reality it is often executed as an excuse for shortcuts. No documentation. Lack of control. And poor quality. Whilst not unique to the agile movement, I believe that quality is an enabler for productivity. I believe that without a reasonable level of quality you cannot be as productive.

What do I mean by quality? In this instance I mean designs peer reviewed, coding standards followed, automated unit tests, code peer reviewed, automated performance tests, tested scripted deployments and documentation. Which of these or even how much of any of these is down to the specific of the project.

I am probably saying this to an audience that, if you believe the cliches, is most likely to agree. DBAs like the safe bet. In direct opposition to the mantra of "if its going to be late it might as well never turn up", many lean more towards "late is better than not getting there". Although I am not a DBA but a pesky developer, I tend to lean towards the latter. Quality improves productivity.