Where does the Craftsman's responsibility start/end?
Paul Pagel
talked about the Challenger disaster and he blamed the engineers who
knew the risks and didn't do whatever it took to keep the takeoff from
happening. The more general deduction being that we as craftsmen and
professionals are responsible for the code we write and the success of
our projects.
How involved must we be in the business to gaurentee (in some cases
just to understand) what it means to be a successful project?
Following the Challenger example, are we only responsible for the
failure of a project. The failure of the Challenger was the failure
of the engineers, because they knew the o-rings would not hold (or at
least the risk was beyond an acceptable level).
Sometimes I get a feature the customer wants and think, "There is no
way this is useful to the user. In fact, this is a waste of my time
and their money." Or even worse, "This feature will be destructive to
the usability/functioning of the rest of the system without adding
value." I will raise an objection, but continue down the path of
cognitive dissonance if they persist. It is not my job to tell them
how to spend their money; or is it? When they hire a team of
craftsman, where does this line of accountability start for the
software craftsman?
Robert Martin
dennyabraham
that, like the Morton Thiokol engineers, a craftsman can create a
product that meets requirements and falls well within tolerances.
But, a craftsman cannot control the use of their work. Do we have an
obligation to add functionality for customers that can be optimal
locally, while degrading the quality of the overall workmanship we
provide?
What do the professional ethics of software craftsmanship demand we
do?
On Nov 11, 3:32 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> I think that line of accountability starts where are expertise
> begins. We may not be experts at what features are important to
> customers. We are, however, experts in what kind of code is best able
> to deliver what the business says it needs. I have no desire to
> second-guess the experts in marketing and sales who need certain
> features. By the same token, I don't want them second-guessing my
> estimates or issues of code and design quality.
>
> ----
Dave Hoover
> How involved must we be in the business to gaurentee (in some cases
> just to understand) what it means to be a successful project?
I'd say, "as involved as possible". I think too many of us distance
ourselves from our customers' businesses. It easier to focus on
purely technical topics than focus on the messy realities of business.
In my experience it takes time to get involved in the the business,
so the beginning of your relationship with your customer might have a
very sharp distinction between your knowledge and hers. But over
months, years, and successive deliveries, you should be growing your
domain and business knowledge, just as a smart customer will grow her
technical skills through interacting with you.
Dave Hoover
//obtiva: Agility applied. Software delivered.
Bent
lost. Noboby's going to die if I implement a crappy user interface.
I would argue that a craftman should be expected to understand the
whole problem, and deliver what the customer really needs (not
necessarily what they asked for). But it's important to bring the
customer along in the discovery process. Sometimes, implementing it
the way someone asks for it can be the best way to get them to change
thier mind. If you politely and clearly raise concerns about a
feature, only to be told to do it anyway, I think all you can do is to
build it so that the discussion can move out of the abstract. Once you
have an implementation to complain about, you can start talking about
the issues more objectively and concretely.
On the flip side of this issue, I've been in a number of situations
where I thought a feature was useless, implemented it anyway, and
discovered that the users really liked it. The discussion of why they
liked it almost always leads to more valuable features. These
situations almost always increase my understaning of the domain and
what challenges the users really face.
In either case, if there isn't consensus about a feature in the first
1/2 hour or so of discussion, there probably won't be. Implementing it
is sometimes the only way to move forward.
Robert Martin
I don't think the Challenger is a fair comparison here. Lives were
lost. Noboby's going to die if I implement a crappy user interface.