Re: So let's build a router
From: Kurt (kurbylogic_at_hotmail.com)
Date: 09/24/04
- Next message: Programmer Dude: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- Previous message: Mark Nicholls: "Re: dip Notions 2 Major Errors"
- In reply to: Cristiano Sadun: "Re: So let's build a router"
- Next in thread: Phlip: "Re: So let's build a router"
- Reply: Phlip: "Re: So let's build a router"
- Reply: Cristiano Sadun: "Re: So let's build a router"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 24 Sep 2004 09:46:38 -0700
Cristiano Sadun <cristianoTAKEsadun@THIShotmailOUT.com> wrote in message news:<Xns956E61E222CC4Sadun@212.45.188.38>...
> Universe <universe@tAkEcovad.OuT.net> wrote in
> news:i6r5l01a1emgk27h8dsa77fpbehaqjb814@4ax.com:
>
> > But there are 2 issues here:
> > 1) Is SW Engineering technology so bad nothing can get built
> > most of the time?
>
> Depending on the sources, it appears it's so bad that nothing gets build
> from more or less sizable percentages of the time.
>
> Are you guys questioning that the "software crisis" exists?
I would agree a sizable percentage of projects are not completed, many
do not even start or are cancelled at the first sign of an unexpected
or potentially overwellming challenges. However, I would not go as
far to say that the 'failure' is due soley to the existing
methodologies and/or the teams using them. There are many factors at
play, I'm willing to say the failure of C3 may not have been entirely
within the control of the project team. This 'software crisis' you
see, could it be just that..., factors outside the control of the
project team? No matter what methodology used some projects will not
complete, and due to unforseeable cercumstances. However we can do
our best to make sure that every forseeable risk is identitied and
mitigated. This is why a risk mitigation plan: identifying potential
risks, impact, likelyness to occur, how to detect them, and what to do
when it happens is so important. Seems as if C3 failed because
"GoldOwner" and "GoldDonor" had different visions... This is *not*
uncommon! and yet we know who these people from the project start!
When the person with the checkbook and the person with the vision are
different there is a risk, they might not bring it to your attention
until problems start arising, however, once the risks have been shared
with the customer they'll be thinking about it as much as you and may
help you determine its threat and likelyness to occur, when goals and
requirements are defined if they don't agree we should know this as
soon as possible not 5 years later, chances are this could have been a
3 month project rather then a 5 year project. This project may have
been doomed to fail no matter who implemented it, but perhaps it would
have been more 'successful' if it 1) never started 2) ended sooner.
>
> > 2) How did a project play in the market, and so and related how
> > did analysis fit into marketing? That type of thing
>
> Yes, here you're right. We need a clear definition of project failure
> before going into the field and examining historical projects to find how
> many have indeed failed or not.
>
> A possibility with which I've played is to avoid a boolean definition of
> success/failure - but rather use a discrete or continue function.. for
> example, something like
>
> Success(p) = 1 - overbudget(p)*delayed(p)*missingfunctionality(p)
> *userAppreciation(p)
Value(p) = ....
>
> etc.., where all these indicators are real or rational values x, 0<x<=1.
>
> By selecting a set of indicators and assigning them certain shapes, we
> could model different concepts of success/failure which put emphasis on
> the speficics we're interested in.
>
> > XP has failed to show on #1 so far.
>
> #1 cannot be shown by any methodology. A methodology is supposed to be a
> solution; #1 is a problem. The existence of the problem is simply shown
> by definining success/failure appropriately and then go into the field
> and check out the number of projects that have failed according to that
> definition.
>
> In literature, percentages vary (if I recall well) from 40% to 70% in
> different periods and contexts.
- Next message: Programmer Dude: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- Previous message: Mark Nicholls: "Re: dip Notions 2 Major Errors"
- In reply to: Cristiano Sadun: "Re: So let's build a router"
- Next in thread: Phlip: "Re: So let's build a router"
- Reply: Phlip: "Re: So let's build a router"
- Reply: Cristiano Sadun: "Re: So let's build a router"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
