From: Anonymous on
In article <LsT8k.91002$6q2.28302(a)fe03.news.easynews.com>,
William M. Klein <wmklein(a)nospam.netcom.com> wrote:
>Unlike you, I don't care (too much) when it was outsourced.

My point was not to get an answer, Mr Klein... my point was to show that
neglecting to respond to questions was a behavior that's been demonstrated
previously.

(as for my interest... it'd be a curious bit of trivia to learn how long
the code's been running without being touched)

DD

From: Robert on
On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz>
wrote:

>"Robert" <no(a)e.mail> wrote in message
>news:r966641piavtlfe3ov1pgbg6oiqll6ojq3(a)4ax.com...
>> On Thu, 26 Jun 2008 13:19:20 +1200, "Pete Dashwood"
>> <dashwood(a)removethis.enternet.co.nz>
>> wrote:
>>
>>>If a corporation decides that the local market is "too expensive" and they
>>>can buy the service elsewhere, cheaper, that is their prerogative and,
>>>while
>>>we may not like it, we can't really blame them. But if the quality of that
>>>service is actually poorer, then why would we do anything other than offer
>>>to fix it, for a proper fee?
>>
>> It is semi-common, especially in the Big Five world, to staff a project
>> with mostly cheap
>> labor plus one or two hotshots, whose role is to rescue the drones when
>> they shoot
>> themselves in the feet, review their code, and solve problems requiring a
>> high level of
>> expertise.
>
>Yes, a certain primary coloured company was doing it in the 1960s. The
>people were referred to internally as "brains" and "bunnies"...

That terminology is not used in the US. Grunt, peon and body is used for unskilled
workers.

>The goal of
>a bunny was to become a brain, the goals of brains were multifarious and
>complex. They usually involved ego, recognition, and large amounts of money.

There are two kinds of brains. Egoists will never be anything but techies; non-egoists are
seen as management material. In some non-US contracting companies, all or most managers
are former brains (and not arab or american). Managers in American companies tend to be
politicians.

>A few brains who I knew personally were really into challenges and hated it
>when everything was going fine. These people thrived when the chips were
>down and seemed to develop new personalities overnight. It was an education
>to see them at work.

An education in management by crisis rather than planning ahead. In big companies,
emergencies are the only way to get money. When things are going smoothly, top management
gets rid of developers. There is no incentive to plan ahead.

> I invariably got on well with these people, one of them
>once remarking he was always glad to see me because I brought him problems
>that were interesting and worth doing... :-) (I'm not sure to this day
>whether that was good or bad...)

Good for him; bad for stockholders.

>> Contracting companies say more than 95% of the work is routine.
>
>So bunnies can do it. But when problems arise, a brain is needed. Now, if
>you don't employ a brain because it will cost too much, or you are an
>outsourcing company that doesn't want to train people (despite earning very
>large sums of money by the standards of the countries where they operate),

Management thinks all knowledge came through training. If you ask the brains, they'll say
they figured out the solution.

Management keeps wanting to routinize computers, like factory jobs. We know the problems
are unique, not repetative. You can't train to handle a problem that's never happened
before.

>then isn't it a much superior management stratagem to simply pressure the
>bunnies until they either solve the problem, crack up, or quit? (Given that
>bunnies are just cannoin fodder to unscrupulous employers and can be easily
>replaced...)

Lock them in a War Room. No one leaves until the problem is fixed, even if it takes all
night. Some companies have dozens of war rooms going day and night.

Waterfall was invented to prevent such frequent failures. It doesn't work in these
companies because of hidden coupling between systems. The systems work in isolation, but
don't play well together.

> So what are you going to do? You have a problem, have given it
>your best shot, and can't solve it. Seek help. Hey, there's a forum where
>you can get free advice... You post, get a solution and keep your job... But
>what you SHOULD do is admit that this problem requires expertise you don't
>have, and tell your employer it will cost to solve it. If all of the bunnies
>did this, and if the forum was more careful about free advice, eventually,
>employers would get the message...

No, they wouldn't get the message. They'll fire one bunny and hire another just as bad.
They're now making the same mistakes they made 30 years ago.

>(I hasten to add that if someone's job was actually on the line and I could
>help, I would not withold information. Survival trumps idealism every time.
>However, I would make it very clear what the course of action should be in
>future.)
>>
>> How would you feel about being one of the experts? In other words,
>> facilitating the
>> replacement of ~50 of your countrymen with cheap labor?
>
>Robert, I have worked as both a brain and a bunny. No jobs were lost or
>countrymen replaced in either case.

