This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Retreaded: FaultyTechniqueDichotomy
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
My main inspiration in life is trying to capture and improve the
way in which we do software development. So I spend a lot of time
talking to people about various techniques they've used, which ones
work well and which ones suck.
As I do this, I often hear about faulty techniques: "FIT wasn't
worth the effort", "never put any logic in stored procedures", "test
driven design led to a chaotic mess". The problem with any report of a
faulty technique is to figure out if the technique itself is faulty,
or whether the application of the technique was faulty.
Let's take a couple of examples. Several friends of mine
commented how stored procedures were a disaster because they weren't
kept in version control (instead they had names like GetCust01,
GetCust02, GetCust02B etc). That's not a problem with stored
procedures, that's a problem with people not using them properly.
Similar a criticism that TDD led to a brittle design on further
questioning led to the discovery that the team in question hadn't done
any refactoring - and refactoring is a critical step in TDD.
Of course if you take all this too far, you get the opposite
effect. I often say "no methodology has ever failed". My reason for
this is that given any failure (assuming you can know
WhatIsFailure) you can find some variation from the
methodology. Hence the methodology wasn't followed and therefore
didn't fail. This issue is compounded even further with self-adaptive
agile methods.
So when you hear of techniques failing, you need to ask a lot
more questions.
Was it the technique itself that had problems, or was some
other thing being missed out. Does the technique have an influence on
this? (Version control is a separate thing to stored procedures, but
it can be harder to use version control with stored procedures due to
nature of tools involved.)
Was the technique used in a context that wasn't suitable for
it? (Don't use wide-scale manual refactoring when you don't have
tests.) Remember that software development is a very human activity,
often techniques aren't suitable for a context because of culture and
personality.
Were important pieces missed out of the technique?
Were people focused on outward signs that didn't correspond to
the reality? This kind of thing is what Steve McConnell called Cargo Cult
Software Engineering..
An interesting aspect of this is whether certain techniques are
fragile; that is they are hard to apply correctly and thus more prone
to a faulty application. If it's hard to use a technique properly,
that's a reasonable limitation on the technique, reducing the context
when it can be used.
There's no simple answer to this problem, since with these
techniques we are as unable to measure compliance as we are unable to
measure their successfulness. The important thing to do is whenever
you hear of a technique failing - always remember the dichotomy.
Previous Topic
