[tlug] Quality under fire [was: No video playback in Iceweasel]

["Stephen J. Turnbull" <stephen@example.com>]

Benjamin Kowarsch writes:

 > Coding as part of the interview process is part of the problem, not
 > part of a solution.

I would say rather poor interviewers are the problem.

 > It favours practitioners who jump right into coding without any
 > requirements solicitation process, without any design, without any
 > implementation plan.

Only if the *interviewer* favors them.  Coding *is* part of the job.
It is also only *part* of the job.  "Code this" can be a trick
("jumping in" is an immediate unappealable "fail"), or somewhat more
refined (as in Josh's "I expect production-quality code").

 > Foregoing proper preparation is precisely the reason why software
 > is so bad these days, why projects go out of scope, over time and
 > over budget.

That's not what the SEI[1] says, at least not when "proper preparation"
is defined as

 > To produce quality, there has to be a proper requirements
 > solicitation process at the end of which there is a requirements
 > catalog categorised into must-haves, should-haves, could-haves and
 > most importantly will-not-haves. Then there has to be a proper
 > design process at the end of which there is a specification
 > document.  Finally, there has to be a risk management and planning
 > process at the end of which there is an implementation plan with a
 > mitigation strategy.
 > 
 > Only at that point should any coder be allowed to write the first
 > line of code.

Of course there are domains where such a formal process is a good idea
or perhaps the only idea leading to superlative quality.  But generally
the SEI only asks for "process" and "measurement", and the measurement
part is far more important than specific components of the process.


Footnotes: 
[1]  Watts Humphrey being the leading exponent: Managing the Software
Process, A Discipline for Software Engineering, The Personal Software
Process.  There are also technical reports from the SEI, the
Capability Maturity Management Process, etc, but they're much harder
to read (and oriented toward milspec suppliers and therefore waterfall
processes, at least the earlier ones are).