Twenty years ago, these projects were staffed with Americans making the equivalent of
$50/hr. Now they're staffed with third worlders making $30/hr, or people in their native
countries making $10/hr.

Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's still $80/hr.
Clients are getting less for the same money; contracting companies are getting rich.
From: Pete Dashwood on


"Robert" <no(a)e.mail> wrote in message
news:lta86493p3lh3st265vlni5vh72p0tas9a(a)4ax.com...
> On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood"
> <dashwood(a)removethis.enternet.co.nz>
> wrote:
>
>>"Robert" <no(a)e.mail> wrote in message
>>news:r966641piavtlfe3ov1pgbg6oiqll6ojq3(a)4ax.com...
>>> On Thu, 26 Jun 2008 13:19:20 +1200, "Pete Dashwood"
>>> <dashwood(a)removethis.enternet.co.nz>
>>> wrote:
>>>
>>>>If a corporation decides that the local market is "too expensive" and
>>>>they
>>>>can buy the service elsewhere, cheaper, that is their prerogative and,
>>>>while
>>>>we may not like it, we can't really blame them. But if the quality of
>>>>that
>>>>service is actually poorer, then why would we do anything other than
>>>>offer
>>>>to fix it, for a proper fee?
>>>
>>> It is semi-common, especially in the Big Five world, to staff a project
>>> with mostly cheap
>>> labor plus one or two hotshots, whose role is to rescue the drones when
>>> they shoot
>>> themselves in the feet, review their code, and solve problems requiring
>>> a
>>> high level of
>>> expertise.
>>
>>Yes, a certain primary coloured company was doing it in the 1960s. The
>>people were referred to internally as "brains" and "bunnies"...
>
> That terminology is not used in the US. Grunt, peon and body is used for
> unskilled
> workers.
>
>>The goal of
>>a bunny was to become a brain, the goals of brains were multifarious and
>>complex. They usually involved ego, recognition, and large amounts of
>>money.
>
> There are two kinds of brains. Egoists will never be anything but techies;
> non-egoists are
> seen as management material. In some non-US contracting companies, all or
> most managers
> are former brains (and not arab or american). Managers in American
> companies tend to be
> politicians.
>
>>A few brains who I knew personally were really into challenges and hated
>>it
>>when everything was going fine. These people thrived when the chips were
>>down and seemed to develop new personalities overnight. It was an
>>education
>>to see them at work.
>
> An education in management by crisis rather than planning ahead. In big
> companies,
> emergencies are the only way to get money. When things are going smoothly,
> top management
> gets rid of developers. There is no incentive to plan ahead.
>
>> I invariably got on well with these people, one of them
>>once remarking he was always glad to see me because I brought him problems
>>that were interesting and worth doing... :-) (I'm not sure to this day
>>whether that was good or bad...)
>
> Good for him; bad for stockholders.
>
>>> Contracting companies say more than 95% of the work is routine.
>>
>>So bunnies can do it. But when problems arise, a brain is needed. Now, if
>>you don't employ a brain because it will cost too much, or you are an
>>outsourcing company that doesn't want to train people (despite earning
>>very
>>large sums of money by the standards of the countries where they operate),
>
> Management thinks all knowledge came through training. If you ask the
> brains, they'll say
> they figured out the solution.
>
> Management keeps wanting to routinize computers, like factory jobs. We
> know the problems
> are unique, not repetative. You can't train to handle a problem that's
> never happened
> before.

Hmmm... I think we part company here :-) I believe there are general
approaches to problem solution that can be learned (empirically, by
experience, and, to a lesser extent perhaps, but still valuably, in the
classroom...), and I also believe that many of the problems encountered in
IT have been encountered before. I would agree that every company THINKS
their problems are unique... but that doesn't make it so.

It is arguaable, and I see you disagree. No problem.

>
>>then isn't it a much superior management stratagem to simply pressure the
>>bunnies until they either solve the problem, crack up, or quit? (Given
>>that
>>bunnies are just cannoin fodder to unscrupulous employers and can be
>>easily
>>replaced...)
>
> Lock them in a War Room. No one leaves until the problem is fixed, even if
> it takes all
> night. Some companies have dozens of war rooms going day and night.

