Prev: SQL Server Performance Local vs Remote.
Next: Trying to get a % of responses from a survey in a query
From: --CELKO-- on 8 May 2010 14:46
>> You know the funny thing is that almost every IT project costs double what is originally quoted. I've had many clients who exclaim to me later that they wish they had held me to my quote. To which I immediately reply: in that case they would only have received what they asked for in their spec. <<

It is worse than that. Ever read Yourdon, Boehm, DeMarco, et al about
large software projects? DeMarco's research is that
15% deliver nothing at all (cancellations, total failures), another
percentage deliver nothing useful (obsolete on arrival, not up to
specs, etc.) and a third percentage deliver only part of the specs.
The success rate has been pretty low. I think it was Yourdon that said
if we made manufactured goods the way that we make software, Henry
Ford would have been bankrupt in two months.

>> The reality is that we don't get specs. Certainly not detailed ones. And when I have had to complete a genuine RFT or formal quotation, I would say that initial spec would never cover more than 30% of what is eventually built. <<

That depends on your clients. In Defense contracting, nothing happens
until you have a spec (MIL STD 2167 and its descendants); major
companies that cannot have failures or "tuning time" also follow this
regiment. This is a world in which we cannot say things like "there
are no specs for this nuclear weapon control system, so you cowboy
coders write stuff and we'll make it up as we go along."

>> We now have an attitude of continual delivery and continual billing. <<

LOL!

http://www.despair.com/consulting.html

That seems to turn into continual re-coding and continual billing.
Boehm's research at TRW showed that an error made in step(n) of the
waterfall model cost almost exactly 10x to correct in step(n+1).
Specification errors were the earliest and therefore the most
expensive to correct. In fact, they were a major factor in total
failures. Perhaps the most extreme example was a failed reservation
system for Greyhound Bus Lines. People that ride buses pay cash at the
gate; they do not make reservations.

>> We agree on small milestones which they are happy to pay on. Each milestone statement is accompanied with some kind of forward estimate of work remaining but we find that the customer 'customizes' the work so much along the way that putting too much effort into a detailed spec is just pure wasteful. It is often fantasy. <<

When I was paid for milestones, they were well-defined (so that many
teams could work in parallel), had QA tests ready to go (created by
another group) and had to meet certain SEI standards. The QA suites
were written from the specs without seeing any code.

We had a structure chart for the whole system on the wall whose boxes
showed the status of each module (uncoded, testing, approved or a
traffic light). We had stub programs for the uncoded modules, so
testing was possible.

To get away from decades of classic research, let me do my anecdotal
evidence against yours. When I was part of a team that did the Georgia
State Crime Lab Database and we followed a disciplined approach, we
delivered a system under budget (a first for LEAA money at the time),
4 months ahead of schedule and a system robust enough to be changed by
the junior programmer on the project when we left.

This made a lot of problems in a bureaucracy :) They had no way to
take back money and no idea what to do with the extra man-hours.


From: Tony Rogerson on 8 May 2010 16:10
Frankly you are very industry old and in those terms stuck in the past and
because folk don't employ you that often you are very out of touch and don't
realise the industry has moved on considerably since the last time you did a
full stretch of project work, what is it now - some 15 years ago - perhaps
more?

--ROGGIE--



"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:a6d97135-9e10-4a1c-aa30-ea7cb1a2fc80(a)r34g2000yqj.googlegroups.com...
>>> You know the funny thing is that almost every IT project costs double
>>> what is originally quoted. I've had many clients who exclaim to me later
>>> that they wish they had held me to my quote. To which I immediately
>>> reply: in that case they would only have received what they asked for in
>>> their spec. <<
>
> It is worse than that. Ever read Yourdon, Boehm, DeMarco, et al about
> large software projects? DeMarco's research is that
> 15% deliver nothing at all (cancellations, total failures), another
> percentage deliver nothing useful (obsolete on arrival, not up to
> specs, etc.) and a third percentage deliver only part of the specs.
> The success rate has been pretty low. I think it was Yourdon that said
> if we made manufactured goods the way that we make software, Henry
> Ford would have been bankrupt in two months.
>
>>> The reality is that we don't get specs. Certainly not detailed ones. And
>>> when I have had to complete a genuine RFT or formal quotation, I would
>>> say that initial spec would never cover more than 30% of what is
>>> eventually built. <<
>
> That depends on your clients. In Defense contracting, nothing happens
> until you have a spec (MIL STD 2167 and its descendants); major
> companies that cannot have failures or "tuning time" also follow this
> regiment. This is a world in which we cannot say things like "there
> are no specs for this nuclear weapon control system, so you cowboy
> coders write stuff and we'll make it up as we go along."
>
>>> We now have an attitude of continual delivery and continual billing. <<
>
> LOL!
>
> http://www.despair.com/consulting.html
>
> That seems to turn into continual re-coding and continual billing.
> Boehm's research at TRW showed that an error made in step(n) of the
> waterfall model cost almost exactly 10x to correct in step(n+1).
> Specification errors were the earliest and therefore the most
> expensive to correct. In fact, they were a major factor in total
> failures. Perhaps the most extreme example was a failed reservation
> system for Greyhound Bus Lines. People that ride buses pay cash at the
> gate; they do not make reservations.
>
>>> We agree on small milestones which they are happy to pay on. Each
>>> milestone statement is accompanied with some kind of forward estimate of
>>> work remaining but we find that the customer 'customizes' the work so
>>> much along the way that putting too much effort into a detailed spec is
>>> just pure wasteful. It is often fantasy. <<
>
> When I was paid for milestones, they were well-defined (so that many
> teams could work in parallel), had QA tests ready to go (created by
> another group) and had to meet certain SEI standards. The QA suites
> were written from the specs without seeing any code.
>
> We had a structure chart for the whole system on the wall whose boxes
> showed the status of each module (uncoded, testing, approved or a
> traffic light). We had stub programs for the uncoded modules, so
> testing was possible.
>
> To get away from decades of classic research, let me do my anecdotal
> evidence against yours. When I was part of a team that did the Georgia
> State Crime Lab Database and we followed a disciplined approach, we
> delivered a system under budget (a first for LEAA money at the time),
> 4 months ahead of schedule and a system robust enough to be changed by
> the junior programmer on the project when we left.
>
> This made a lot of problems in a bureaucracy :) They had no way to
> take back money and no idea what to do with the extra man-hours.
>
>
From: Geoff Schaller on 8 May 2010 21:31
Joe,

