Re: Dilbert debunks Agile detractors
- From: "A.G.McDowell" <mcdowella@xxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 22 Mar 2008 21:47:15 +0000
In article <9a25a138-0f80-4c9c-aeaf-2ec7be14e36f@xxxxxxxxxxxxxxxxxxxxxxx
..com>, Enterprise Architect <architectenterprise@xxxxxxxxxxx> writes
On Mar 22, 11:23 am, Phlip <phlip2...@xxxxxxxxx> wrote:
Enterprise Architect wrote:
I suppose it all depends on what "measure" represents to you in the
context of software development.
A metaphor is a leaky bucket that can only carry water so far.
There are plenty of things worth measuring and cutting in software
development, and plenty of things that are not. The expression
"measure twice cut once" is often used by people who think that
designs should be planned before cutting code.
Even if software's malleability
makes it easy to change compared to computing hardware, bridges or
buildings, a quality product requires not just continuous refinement.
It also requires a well thought out initial conception. There is a
place (and a need) for both.
I'm not smart enough to always think out a good initial conception.
--
Phlip
Not everyone is capable of doing so, that's true. There are on the
other hand some people who are very good at it, and I've had the
privilege of working with many such people.
At the end of the day, if you've found an approach that delivers good
results and that works for you on a personal level, stick with it. No
one way is best in all environments, teams and situations.
Situation means an awful lot. I have worked with very good customers,
who put in the requirements an explicit mechanism for change and a
quantitative limit on that change. I have worked with customers who
hired somebody else to write the requirements, so neither the customer
nor the developer really understood them. I have worked with customers
who reused requirements from previous projects that didn't make sense in
the new situation. The customer I was most impressed with I actually
worked for. They understood and improved everything except the lowest
possible level of detail. Unfortunately that turned out to be one of the
major problems.
--
A.G.McDowell
.
- References:
- Dilbert debunks Agile detractors
- From: Phlip
- Re: Dilbert debunks Agile detractors
- From: Enterprise Architect
- Re: Dilbert debunks Agile detractors
- From: Phlip
- Re: Dilbert debunks Agile detractors
- From: Enterprise Architect
- Dilbert debunks Agile detractors
- Prev by Date: Re: Dilbert debunks Agile detractors
- Next by Date: Re: Dilbert debunks Agile detractors
- Previous by thread: Re: Dilbert debunks Agile detractors
- Next by thread: Re: Dilbert debunks Agile detractors
- Index(es):
Relevant Pages
|