If the skills and information required to solve the problem are not actually
available in the "War Room" then you can lock them in there until the next
Ice Age and it won't make any difference... Besides, I have yet to see the
Company that could contain me in a room where I didn't want to be...:-)

I have never seen this particular approach employed but I accept your
assurance that it is. It doesn't sound like a good way to motivate people...
>
> Waterfall was invented to prevent such frequent failures. It doesn't work
> in these
> companies because of hidden coupling between systems. The systems work in
> isolation, but
> don't play well together.

Waterfall doesn't work perfectly for a number of reasons. Didn't you say
earlier that Waterfall was invented to retard change? I think you later
amended that to be that Waterfall was invented, not to retard change or keep
control, but to avoid blame for errors? Now it is to prevent the frequent
failings that companies experience, but it doesn't work due to system
coupling... Although I am no fan of the Waterfall approach (except under
certain very special and easily identifiable circumstances), I think that to
keep blaming it for any problems that arise is, well... inconsistent.

Let's leave the development Methodology out of the discussion.:-)


>
>> So what are you going to do? You have a problem, have given it
>>your best shot, and can't solve it. Seek help. Hey, there's a forum where
>>you can get free advice... You post, get a solution and keep your job...
>>But
>>what you SHOULD do is admit that this problem requires expertise you don't
>>have, and tell your employer it will cost to solve it. If all of the
>>bunnies
>>did this, and if the forum was more careful about free advice, eventually,
>>employers would get the message...
>
> No, they wouldn't get the message. They'll fire one bunny and hire another
> just as bad.
> They're now making the same mistakes they made 30 years ago.

But doing that wouldn't solve their problem. Sooner of later (with the
controls I mentioned in place) they would have to pay a market rate for
proper advice or abandon the project.
>
>>(I hasten to add that if someone's job was actually on the line and I
>>could
>>help, I would not withold information. Survival trumps idealism every
>>time.
>>However, I would make it very clear what the course of action should be in
>>future.)
>>>
>>> How would you feel about being one of the experts? In other words,
>>> facilitating the
>>> replacement of ~50 of your countrymen with cheap labor?
>>
>>Robert, I have worked as both a brain and a bunny. No jobs were lost or
>>countrymen replaced in either case.
>
> Twenty years ago, these projects were staffed with Americans making the
> equivalent of
> $50/hr. Now they're staffed with third worlders making $30/hr, or people
> in their native
> countries making $10/hr.

Well, most companies in our part of the world are NOT outsourcing. By
adopting more modern approaches there is no need to. I have friends who
simply laugh at the idea of coding a new system development line by line, in
house OR outsourced.

Moving to component based approaches rather than line-by-line Procedural
code simply obviates the need to outsource (and also gets systems delivered
in a fraction of the time it would otherwise take...). I believe it is only
the procedural approach that is so labour intensive it needs to be
outsourced. Having said that, the sub-continent and China both offer
outsourced solutions in languages other than COBOL. I don't personally know
of any companies who are outsourcing C# or Java, but there probably are
some. I guess if VERY large development was being undertaken, it could make
sense. The modern trend is NOT to do that. Instead, manageable systems are
constructed quickly and easily using visual tools. This approach means that
things can be rebuilt quickly using existing components if the original
design is found to be lacking. It is much less risky to build and deploy a
series of subsystems rather than to attempt construction of one huge
monolithic solution.

>
> Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's
> still $80/hr.
> Clients are getting less for the same money; contracting companies are
> getting rich.

Hmmm... I know personally of a couple of recruitment agencies in the UK that
have failed within the last few years. I'm sure there are more. It is a very
competitive market place and more and more companies are using preferred
supplier lists that will only admit agencies with a markup within 15% (the
old cowboy days of agencies using 60% markups are thankfully, virtually
gone...) This may not be the case in the USA, of course.

Certainly, LARGE contracting agencies with many people placed are doing
well. I imagine that outsourcing is affecting their bottom lines, though.

The simple fact is that the old glory days of contracting are gone. As the
knowledge required to build commercial computer systems is deskilled and
moved to tools and packages, the levels of programming skill required are
less than once was the case. This means that people who are computer
literate, but not necessarily skilled programmers, can build their own
solutions. For "mission critical" systems, most companies will still require
professional construction and this is either outsourced or built quickly
using contract resource. Modern tools and approaches have made this
possible; in the COBOL days it simply couldn't be done. (Nothing ever got
done quickly using COBOL...)