> It is worse than that. Ever read Yourdon, Boehm, DeMarco, et al about
> large software projects? DeMarco's research is that

No - which is probably the difference between the two of us. I
experience these things first hand and don't need to read a book to
confirm my experiences. Perhaps others wanting to get in to large firm
contracting might get a picture from DeMarco but then again, you do
these things because you want or it is a foot in the door. And if you're
big enough to make the play, you already know the stakes...

> That depends on your clients. In Defense contracting, nothing happens
> until you have a spec (MIL STD 2167 and its descendants); major

Oh I agree. The ONLY detailed specs and legal contracts we've had to
comply with in detail came from government related work and in all
cases, they should have saved the money.

> >> We now have an attitude of continual delivery and continual billing. <<
> LOL!
> http://www.despair.com/consulting.html

But you don't need to read books to know that it is all about delivery
of expectations you built with the client. We have found it better to
agree on broad principles, set milestones and then achieve them. Get
continual feedback and adjust. When they request items or changes that
add to the new project cost you declare them immediately, seek approval
and adjust the forward estimates. Often it is just a case of reshaping
the contract and its expectations. With government contracts we get them
to agree to billing points that match deliverables and then we "allow"
some 15% to be withheld so that they can guarantee themselves feature
completion.

> That seems to turn into continual re-coding and continual billing.

This is not necessarily bad and where Boehm and DeMarco fall down in
their approach is that they fail to consider a genuine dynamic model for
delivery. How many projects have seen the underlying technology change
dramatically in the life of the project... or company aims change.
Anything to be delivered over 2-3 years is going to suffer that fate. It
must be factored in or all parties are going to suffer.

> When I was paid for milestones, they were well-defined (so that many
> teams could work in parallel), had QA tests ready to go (created by
> another group) and had to meet certain SEI standards. The QA suites
> were written from the specs without seeing any code.

Then we aren't disagreeing.

> To get away from decades of classic research, let me do my anecdotal

....oh puh-lease! Thank you :)

> evidence against yours. When I was part of a team that did the Georgia
> State Crime Lab Database and we followed a disciplined approach, we

But this kind of project is rare. More often than not there is
intervention on the part of the client that rates only as interference
and other times where the contractor misunderstood a requirement and
delivered it incorrectly. There need to be mechanisms to prevent both.

> This made a lot of problems in a bureaucracy :) They had no way to
> take back money and no idea what to do with the extra man-hours.

Never had that problem. There are always ways to spend the unspent....
Especially in government.


Geoff Schaller
Software Objectives

From: Geoff Schaller on 8 May 2010 21:33
I laughed so hard when I saw it that I forgot to comment.

In any event, "old fart" is more a term of endearment than an insult.
You know... that grand pa figure in baggy pants and slippers.



"TheSQLGuru" <kgboles(a)earthlink.net> wrote in message
news:tamdnUhIsJTg7XjWnZ2dnUVZ_i2dnZ2d(a)earthlink.com:

> > True, but at least I am not rude :)
>
>
> That is a stunningly brash and false statement!!!
>
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>

From: --CELKO-- on 9 May 2010 16:30
>> where Boehm and DeMarco fall down in their approach is that they fail to consider a genuine dynamic model for delivery. <<

Boehm is the guy that invented the spiral development model. RAD, JAD
and its Agile/Extreme descendants all go back to his work at TRW

>> Never had that problem. There are always ways to spend the unspent.... Especially in government. <<

That was the only time I did, too :)

LEAA (Law Enforcement Assistance Act) had no way to return the money.
There was no account code for it. So we tried to buy expendable
supplies -- not legal (that had to be State funds, not Federal). We
tried to take a trip -- not legal (contract had final signatures). We
tried to buy more hardware, but the HP-3000 was the largest model at
the time and was in a closet so cramped it was physically impossible
to add anything else. For about a year, I kept getting calls from the
Feds trying to get me to spend the extra money in some creative way.
We had messed up the system!

The rule of thumb in the Cold War continuing contracts was to spend
105% to 110% of the year (n) budget, so you could get an increase in
year (n+1). Just over enough to make it look like you were doing
honest estimates, had project control, etc. and needed a little extra
for the next step. Of course, a true estimate would be under as often
as it is over the mark. But management also know this game and did
things to control for it.

When I worked for Georgia Tech, I wrote a spreadsheet to back-figure
the billings we sent to the US Army each month. a year or two later, I
went to work for the US Army on the other side of the campus. I was
now a Contract Officer on the other side of the desk and got to reject
my own spreadsheet figures.

The Cold War was strange times.
First  |  Prev  | 
Pages: 1 2 3 4
Prev: SQL Server Performance Local vs Remote.
Next: Trying to get a % of responses from a survey in a query