[
Lists Home |
Date Index |
Thread Index
]
On Sun, 2004-04-04 at 01:45, Rick Marshall wrote:
<snip>
>
> the other lesson remains that standards that codify practice are much
> more useful than standards that try to drive practice. simply because
> codifying practice is codifying what works. the rest is really just
> polemics.....
> <snip>>
Except when codifying practise is codifying what does not work. When you
have a complex process it is very easy to draw the wrong conclusions
about what works and what does not. As a result, it is very easy to
codify things that doesn't work.
My company, and several others, work with a project management
methodology called PPS. PPS is, according to its proponents, a
collection of management practises that are proven to work in practise.
The PPS proponents I have met are also very quick to point out that
there is no theorethical foundation in PPS, it is all a collection of
best practises. They also maintain that PPS can be used for any kind of
project, whether it is software development, building a bridge, or
creating a new standard.
One problem with PPS is that it has been put together by project
administrators with no engineering experience, and no programming
experience. All the practises are administrative. As a result, the
response to almost any problem is to produce another document.
When we had a problem with long response times from software testers,
and poor quality testing, the PPS response was that for every bug
report, a requirement specification and a function specification must be
written. This extra administration would have stopped the project dead
in its tracks. Fortunately the scheme was never implemented, because a
lower level manager threatened to quit if it was. (What we who worked in
the project wanted was test driven development and automated testing.
However, both our own and our customers management killed that one off
very quickly. As you might have guessed, the customer also uses PPS.)
Adding more documents, duplicating specifications that had already been
written, and adding absolutely nothing beyond the information in the bug
report, may seem an insane way to try to speed the process up. However,
at some point, an administrative project manager has noted that projects
with specifications do better than projects without, so the artifact of
solving problems by adding more specifications was codified into PPS.
Since PPS is based entirely on observation of projects, and lacks a
theoretical framework, there are a lot of "cargo cult" practises. Some
of the practises have little relation to what makes a project
successfull. Other practises work, but are misapplied or out of date.
However, the fact that PPS does not work, and can be shown not to work
(there is a university study of PPS) does not stop it from being used.
It is also very popular, at least among management. The people who do
the actual work tend to have a different opinion...
There are many other examples of how things that do not work have been
practised, codified, and used: astrology, magic, Software Engineering,
<Insert your least favourite XML recommendation>, tarot cards, the water
test (for identifying witches)...
Personally I believe that there should be two components to standards
and recommendations: they must have a theoretical framework, and the
theory must have been tested in practise and proven sound. (I am very
much in favour of XML recommendations being accompanied by reference
implementations whenever possible. If the people who put the
recommendation together can't implement it, then who can? If it is too
expensive and time consuming for them to do it, then maybe the
recommendation is too complex, or simply not useful enough.)
/Henrik
|