Today it is the "Solutions Architect", rather than the Programmer who is
moving centre stage.

Pete.
--
"I used to write COBOL...now I can do anything."





From: Robert on
On Sat, 28 Jun 2008 12:09:53 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz>
wrote:

>"Robert" <no(a)e.mail> wrote in message
>news:lta86493p3lh3st265vlni5vh72p0tas9a(a)4ax.com...
>> On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood"
>> <dashwood(a)removethis.enternet.co.nz>
>> wrote:

>> Management thinks all knowledge came through training. If you ask the
>> brains, they'll say
>> they figured out the solution.
>>
>> Management keeps wanting to routinize computers, like factory jobs. We
>> know the problems
>> are unique, not repetative. You can't train to handle a problem that's
>> never happened
>> before.
>
>Hmmm... I think we part company here :-) I believe there are general
>approaches to problem solution that can be learned (empirically, by
>experience, and, to a lesser extent perhaps, but still valuably, in the
>classroom...), and I also believe that many of the problems encountered in
>IT have been encountered before. I would agree that every company THINKS
>their problems are unique... but that doesn't make it so.

Every company thinks its BUSINESS problems are unique, but its computer problems are
routine. It's actually the other way around.

>> Lock them in a War Room. No one leaves until the problem is fixed, even if
>> it takes all
>> night. Some companies have dozens of war rooms going day and night.
>
>If the skills and information required to solve the problem are not actually
>available in the "War Room" then you can lock them in there until the next
>Ice Age and it won't make any difference...

They solve the problem by deleting the errant transaction. It recurrs a month later
because no one fixed (or understood) the underlying logic error.

>> Waterfall was invented to prevent such frequent failures. It doesn't work
>> in these
>> companies because of hidden coupling between systems. The systems work in
>> isolation, but
>> don't play well together.
>
>Waterfall doesn't work perfectly for a number of reasons. Didn't you say
>earlier that Waterfall was invented to retard change? I think you later
>amended that to be that Waterfall was invented, not to retard change or keep
>control, but to avoid blame for errors? Now it is to prevent the frequent
>failings that companies experience, but it doesn't work due to system
>coupling...

They are variations of the same idea. If it works, don't change anything. Lockdowns are an
overt version of this. If you MUST change something, change only the bare minimum and then
test the hell out of it before it goes to production. There's no such thing as too much
testing. If it fails in production, redouble testing so that can't happen again.

>Although I am no fan of the Waterfall approach (except under
>certain very special and easily identifiable circumstances), I think that to
>keep blaming it for any problems that arise is, well... inconsistent.

The real problem with Waterfall is not waste of time and money; the real problem is that
it prevents us from doing things right. It seems to prefer spending twice as much on
stopgap solutions.

>> Twenty years ago, these projects were staffed with Americans making the
>> equivalent of
>> $50/hr. Now they're staffed with third worlders making $30/hr, or people
>> in their native
>> countries making $10/hr.
>
>Well, most companies in our part of the world are NOT outsourcing. By
>adopting more modern approaches there is no need to. I have friends who
>simply laugh at the idea of coding a new system development line by line, in
>house OR outsourced.

Most of the world thinks Americans are dumb. New Zealand is no exception.

>Moving to component based approaches rather than line-by-line Procedural
>code simply obviates the need to outsource (and also gets systems delivered
>in a fraction of the time it would otherwise take...). I believe it is only
>the procedural approach that is so labour intensive it needs to be
>outsourced. Having said that, the sub-continent and China both offer
>outsourced solutions in languages other than COBOL. I don't personally know
>of any companies who are outsourcing C# or Java, but there probably are
>some. I guess if VERY large development was being undertaken, it could make
>sense. The modern trend is NOT to do that. Instead, manageable systems are
>constructed quickly and easily using visual tools. This approach means that
>things can be rebuilt quickly using existing components if the original
>design is found to be lacking. It is much less risky to build and deploy a
>series of subsystems rather than to attempt construction of one huge
>monolithic solution.

There must be a receptive audience for that idea, because I've been hearing it as long as
I can remember. In the 70s, 4GLs would eliminate programmers by GENERATING all the code.
In the 80s, 'your people' could do it themselves with Lotus or Excel macros, or with
Access. In the 90s, any chimpanzee could drag and drop widgets, VB or VC++ would spit out
the code.

The words change, but the melody remains the same. It's old wine in new bottles.

>> Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's
>> still $80/hr.
>> Clients are getting less for the same money; contracting companies are
>> getting rich.
>
>Hmmm... I know personally of a couple of recruitment agencies in the UK that
>have failed within the last few years. I'm sure there are more. It is a very
>competitive market place and more and more companies are using preferred
>supplier lists that will only admit agencies with a markup within 15% (the
>old cowboy days of agencies using 60% markups are thankfully, virtually
>gone...) This may not be the case in the USA, of course.

<laugh> Ever since Y2K, 50% is a starting point. Contracting companies aspire to get more.
I've told the story here about one who cried poor because it was making only 70 out of 120
bill rate. I know for a fact that IBM keeps 160 out of 200 bill rate.

Blended Rate is their favorite phrase. That means you pay the same for everyone, from
bunny to brain. Never mind that there are 50 bunnies for every brain.

>Certainly, LARGE contracting agencies with many people placed are doing
>well. I imagine that outsourcing is affecting their bottom lines, though.

Big winners ARE outsourcing companies: Tata and Tech Mahindra.

>The simple fact is that the old glory days of contracting are gone.

No they're not. The action moved to India.

>As the
>knowledge required to build commercial computer systems is deskilled and
>moved to tools and packages, the levels of programming skill required are
>less than once was the case. This means that people who are computer
>literate, but not necessarily skilled programmers, can build their own
>solutions. For "mission critical" systems, most companies will still require
>professional construction and this is either outsourced or built quickly
>using contract resource. Modern tools and approaches have made this
>possible; in the COBOL days it simply couldn't be done. (Nothing ever got
>done quickly using COBOL...)

Actually, it is done quickly. A typical six month project is timelined this way. Take away
planning from the front end, say two months. Take away testing and approval signatures
from the back end, say three months, although 3.5 is better because you don't know whether
the manager will be on vacation. Whatever is left in the middle is programming time.
Typically that's two weeks, although it is common for it to be 2-3 days. I've even seen it
go negative. But programmers are kept around and paid for six months, just in case
something goes wrong.

Management sees the bill and THINKS programming took the whole six months, when it
actually took two weeks.

>Today it is the "Solutions Architect", rather than the Programmer who is
>moving centre stage.

Programmers used to be called Engineers, until real engineers complained about usurption
of the title. Now it's architects' turn to complain.

From: Pete Dashwood on


"Robert" <no(a)e.mail> wrote in message
news:vlab645g2aa2idppk6r0n6o3qhsv4nlnk3(a)4ax.com...
> On Sat, 28 Jun 2008 12:09:53 +1200, "Pete Dashwood"
> <dashwood(a)removethis.enternet.co.nz>
> wrote:
>
>>"Robert" <no(a)e.mail> wrote in message
>>news:lta86493p3lh3st265vlni5vh72p0tas9a(a)4ax.com...
>>> On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood"
<snip>
> Most of the world thinks Americans are dumb. New Zealand is no exception.
>
I'm surprised you feel empowered to speak for all New Zealanders, Robert. (I
certainly don't... :-))

It is certainly true that many people here are disappointed with the
leadership (or lack of it) in the USA, but I think that goes for many
Americans, too.

Americans visiting NZ will be assured of the same warm welcome and courtesy
we afford all our visitors (just as most Americans do for guests in their
country, also...)

Personally, I don't think Americans are stupid, being mindful of the
technological and scientific breakthroughs that have come out of America
during the 20th Century, and even, at a level closer to home, by some of the
contributions made in this very forum by Americans, including yourself :-)..

I DO think that some US foreign policy is "dumb" (foolish, stupid...), and
it bugs me I don't get to vote on something that affects my future almost as
much as anyone living in the USA...

<snip>
>
> There must be a receptive audience for that idea, because I've been
> hearing it as long as
> I can remember. In the 70s, 4GLs would eliminate programmers by GENERATING
> all the code.
> In the 80s, 'your people' could do it themselves with Lotus or Excel
> macros, or with
> Access. In the 90s, any chimpanzee could drag and drop widgets, VB or VC++
> would spit out
> the code.
>
> The words change, but the melody remains the same. It's old wine in new
> bottles.

There is some truth in what you say, insofar as things have been
consistently overhyped throughout the latter part of the 20th century. But
lessons are being learned. Last week MicroSoft only paid $100 million for a
new "natural language" search technology; a few years back during the dot
com boom, a lesser technology in the same field sold for over $500 million.
The lower price reflects the fact that overhyped claims about natural
language processing have been around for years. This time I believe they
have a bargain.

Just like you, and having been a programmer all of my working career, I am
also cynical about lurid claims for software. But I do believe stuff I have
seen and used myself.

Drag and drop tools like Visual Studio increase productivity (well, MY
productivity, anyway...:-)) many fold. Other visual tools like Iron Speed
and Stimulsoft make Web sites and reports a matter of minutes, rather than
days. Software and tools ARE getting better, more powerful and smarter than
ever before and this trend looks like continuing. Smart scripting languages
like Ruby, PHP, and Python are bringing quick builds of shared applications
within reach of non-specialist people. Frameworks like Rails for Ruby, .Net
(MicroSoft), Mono (Open Source), and Prototype (JavaScript) are providing
tens of thousands of packaged components that can be accessed with a mouse
click. People are building with Lego instead of with daub and what they are
building is ready much quicker and is more structurally sound. More
importantly, it can be easily disassembled and reassembled differently if
needed...

I'm currently working in a mixed COBOL / C# environment building some tools
for a client. Every day I kind of dread moving to the COBOL machine and
carving out code with the prehistoric IDE provided by Fujitsu and having to
test and debug thousands of lines of procedural code. Yet there was a time
(not so long ago...) when I did this quite happily. I'm even irritated at
having to go back into that environment to check and test procedural COBOL
generated by my own C# toolset... it is tiresome, boring and tedious. I'll
be glad when I've finished it and can get back to the much more interesting
task of expanding my horizons with LINQ and the finer details of C#...:-)

The point I'm trying to make is that if you had asked me say, 10 years ago,
if I would be unhappy writing COBOL, I would never have imagined that could
happen. Since then, I have visited new worlds and found them to be
good...:-)

Despite all the hype we've had over decades about future tools, there is
real evidence here and now, that at least some of these tools are delivering
what they promised.


>
>>> Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's
>>> still $80/hr.
>>> Clients are getting less for the same money; contracting companies are
>>> getting rich.
>>
>>Hmmm... I know personally of a couple of recruitment agencies in the UK
>>that
>>have failed within the last few years. I'm sure there are more. It is a
>>very
>>competitive market place and more and more companies are using preferred
>>supplier lists that will only admit agencies with a markup within 15% (the
>>old cowboy days of agencies using 60% markups are thankfully, virtually
>>gone...) This may not be the case in the USA, of course.
>
> <laugh> Ever since Y2K, 50% is a starting point. Contracting companies
> aspire to get more.
> I've told the story here about one who cried poor because it was making
> only 70 out of 120
> bill rate. I know for a fact that IBM keeps 160 out of 200 bill rate.
>
> Blended Rate is their favorite phrase. That means you pay the same for
> everyone, from
> bunny to brain. Never mind that there are 50 bunnies for every brain.

Then it's time this racket was publicly exposed and companies simply refused
to pay outrageous bill rates to middlemen. (It happened in the U.K....)
Sure, companies need contractors, but there are many agencies competing for
the business... Imagine how ONE ethical agency that charged say, 20% markup
and pitched their charge out rate 20% below what the cowboys are charging,
could clean up. They would have no trouble getting contractors or clients.
<snip>
>> (Nothing ever got
>>done quickly using COBOL...)
>
> Actually, it is done quickly. A typical six month project is timelined
> this way. Take away
> planning from the front end, say two months. Take away testing and
> approval signatures
> from the back end, say three months, although 3.5 is better because you
> don't know whether
> the manager will be on vacation. Whatever is left in the middle is
> programming time.
> Typically that's two weeks, although it is common for it to be 2-3 days.
> I've even seen it
> go negative. But programmers are kept around and paid for six months, just
> in case
> something goes wrong.

Yeah, right... :-)
>
> Management sees the bill and THINKS programming took the whole six months,
> when it
> actually took two weeks.

Whether they worked or not, they were on site for six months, being charged
to that project. As a Project Manager, I'd be a little perturbed by this
:-)...

Pete.
--
"I used to write COBOL...now I can do anything."


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Prev: compile+link Fujitsu Linux
Next: variable length in REDEFINES