'real' projects [Was cowhand coders]

[Ladislav Bashtarz]

Robert C. Martin wrote:
>
> Phlip wrote:
>
> >
> > And let's not forget all those managers and executives who refuse to
> > allocate anything resembling design time, then ask "where did all
> > these last minute changes come from?" at ship time!
> >
>
> Has anyone here ever actually worked for a manager that told them
> *not* do design. That told them to simply leap into code without
> doing any analysis and design?
>
> I find it hard to believe that such managers exist!

perhaps you should get out more?

> Now, I have worked on projects where managers set forth extremely
> unrealistic schedules. And I have seen *engineers* use that as a
> reason to skip design. But I have never seen a manager tell
> anybody not to design something.
>
> A tight schedule is not a reason to skip analysis and design. Indeed,
> it is all the more reason to perform good analysis and design.
> These steps cannot truly be eliminated from the software process. The
> engineer who skips them will find the forcefully reinserted at very
> inconvenient and expensive times. The engineer who skips them will
> find that the projects takes *longer* because of those omissions.
>
> What should you do if you are working in an unrealistic schedule?
> You should analyze and design as though the schedule were not
> unrealistic (which does not mean you take it easy). The analysis
> and design will give you some data that may be able so substantiate
> your claim that the schedule is unrealistic.

i repeat: you should get out more. if you have not
ever encountered a ceo, coo or cio banging his fist
angrily at a desk or a conference table, demanding
the impossible, then it is clear that you have not
worked on a real project.

it is quite easy to make general statements from the
safety of the lab, and extrapolate and expound on them
at length. the proof, however, is in the demands of
the real world projects that have to function properly
all the time.

> If, you don't do this. If you go ahead and work full bore in a
> project with an unrealistic schedule; and you skip thorough analysis
> and design as a way to speed things up, then you are essentially
> accepting the notion that there are shortcuts to good enginering. You
> are validating the managers choice of schedule by trying to conform to
> it.

the hype of the current slew of tools that purport to
solve all problems is powerful. the execs that wield
the power (but not the know-how) believe that it is
all magic. they therefore expect and forcefully
demand that magic in no time flat.

i tell my clients that they can have it;

1) cheap
2) fast
3) supporting their business

but they can choose only two from 1-3 above.

the bottom line is that if the client wants me to run
the project, then i set the time and budget, or i move
on.

-- ladislav bashtarz
ladi...@tagsys.com

[Scott P. Duncan]

> i repeat: you should get out more. if you have not
> ever encountered a ceo, coo or cio banging his fist
> angrily at a desk or a conference table, demanding
> the impossible, then it is clear that you have not
> worked on a real project.

I'm not really responding to the originator of these
comments, but rather some thoughts raised in me about
encounters with demands. Why is it that we often
seem to associate "real" projects (and experience in the
"real" world) with some of the most negative examples? I
do believe one can say that a "realistic" picture of the
software industry includes such things, but why must some-
one have to experience all the worst situations to be
taken seriously?

I've worked on "real" projects for commercial and govern-
ment organizations both as employee and consultant. I
certainly have seen my share of undesirably situations,
but the desirable situations were "real" projects, too.

I can agree that knowledge of the difficult situations is
important when discussing software development practices,
but because some things work in good environments and will
not work in poor ones, does that mean the folks in the better
environments should be discounted? Again, lacking in any
appreciation that the negative situations exists is the other
side of the coin.

But I do no consider it some sort of "red badge of courage"
that I have encountered difficult situations and troublesome
projects. They were undesirable, unpleasant, suboptimal ex-
periences, but I do not think I would wish them on anyone
just for the sake of "experience," expecting that no one can
be a "real" programmer, analyst, etc. if they have not had
to put up with such situations.

I am no longer as amazed, but am disappointed, at how much
this kind of thinking actually makes its way into the pre-
sumptions of what qualifies a person for certain work. People
are expected to perform, in spite of the inadequacies, as if
they are being told "Yes, we know conditions are undesirable,
but we're looking for people who can deal with that and get the
job done nonetheless, so we don't have to change things around
here."

It is the sense of pride in being able to do so as well as to
believe such a demand is a significant true indicator of skill
and professional behavior that worries me, not that people have
to face such things. I could accept it better if I felt there
was more concern to alleviate such situations.

I think our industry can get away with this because there is so
much legitimate technical and business challenge in the field at
this time in history, that many people are willing to put up with
the undesirable aspects just to experience the accomplishments
that are possible, taking pleasure in little things quite often.

I once interviewed for a job where I was told that I "understood
the vision but not the culture" and they needed the latter at
least as much. The "culture" was that single individuals had
complete control over very large aspects of a complex project,
worked exytremely long hours to get the work done, and were
likely not part of the project team (or even the company) six
months later. I did not get (nor want) the job. It was with a
real up and coming organization that burst into the heavens with
their systems and proceeded to fall as steeply before being bought
out by one of the longer-term, and many times larger, companies
in the field. In speaking to ex-employees some years later,
they still regarded the experiences somewhat fondly, not because
of what they achieved for the company, but what they had personally
managed to do despite the awful conditions.

> the proof, however, is in the demands of
> the real world projects that have to function properly
> all the time.

I would agree with this, except as regards the boundaries of the
"demands" and what a "properly functioning project" might mean as
compared to "properly functioning product." I'm not sure that
a lot of the "demands" placed on a "project" are "proof" of any
really good thing about our industry. On the other hand, the
technical demands to be overcome, as opposed to the purely arti-
ficial ones associated with project management matters can be
worthwhile struggling against and overcoming.

> the hype of the current slew of tools that purport to
> solve all problems is powerful. the execs that wield
> the power (but not the know-how) believe that it is
> all magic. they therefore expect and forcefully
> demand that magic in no time flat.

And as long as someone is willing to say "Yes sir, I'll do that"
this will not stop. I do not see such a situation as a matter
of pride for this, or any, industry. More often than not it
results in failures, rather than successes -- and how failures
get dealt with is the subject of another thread.

And I know it is not "realistic" to tell people to "vote with their
feet" since a large number of folks cannot see their way clear to
doing this. But acquiescing to such situations by suggesting those
who don't want to support them must come out a "get dirty" to be
considered "real" in some sense, isn't likely to change things.

> i tell my clients that they can have it;
>
> 1) cheap
> 2) fast
> 3) supporting their business
>
> but they can choose only two from 1-3 above.

I forget exactly who I heard discuss this, but they said
that you could have all three, just not all at the same
time, i.e., until you had enough process/management maturity
to manage at least two, you could not successfully work on
the third without sacrificing one of the others. So the
claim of "pick two" is largely correct, but not an absolute.
It is a way for people to deal with individual situations,
especiually if they can walk aweay from them and not have to
care about the longer-term health of the organization.

> the bottom line is that if the client wants me to run
> the project, then i set the time and budget, or i move
> on.

And if you can get that authority (or vote with your feet),
then you can deal with the "real" world in a personally
satisfactory way.

[Robert C. Martin]

Ladislav Bashtarz wrote:
>
> Robert C. Martin wrote:
> >
> > Phlip wrote:
> >
> > >
> > > And let's not forget all those managers and executives who refuse to
> > > allocate anything resembling design time, then ask "where did all
> > > these last minute changes come from?" at ship time!
> > >
> >
> > Has anyone here ever actually worked for a manager that told them
> > *not* do design. That told them to simply leap into code without
> > doing any analysis and design?
> >
> > I find it hard to believe that such managers exist!
>
> perhaps you should get out more?

Hmmm. Perhaps 27 years, the last five of which have been spend
on the road consulting for major coporations is not getting out
enough...

>
> > Now, I have worked on projects where managers set forth extremely
> > unrealistic schedules.

>

> i repeat: you should get out more. if you have not
> ever encountered a ceo, coo or cio banging his fist
> angrily at a desk or a conference table, demanding
> the impossible, then it is clear that you have not
> worked on a real project.

Well, as I said above, I have seen managers ask for unrealistic
things (although bangning on desks was usually not part of it -
things like that are a little Kruchevian)

As for real projects; I think I may have worked on one or two.

>
> it is quite easy to make general statements from the
> safety of the lab, and extrapolate and expound on them
> at length.

Believe me, I am not in the safety of a lab right now....

I have never seen a manager get up and say: "Right lads, no more
designing, time to code now." I have seen managers demand a project
be complete at an unreasonable date.

--
**We are looking for good engineers, See our website
**for more information.

Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan

[Scott P. Duncan]

Ell wrote:
>
> Robert C. Martin (rma...@oma.com) wrote:
> :
> : I have never seen a manager get up and say: "Right lads, no more

> : designing, time to code now." I have seen managers demand a project
> : be complete at an unreasonable date.
>

> Pray tell, what's the difference?

A dumb manager does the former; a smart one, the latter, allowing
the project staff to dig their own grave.

Okay, that was mean, but I was being sarcastic only to a point.

It's hard to think of any manager doing the former unless the
perception held of the staff was that they were so inexperienced
and lacked so much sense about development that they actually had
to be told to move on.

On the other hand, the latter acknowledges that the staff knows
too much to be micro-managed in a foolish way, but assumes they
are willing to accept unreasonableness in scheduling and, perhaps
as a misguided sign of professional skill and pride, they will
try to do it, perhaps fail, but also perhaps get the job done
faster and cheaper than if they weren't put under pressure.

The software industry is one in which the feeling is that pressure
must be applied (the spin doctor phrase is "stretch goals") or no
useful work will get done. I submit this is because the front end
of the lifecycle is so immaturely practiced in so many cases that
time is not well spent, management can tell that, so they put the
pressure on to get to construction and testing as soon as possible.
It may not be documented well, not all of the requirements will
have been uncovered, there may be rework to do, but, hey, something
got done. Version 1.1 can address the remaining problems.

[Phlip]

Robert C. Martin wrote in article <3499972C...@oma.com>...

>> > I find it hard to believe that such managers exist!
>>
>> perhaps you should get out more?
>
>Hmmm. Perhaps 27 years, the last five of which have been spend

>on the road consulting for major corporations is not getting out
>enough...

He means out among managers who can't afford you.

(Their fault, and for obvious reasons.)

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======
-- Search Keywords: Software, C++, OO, Windows, Traci Lords --

[Phlip]

Scott P. Duncan wrote:

>...I submit this is because the front end

>of the lifecycle is so immaturely practiced in so many cases that
>time is not well spent, management can tell that, so they put the
>pressure on to get to construction and testing as soon as possible.
>It may not be documented well, not all of the requirements will
>have been uncovered, there may be rework to do, but, hey, something
>got done. Version 1.1 can address the remaining problems.

Guy - it's like you are reading my MIND!

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======

-- Whip me. Beat me. Make me install Oracle. --

[Ell]

Robert C. Martin (rma...@oma.com) wrote:
:
: I have never seen a manager get up and say: "Right lads, no more
: designing, time to code now." I have seen managers demand a project
: be complete at an unreasonable date.

Pray tell, what's the difference?

And yes, I've experienced this also.

Elliott
--
Copyright 1997 Elliott. exclusive of others writing.
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell

[Tim Ottinger]

Hi.

Please realize that I'm describing, not defending, some of
these really dumb management practices. I find most of this
unconscionable, but have seen it happen.

Scott P. Duncan wrote:
> It's hard to think of any manager doing the former unless the
> perception held of the staff was that they were so inexperienced
> and lacked so much sense about development that they actually had
> to be told to move on.

Or believing that the lack of code was simply a motivational
problem, rather than an engineering one. Some managers think
that all problems are motivational problems.

Or because the customer has caught them lowballing the estimate
and are banging on his door crying "where's that system, how
much do you have done, what can I look at". This problem is
largely mitigated by having an incremental delivery style, but
happens fairly often with lowballed waterfall projects.

> On the other hand, the latter acknowledges that the staff knows
> too much to be micro-managed in a foolish way, but assumes they
> are willing to accept unreasonableness in scheduling and, perhaps
> as a misguided sign of professional skill and pride, they will
> try to do it, perhaps fail, but also perhaps get the job done
> faster and cheaper than if they weren't put under pressure.

The typical scenario involves a "foot-in-the-door" project.
A major company has put up a project for bids and the only
way to beat someone else to the business is to intentionally
lowball the estimate. The thought is that it will be too
painful for the customer to back out at the last minute,
and that having success "by any means" will not only result
in payment for the contract, but followon work, and also
citeable experience in the domain. In this way, some shops
"go begging to market". It's a way to gather experience
in a domain, with a given customer, or in a given technology.

> The software industry is one in which the feeling is that pressure
> must be applied (the spin doctor phrase is "stretch goals") or no
> useful work will get done.

This is the less common situation, IME. The more typical
are the "begging to market" scenario, or a sick policy of
not tying salesman compensation to successful delivery.

In the latter case, the salesman is paid a percentage of
the contract value on the day it's signed. This causes
him to sign as many high-value contracts (big jobs) as
possible in the shortest amount of time (too quick to
allow any reasonable system to be built). It results in
a company that is dramatically overcommitted, and which
must rush all products to market only well enough to
result in initial payment so that the customer may be
placed on the back burner (relieving pressure for a
short time) while other systems are built.

> I submit this is because the front end
> of the lifecycle is so immaturely practiced in so many cases that
> time is not well spent, management can tell that, so they put the
> pressure on to get to construction and testing as soon as possible.
> It may not be documented well, not all of the requirements will
> have been uncovered, there may be rework to do, but, hey, something
> got done. Version 1.1 can address the remaining problems.

I think that managers usually are under pressure already before
they resort to such silly non-management of projects. It's not
because requirements and analysis were done poorly so much as
because the entire project is given less time than a proper
analysis *or* design would require. They panic, wet themselves,
and then proceed to push the pressure downward in improper ways.

I know managers who could not sleep nights, who had nervous
problems, who had ulcers, and the like because of the pressures
of being in just the kinds of situations I described.

To blame the problem on developers or their front-line managers
alone is naive. Such really big problems come from sick
organizations.

--
+-----------------------------------------------------------+
| Tim Ottinger: http://www.oma.com/ottinger |
| Object Mentor: http://www.oma.com 800-338-6716 |
+-----------------------------------------------------------+
| Design, Consulting, Mentoring, Training |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein

[Scott P. Duncan]

Tim Ottinger wrote:
>
> I think that managers usually are under pressure already before
> they resort to such silly non-management of projects. It's not
> because requirements and analysis were done poorly so much as
> because the entire project is given less time than a proper
> analysis *or* design would require.

I think what I was getting at was that the latter is because the
belief exists that the upfront phases don't succeed in their
goals in any event, so why allocate as much time for them anyway?
Given that belief -- based on experience that requirements and
specifications do not come to the closure expected/hoped for and
redesign/rework seems to be a given -- allocating the time to do
both of these well (perhaps through a spiral modeling or proto-
typing approach) does not seem fruitful.

I was, in this specific comment, not simply blasting management
but also indicating that technical practitioners have to get a
lot better at the front end in order to build up some confidence
that, given the time, very valuable results will be achieved that
can lead to implementation and testing which proceeds more smooth-
ly.

[Ron Perrella]

Robert C. Martin wrote:

> [lines deleted.]

> Believe me, I am not in the safety of a lab right now....
>

> I have never seen a manager get up and say: "Right lads, no more
> designing, time to code now." I have seen managers demand a project
> be complete at an unreasonable date.

What? I have heard this *many* times! I even heard the following:

"I think we spent too much time designing the last project"

(first successful project this manager ever had!)

[Dave Vance]

Just to add to the meta-discussion:

1) I agree with most of the discussion on the percentage of testing
time required, which was the original question. 30-50% of a
project's time
spent on testing is nothing extraordinary, depending on how many
parts of
the final product are unique. Perfect people don't make perfect
software,
and it has more to do with the uniqueness of the product than human
error.
Even a master carpenter would probably spend that much time testing
out a
new swing set for his kids compared to the time he spent building
it.

2) On the topic of unrealistic schedules, I think the choice of
"managers are weenies" as a root cause is short-sighted. Yes,
there are a lot of managers out there with little experience in
projects, but you get a lot of schedule pressure even when the
manager's just as experienced as you. Typically the customer
doesn't really understand what he/she is asking for and everyone
tries
very hard to make the customer happy. I've been on lots of
projects where
the view from management was "yes, I know this is going to be hard,
but
we'll make a lot of money if we make it". A good organization
shares some
of those rewards with their employees - and yes, that does happen.

3) What's an "unrealistic" schedule to begin with? More effort than
you've
put in before? More effort than anyone's ever done in the history
of
computing? More than 8 hours a day? Working weekends? Let's face
it,
our expectations of what's fair are highly variable, and change as
we gain
experience, get a family, etc. What's completely unrealistic to
you may be
perfectly acceptable to the guy sitting next to you, or to the next
company
down in the Yellow Pages. In today's competitive world, companies
HAVE to
push somewhat on their people, if they get complacent they'll be
out of a
job. Sorry guys, but that's the way it works. If you don't
believe me,
wait 10 years and see how many jobs have gone to Indian and
Chinese-staffed
companies - their view of unrealistic is a lot different from ours!

-- Dave --

[Tim Ottinger]

Scott P. Duncan wrote:
> I think what I was getting at was that the latter is because the
> belief exists that the upfront phases don't succeed in their
> goals in any event, so why allocate as much time for them anyway?

Okay. I believe you've observed this. It's not common in my
experience, but I don't doubt that this occurs out there somewhere.

I often talk about the opposing Two Great Fears. The first Great
Fear is a hacked-together system, which is a nightmare because
it is released under great stress, and can be maintained only
barely, and under great stress. The second Great Fear is that
of analysis paralysis, which is a nightmare because entire teams
of people leech resources from an organization for many months
or years without producing anything of value to the company.

Obviously, the ideal is in the center, where enough analysis
and design are done, but the project isn't stalled. This is
often best managed through iterative/spiral development.

> Given that belief -- based on experience that requirements and
> specifications do not come to the closure expected/hoped for and
> redesign/rework seems to be a given -- allocating the time to do
> both of these well (perhaps through a spiral modeling or proto-
> typing approach) does not seem fruitful.

Interesting. Redesign and rework are a given, in one context:
Requirements and technology will change, and any successful
product is expected to keep abreast of both kinds of changes.

But this only points out that there has to be a balance so that
a project strays nowhere near the Two Great Fears but sails
between them.

> I was, in this specific comment, not simply blasting management
> but also indicating that technical practitioners have to get a
> lot better at the front end in order to build up some confidence
> that, given the time, very valuable results will be achieved that
> can lead to implementation and testing which proceeds more smooth-
> ly.

I won't argue against this point, even without the above
paragraphs to support it. I was not accusing you of mindlessly
lambasting managers, but merely trying to inject another
perspective on why it's often so bad. It is often neither
incompetence nor disbelief on the manager's part. It can
be an organizational dysfunction.

Tim

[Brett J. Stonier]

Ladislav Bashtarz wrote:

<snip>

> perhaps you should get out more?

<snip>

> i repeat: you should get out more. if you have not
> ever encountered a ceo, coo or cio banging his fist
> angrily at a desk or a conference table, demanding
> the impossible, then it is clear that you have not
> worked on a real project.
>

> it is quite easy to make general statements from the
> safety of the lab, and extrapolate and expound on them

> at length. the proof, however, is in the demands of

> the real world projects that have to function properly
> all the time.

Is this sort of stuff really necessary? What sort of environment does
it produce to turn well-intentioned commentary or questions into a
contest of bravado? This ancient but low-brow technique of debate is
useful only when you don't have valid statements to back up your
opinions -- it serves to distract from the real issues by attacking the
integrity of the other person and putting them on the defensive.

Not everyone lives in your world. Certainly, there are unreasonable,
demanding, and bad managers out there. There are also reasonable and
intelligent ones. IMO, your criteria that a "real" project is one in
which you've got unreasonable demands from a bad manager is about as
valid as the sterotypical elderly person's stories about their "real"
childhood, when you had to walk barefoot in the snow 12 miles to and
from school each day, uphill both ways. There's nothing wrong with
taking pride in overcoming adversity, but it is wrong to try to
invalidate other people's struggles and accomplishments.

You sound like you have intelligent, meaningful things to add to this
thread and these newsgroups -- don't ruin that by turning dialogue into
argument and colleagues into foes.

Tired of the negative vibes around here ...

Brett S.
http://www.mtjeff.com/~calvin/devhbook

[Scott P. Duncan]

Tim Ottinger wrote:
>
> Scott P. Duncan wrote:
> > I think what I was getting at was that the latter is because the
> > belief exists that the upfront phases don't succeed in their
> > goals in any event, so why allocate as much time for them anyway?
>
> Okay. I believe you've observed this. It's not common in my
> experience, but I don't doubt that this occurs out there somewhere.

Folks aren't blatant about how they express this, but the willing-
ness to allow design and even coding to go on while requirements
are being worked seems common in my experience. Now this prac-
tice is sometimes called "prototyping," but it is often more just
"guessing" at what the requirements will be, then going back to
rework parts that were guessed at incorrectly. It often has no
connection to the requirements clarification effort as is my
feeling for what prototyping is really all about. Hence the
specfiication and construction aspects of development work in
an inefficient relationship (at best) and at cross-purposes
(in worse situations).

> Obviously, the ideal is in the center, where enough analysis
> and design are done, but the project isn't stalled. This is
> often best managed through iterative/spiral development.

And the latter is a conscious management plan where the knowledge
gained is fed back into the next cycle. This is very different
from development teams going off and building what they think
the customer is likely to want while systems engineering is at
work on the "official" requirements. In a given situation,
either side could be wasting the time, but it is clearly the
up front part of the process that is "broken" since it does
not have all relevant project organizations working together.

One might argue that the implementation/construction part of
the process is "broken" since the developers are not cooperating
in the front end. But the implementors usually hum along well
and produce something close to what they envision to be the
product. But that's not so much a "broken" implementation
process as "broken" team relatonships. Since, if we were to
assume the "requirements" that the implementors have are good
ones, they go about their business well.

And though I emphasize the front end, I do not mean to suggest
that the systems engineers are fully at fault. To some extent
they "own" that part of the process, but they are not fully in
control of other participants behavior.

> Interesting. Redesign and rework are a given, in one context:
> Requirements and technology will change, and any successful
> product is expected to keep abreast of both kinds of changes.

I'm thinking more of rework, not due to requirements evolution
over time, but faulty requirements (or understanding of them)
in the first place. I usually reserve "rework" as a term to
imply "unnecessary redesign and reimplementation" which should
have been able to be avoided with known, current technical and
process knowledge. An effective prototyping or spiral approach
can be a part of managing requirements that are genuinely in
a state of flux.

And, because the implementation part of the lifecycle often
functions the best (largely perhaps because it is under one
management chain of control), if the "guess" is correct, a
decent product or component can emerge. On the other hand,
a bad guess causes development pain. That there is very often
the perceived need to proceed on a "guess" of one sort or
another with many people agreeing that it has to be done be-
cause specification is incomplete or unstable is part of my
reason for claiming the front-end is "broken" in some way
since the implementation decision seems to occur somewhat
in spite of, rather than in partnership with, the front end's
situation.

It is all very "realistic" behavior given the situations we
find ourselves in because, I believe, they are "broken." We
can leave them broken and try to heal them over time, but it
seems that, over several decades of software development ex-
perience, most technological (and methodological) effort has
been expended on making the implementation process (and tools)
better. For some front-end workers, a word processor is the
best technology they've ever seen.

> I was not accusing you of mindlessly lambasting managers,

And I did not mean to suggest you were. I was trying to
express my own apology if anyone did think I was since I
was coming down on management estimation expectations at
that point. Hopefully, I've shifted somewhat in this post
to suggest that management is responding to some "real"
things they see happening. It's just that the commitment
to fix some of the problems cannot yet seem to be mustered.

> It is often neither
> incompetence nor disbelief on the manager's part. It can
> be an organizational dysfunction.

Quite truw, something everyone is caught up in. But at this
level of discussion, I do think that's where senior management
has to step in and saying things are "broken" and try to get
something moving to fix it. Organizational issues of this
nature have to be something management "owns." They may not
have to be the ones to develop the fix, but they have to see
to it that the fixes get applied or that decent attempts to
do so are supported.

By the way, I've seen good and bad approaches to this in
the same company as I'm sure many have. One development
project may hum along while another suffers problems. If
the middle management cannot, among themselves, make the
knowledge of how success works one place translate into an
effective transfer to where it can be used to help another
project improve, senior manmagement needs to step in to
make that happen.

This is where the famous quality/process improvement and
technology transfer cry of "getting management support and
involvement" comes in, I believe. They have to make it
clear that addressing such issues is a management priority
which cannot be passed on to lower and lower levels to "fix"
through myriad of committees and teams.

Of course, now I'm on another topic, which, if someone wants to
pursue, I think should be done by changing the subject heading.

[Scott P. Duncan]

Dave Vance wrote:
> Typically the customer
> doesn't really understand what he/she is asking for and
> everyone tries very hard to make the customer happy.
> I've been on lots of projects where the view from
> management was "yes, I know this is going to be hard,
> but we'll make a lot of money if we make it". A good
> organization shares some of those rewards with their
> their employees - and yes, that does happen.

Sure...what I'm concerned with is the situation being a chronic
case, i.e., nearly every project/release is this way. At some
point, you need to get to a customer relationship where reason-
able expectations can be set. Customer survey data I've been
able to see in its raw form, suggests lack of faith that, given
more time in a schedule or more resources, the customer will
get what they want with any more likelihood than if they squeeze
resources. We do dig our own grave here by taking on things
under such conditions, but that's because customers have come
to expect that software is late, costs too much, is of poorer
than hoped for quality, and still doesn't deliver what's expected.
This is part of the "broken" front-end: how expectations get
set.

> 3) What's an "unrealistic" schedule to begin with?

One where it is acknowledged, at nearly the outset, that the
work cannot be reasonably done within the resources alloted
unless preplanned overtime will be used to meet the minimum
schedule, not allowing for unexpected occurrences. And, as
I suggest, doing this over and over, one release after
another.

I watched one "successful" organization do this over 3-4 years.
Some key staff burned out over time and moved on to other
projects. Others stayed because the management did share
rewards with some top people -- the project had the largest
number of people being paid in the top technical category which
meant a larger part of the overall corporate bonus sharing
program as well as basic salary levels. But customers got
more and more dissatisfied with quality and other matters,
though they kept getting promised more and more. But it
was a critical product-line that neither customer nor
supplier wanted to see dropped, so life went on. New
senior management showed up and the head of the project
announced retirement a year later with other middle management
getting moved around.

> More than 8 hours a day? Working weekends?

Lots of folks are willing to do this, sometimes, but not as a
regular diet after a while. Also, when your estimates at the
outset of a project presume this, you're already introducing
risk factors by taking away the time you'd use to address
other risks and unforseen occurrences. Almost everyone I've
ever worked with has worked overtime and weekends to meet
commitments. They have not liked it when the "extra effort"
time has been assumed as part of the regular scheduling of
the project and now "extra, extra effort" (Sundays and holi-
days, all-nighters) becomes the slack.

[I'm not in favor of the "work expanding to fill the allotted
time" phenomenon which makes people not want to hear about
"slack" time estimates.]

> In today's competitive world, companies HAVE to push
> somewhat on their people, if they get complacent they'll be
> out of a job. Sorry guys, but that's the way it works.
> If you don't believe me, wait 10 years and see how many
> jobs have gone to Indian and Chinese-staffed companies -
> their view of unrealistic is a lot different from ours!

And for some, their view and ability to meet certain customer
expectations is different as well. I don't know what will be
the situation in a decade. Lots of things change. But I've
heard the "threat from over the Pacific" story plenty. I have
also seen some of the world-wide benchmark studies done which
indicate it is not going to be low-ball, sweatshop pricing that
does the U.S. software industry in. It will be low quality and
failure to meet product feature/performance expectations. Peo-
ple will pay for reliability. They have to believe they will
get it, when it is promised, and for about what was estimated to
be the cost. Predictability is worth a good bit. Customers
will play the negotiation game. Software developers have to
develop the ability, and therefore the confidence, to deliver
on promises. With that confidence, they can afford to let some
ganme-playing negotiation projects go to others.

Perhaps some SEI folks can comment on this, but it is my under-
standing that upper maturity organizations are not the cheapest
bidders on projects, but still win contracts based on their
reputation for predictability and reliability. I have also heard
from people at some such organizations that they begin to prefer
to deal with customers that have such a perspective on the rela-
tionship between custome and supplier.

Perhaps what will happen in a decade is not the massive flow of
work offshore, but a maturing of what happens onshore and the
growing reputation of some organizations to be a vendor of choice
though not the least expensive.

[Robert C. Martin]

Ell wrote:
>
> Robert C. Martin (rma...@oma.com) wrote:
> :

> : I have never seen a manager get up and say: "Right lads, no more

> : designing, time to code now." I have seen managers demand a project
> : be complete at an unreasonable date.
>

> Pray tell, what's the difference?
>

The difference is that the manager who sets an unreasonable date is
not telling the engineers to skip design. He is not forcing them
to leap into code. Rather he is simply telling them when the whole
process must be complete.

This gives the engineers an interesting option. Knowing that skipping
analysis and design will *lengthen* their time to completion, they can
proceed as through the deadline *was* realistic; and product a good
analysis and design. Once they have this in hand, it is the tool that
can prove that the deadline is unrealistic. Using what they learned
in their analysis and design, they can present to their manager the
reasons why the deadline is unrealistic -- long before the deadline
has passed.

Will the manager be happy? Obviously not, but he will have options.
He can go back to his customers and bosses and re-set their
expectations. He can reassess staffing. He can reassess required
functionality. He may not be happy, but he will have roome to
maneuver.

But if the engineers simply leap into code in a project that has an
unrealistic deadline, they will simply miss the deadline. Proof that
the deadline will be missed will come late -- sometimes only after the
deadline has passed. At this point the manager will have no good
options. And he'll want to know why someone hadn't made the case that
the deadline was unrealistic a long time ago.

Managers have the perogative to set deadlines. Engineers have the
responsibility to prove to the manager that their deadlines are
unrealistic.

[Scott P. Duncan]

Robert C. Martin wrote:
>
> This gives the engineers an interesting option. Knowing that skipping
> analysis and design will *lengthen* their time to completion, they can
> proceed as through the deadline *was* realistic; and product a good
> analysis and design. Once they have this in hand, it is the tool that
> can prove that the deadline is unrealistic. Using what they learned
> in their analysis and design, they can present to their manager the
> reasons why the deadline is unrealistic -- long before the deadline
> has passed.

Frankly, based on prior projects, this can usually be done without
getting some significant distance into the project, i.e., after
analysis and design is over. If you can use function point estima-
tion on the evolving requirements, you can present some interesting
data on what the project is likely to require as well as to show the
pattern of, usually, expanding requirements expectations.

> Will the manager be happy? Obviously not, but he will have options.
> He can go back to his customers and bosses and re-set their
> expectations. He can reassess staffing. He can reassess required
> functionality.

I would argue that a really good up front estimation process is
what you have to have to begin to make a manager feel comfortable
doing this. Also, some track record of being able to meet dead-
lines when you propose what they realistically should be as well as
definethe specific risks involved in trying to reduce cost, schedule,
and/or features. (Risk analysis seems to me to be even less widely
performed than some sort of estimation.)

> He may not be happy, but he will have roome to maneuver.

If he/she feels comfortable maneuvering. Sometimes, facts are
not the issue and what constitutes proof for one level of man-
agement can be viewed as just "excuses from development" by
another.

> But if the engineers simply leap into code in a project that has an
> unrealistic deadline, they will simply miss the deadline. Proof that
> the deadline will be missed will come late -- sometimes only after the
> deadline has passed.

But at least, there is some proof that this project went south due
to the bad scheduling. Will anyone look back on this experience the
next time and think about whether or not the next deadline should
be questioned? The industry seems to be filled with the news coming
too late all the time. Who is it that doesn't want to hear about
the abundant proof (of something going wrong) that exists?

> At this point the manager will have no good options.
> And he'll want to know why someone hadn't made the case that
> the deadline was unrealistic a long time ago.

I do agree with both of these statements. Though I have seen the
second situation occur when the same manager didn't want to hear
about the problems, in fact knew it was risky, at the outset. As
I recall, middle and senior managers often talk about how they "do
not want people to bring them problems, they want solutions." Now
we know what that can mean in the best, dedicated, professional
sense of not whining about things to managers, but bringing them
the "options" noted above. The management response when "bad news"
is brought to them, will affect whether such statements can be
assumed to be taken in that best sense or not.

> Managers have the perogative to set deadlines. Engineers have the
> responsibility to prove to the manager that their deadlines are
> unrealistic.

I believe both of these, too. However, to make the actual project
situation effective, the interaction between the former and the
latter has to make the engineers believe their responsibility will
be taken seriously.

I don't want to suggest, as I have noted before, that there is some
evil plot afoot among management in general to deliberately sink
projects. What I am wondering is whether we have gotten to a
point in the practice of the profession, both technically and mana-
gerially, where there is agreement on what constitutes "proof"
about what is going on in software development and what is reasonably
possible.

In another post, there was discussion of "extra effort" and "extra,
extra effort" and what "reasonable" meant in working toward making
a schedule. If successful projects is really what we want to see
happen, what data do people feel we must have to make this likely?

[Phlip]

Robert C. Martin wrote:

>Managers have the prerogative to set deadlines. Engineers have the

>responsibility to prove to the manager that their deadlines are
>unrealistic.

But one blind spot remains. There are shops where neither the boss nor the
colleagues have any concept what the design phase should look like. Where
"just start beating on it" is beyond question. Sounds like a marketing
opportunity for me.

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======

-- How can I get the Internet installed in my teeth? --

[Tim Ottinger]

I continue to use the term "engineer" loosely, meaning
"software developer with a conscience"...

Robert C. Martin wrote:
> The difference is that the manager who sets an unreasonable date is
> not telling the engineers to skip design. He is not forcing them
> to leap into code. Rather he is simply telling them when the whole
> process must be complete.
>

It would seem that the right thing would be for the manager to
describe the situation (give the real facts that there's not
really time) and then call for options.

It could be an optimization opportunity, and engineers are
usually pretty good at that stuff. I think that to mandate
poor engineering practices to cut the project is silly.
There are almost always some other options, and some of them
involve the things that managers have control of (the Four
T's: Time, Treasure, Talent, and Target).

--
Tim

[Tony Schneider]

Tim Ottinger wrote in message <349BF814...@oma.com>...

>It would seem that the right thing would be for the manager to
>describe the situation (give the real facts that there's not
>really time) and then call for options.
>
>It could be an optimization opportunity, and engineers are
>usually pretty good at that stuff. I think that to mandate
>poor engineering practices to cut the project is silly.
>There are almost always some other options, and some of them
>involve the things that managers have control of (the Four
>T's: Time, Treasure, Talent, and Target).
>

I agree with your viewpoint but you also have to be careful of the
bargaining process that goes on in this type of session. I remember a
lecture by Tim Lister where he discussed a process that went something like
this.

Manager: Can you do this is two weeks?
Team: Absolutely no way!!
Manager: What about three weeks?
Team: Absolutely no way?
Manager: Well what about four weeks?
Team: Well, maybe.

The end result is that the new estimate from the negotiation is the first
date that has a non zero probability of success in the eyes of the
programming team. Unfortunately I have seen processes like this trap
programming teams in a variety of settings.

[Michael Feathers]

Ladislav Bashtarz <ladi...@tagsys.com> wrote in article
<349929...@tagsys.com>...

> Robert C. Martin wrote:
> > Now, I have worked on projects where managers set forth extremely

> > unrealistic schedules. And I have seen *engineers* use that as a
> > reason to skip design. But I have never seen a manager tell
> > anybody not to design something.

Funny story. I ran into Kent Beck at OOPSLA and he
was demonstrating a technique that he uses called
"programming in pairs." The rule is that no one in
an organization programs alone. One person is
typing and the other hangs back and usually catches
things that the other isn't thinking about. It looks
like a very good idea. Good for cross-training and
two minds do think better than one.

Anyway, I asked him how he would reply to a manager
who thought that it was a waste. He said (paraphrasing)
"I'd just ask him if he wants me to solve any of his
problems. He has solutions for mine, maybe I should
solve his."

Gotta love it.

[Tim Ottinger]

> Funny story. I ran into Kent Beck at OOPSLA and he
> was demonstrating a technique that he uses called
> "programming in pairs." The rule is that no one in
> an organization programs alone. One person is
> typing and the other hangs back and usually catches
> things that the other isn't thinking about. It looks
> like a very good idea. Good for cross-training and
> two minds do think better than one.

I wasn't the first to suggest this, but rather a few years
ago (like maybe 7) I had started talking about this. I had
some friends on my programming team, and when we worked
together we got not only better designs, but quicker as
well. We could take on two jobs, do them serially or
alternate incrementally between them, and really crank it
out.

Every time I've mentioned this to a manager I was told that
I was making it up, it couldn't possibly be more productive
than having two people working independently (because of
unproductive "conversation": apparently considered to be
a cause of most lost productivity). The idea was rejected
with a religious ferver.

I'm interested in the idea that Kent Beck is having success
I wonder what the context is for such an idea to be accepted.

I'd love to have had this a little while back, but some
geographic considerations made it rather difficult. It
really does help one come up to speed on a partially-
existing system.

[Stuart Park]

Ron Perrella (perr...@mindspring.com) wrote:
: > I have never seen a manager get up and say: "Right lads, no more
: > designing, time to code now." I have seen managers demand a project
: > be complete at an unreasonable date.

: What? I have heard this *many* times! I even heard the following:

: "I think we spent too much time designing the last project"

: (first successful project this manager ever had!)

Not only have I experienced a boss thinking that too much time
was spent on design, but he would also do programming himself
(without _any_ design or testing)!

--
Stuart Park Melbourne, Australia
Senior Analyst/Programmer E-mail: stu...@psd.com.au
Prometheus Software

[Steve Furlong]

In article <01bd0e3b$e07a1b40$64a7...@feathers.icanect.net>,

Michael Feathers <feat...@icanect.net> wrote:
>Funny story. I ran into Kent Beck at OOPSLA and he
>was demonstrating a technique that he uses called
>"programming in pairs." The rule is that no one in
>an organization programs alone. One person is
>typing and the other hangs back and usually catches
>things that the other isn't thinking about. It looks
>like a very good idea. Good for cross-training and
>two minds do think better than one.

Five or six years ago (IIRC) in Computer Language magazine, Larry
Constantine (IIRC) talked about a visit to PJ Plauger's company,
Whitesmiths (IIRC). All or most of the programmers worked in pairs on
the terminals. They preferred it and it was more productive.

I've suggested trial runs of this technique on three of my jobs. I got
nothing but resistance, not only from managers but from other
programmers. Managers wouldn't even give the idea a hearing; I think
they believed it would lead to too much chit-chat. Programmers
variously didn't want others looking over their code (or perhaps their
methods of coding) or didn't want anyone to see how they spent their
day.

The biggest lesson that I took from this is that even in organizations
which claim that their productivity is too low and that they need to
"do something" to bring it up, no one is willing to try anything
new. I guess management just wanted programmers to work longer hours,
and "process improvement" is a euphemism for "increased pressure". Not
that I'm cynical or anything. (Another possible lesson is that my
interpersonal skills are so bad that I couldn't persuade a starving
man to have a bite to eat.)

>Anyway, I asked him how he would reply to a manager
>who thought that it was a waste. He said (paraphrasing)
>"I'd just ask him if he wants me to solve any of his
>problems. He has solutions for mine, maybe I should
>solve his."

Cute. I'll have to try it some time.

Regards,
Steve Furlong

[Scott P. Duncan]

Steve Furlong wrote:
>
> Programmers variously didn't want others looking over their
> code (or perhaps their methods of coding) or didn't want anyone
> to see how they spent their day.

Lest anyone think I bash management, sales, and marketing too much,
I observe this as one of the biggest impediments to process improve-
ment and improved productivity in development engineering. It is
an historically overwhelming cultural belief that "looking over"
what programmers do is demonstrating mistrust, lack of faith, or
some other disparagement of character. I have never had a manager
actually show any interest in what I did, how I did it, etc. since
my first month or so on my first job in 1972. That is, not until
they felt some discomfort with a project, but then, it was overall
questioning of many people about, not specifics of work patterns
and development practice, but generic competency and schedule
matters.

Oops, sounds like I'm back after managers again. Sorry, all of
them used to be programmers/designers, so they grew up with the
same cultural beliefs. So it is a general belief which I think
finds its way into the criticism of process because process calls
for greater visibility into what is happening, how it is being
done, and to what elevel of quality the activity is being performed.

Watts Humphrey's Personal Software Process (PSP) is, I believe, one
way to specifically attack this problem by making self-measurement
and assessment a part of software engineereing training.

[Mark Johnson]

Steve Furlong wrote:
>
> All or most of the programmers worked in pairs on
> the terminals. They preferred it and it was more productive.
>
> I've suggested trial runs of this technique on three of my jobs. I got
> nothing but resistance, not only from managers but from other
> programmers. Managers wouldn't even give the idea a hearing; I think

> they believed it would lead to too much chit-chat. Programmers

> variously didn't want others looking over their code (or perhaps their
> methods of coding) or didn't want anyone to see how they spent their
> day.

I haven't done this on design or coding, but have used the tandem
technique in debugging problems. It seems to work particularly well
when a very analytical person is paired up with someone who is more
intuitive -- each one would pick things up that the other one missed.

A time or two, we've tried adding a third person, usually for training
purposes. If anything, that seems to slow things down -- if the purpose
is to train the third person on the specific internals of the code being
debugged, it can still be useful.

--
Mark Johnson USnail: Symbios, Inc
E-mail: Mark.J...@symbios.com MetaStor Business Team
Voice: (316) 636-8189 [V+654-8189] 3718 N. Rock Rd.
Visit our web page: http://www.symbios.com Wichita, KS 67226

[Robert C. Martin]

Steve Furlong wrote:
>
> In article <01bd0e3b$e07a1b40$64a7...@feathers.icanect.net>,
> Michael Feathers <feat...@icanect.net> wrote:
> >Funny story. I ran into Kent Beck at OOPSLA and he
> >was demonstrating a technique that he uses called
> >"programming in pairs." The rule is that no one in
> >an organization programs alone. One person is
> >typing and the other hangs back and usually catches
> >things that the other isn't thinking about. It looks
> >like a very good idea. Good for cross-training and
> >two minds do think better than one.
>

> I've suggested trial runs of this technique on three of my jobs. I got
> nothing but resistance, not only from managers but from other
> programmers. Managers wouldn't even give the idea a hearing; I think
> they believed it would lead to too much chit-chat. Programmers
> variously didn't want others looking over their code (or perhaps their
> methods of coding) or didn't want anyone to see how they spent their
> day.

What puzzles me is why anybody would think that they needed a manager's
approval to do this. Actually my complaint is more general than that.
Why do engineers believe that they need management approval when
adopting a change in engineering technique. For example, do you
really need management approval to start using design patterns? How
about informal code reviews? What about programming in pairs, etc, etc.

It seems to me that adopting these techniques is an engineering
perogative, that managers shouldn't even be aware of, much less
give approval to.

[Insiguru]

>But at least, there is some proof that this project went south due
>to the bad scheduling. Will anyone look back on this experience the
>next time and think about whether or not the next deadline should
>be questioned? The industry seems to be filled with the news coming
>too late all the time. Who is it that doesn't want to hear about
>the abundant proof (of something going wrong) that exists?
>

As usual, good points, Scott

However, the proof is in listening to the data. It is hard to ignore data of
your own experiences.

In the organizational learning environments you need three types of data, data
to increase understanding of the development environment, data for managing
software, and data for improving the process.

Data for understanding the environment includes resource distribution
characteristics including cost, effort, duration, computer usage and staff.
Combined with product data in terms of size, components, subsystems and so
forth, valuable questions can be answered. What are the costs, duration, or
effort per single LOC or FP of project X or all projects in the cluster? What
is the effort or schedule distribution per activity including testing for a
cluster of systems.? What are the relationships between size, effort, schedule
and staffing. What is the amount of rework or reuse?

We also need reliability data in terms of activities that inject defects and
how they are found. We need data relative to the number and classes of defects
and changes found in project deliverables. What type and severity of defects
does certain activities inject? How are these defects found and what activity
finds them? How stable or reliable is the system in production and what classes
of defects do we generally find?

We also need qualitative data to help us assess the impact of project
characteristics, management decisions, and special causes on project
performance. Management needs to know the impact of their decisions. Based upon
previous projects, what happens to budget, schedule, quality and functionality
performance when we are given preset deadlines and schedules? What is the
impact when users are uninvolved, when the project manager is inexperienced,
or when the team lack knowledge of the application?

Management data includes planning and estimating, tracking and validation data.
Planning and estimating data provide estimates of cost, schedule, risks,
defects, staffing is generally the same data used for understanding
environment. We can understand the new project by developing quantitative
models based upon similar projects. Similarity says that in the same
organization similar projects will evolve in similar ways. The more similar the
projects the more similar the experiences. The more similar the experiences the
more predictable the quantitative models, and the more successful the project.
Of course, in the CMM tradition a defined process increases similarity.

The estimating models based upon similarity will provide the most accurate
estimates of size, cost, schedule and staffing requirements. In addition,
similarity data will estimate defects and project growth. All projects grow.
Similarity data will help us estimate the growth of requirements, size, cost,
schedule, duration, and staff growth and make contingencies for anticipated
growth. Creeping scope to a degree is natural. What is unnatural is the
inability to deal with it.

The effectiveness of tracking is also a function of the availability of
similarity data and relationships. If the project just tracks task completion
data, then the only available feedback signal is task completion data which may
arrive be too late. With the ability to track and interpret a wide range of
models including change rate, staffing hour, source code or artifact growth,
error rates, artifact change rates, and module change rates, we have a wider
range of tracking capabilities that can help us identify problems before it is
too late.

Validation data allows comparison between the estimates and the actuals. There
is a difference between performing a function and performing a function
effectively. Inaccurate information is worse than not having any information at
all. At least, you know that you lack the information and consider it a risk.
In an organizational learning environment, one of the purposes of the
post-mortem is to rationalize differences between the original estimates and
the actuals. In cases where there are significant variances between project
estimates and actuals, growth, productivity, size, original assumptions and
rationalizations, risks, and other factors are analyzed in order to reconcile
differences between the between the estimates and actuals.

Because improvements objective are organizational-specific, so is the data
requirements. The solution is the ability to measure any type of data. However,
the basis of many process improvement methods is understanding the environment.

Cheers

R.Mathis

[Alan P. Burke]

I've been following the discussion about 'pairing' with amusement and
chagrin. A good friend and I started doing it in the early 1970's,
working on operating system code (OS/360) in assembler. We found that it
helped us tremendously to build correct code. Of course, we had an
incentive to get it right since we could only do a compile-link-go about
once a day, with the "go" part in the nighttime hours. A short while
later we bumped into the "top-down, structured programming revolution"
only to discover that most of us had being doing something like for a
few years.

As to management permisssion, I recall being asked to do a critical
piece involving communications between two 360's across a
channel-to-channel adapter, in about 4 weeks. I agreed. Since it was
critical, I decided to do it right the first time and spent a little
less than three of the weeks analysing, designing and pseudo-coding it
(stuff that 'real' programmers never did then). He asked me then how the
testing was going. I said that I had been doing desk-checking, not
testing and he responded that if I didn't have the code running in a
week, I'd be fired. I assured him that it would be working then and that
it would work the first time I tried it and that it would have no
errors. Since I had already missed a weekend or two of available test
time, all he could do was to emphasize the risk if I failed.

That weekend, I assembled the code, for the first time, without errors.
I linked it without errors. It ran with only one failure, caused by an
undocumented timing problem with the adapter. I corrected the flaw in
about two days.

The software was installed into production on the following weekend and
never failed. Another colleague picked up my code about 6 months later
with a mandate to generalize it for multiple (>2) processors. He did it
in very quick time and thanked me for having written the code in a way
that was generalizable (no accident). Not one did I ask my manager for
permission. But I didn't change my approach from that point on.

Contrition is easier than permission.

Merry Christmas and Happy New Year,
Alan

[Jeff Miller]

fur...@alumni.rpi.edu (Steve Furlong) writes:

[---snip---]

>The biggest lesson that I took from this is that even in organizations
>which claim that their productivity is too low and that they need to
>"do something" to bring it up, no one is willing to try anything
>new.

This is exactly right. Organizations work their way into a comfort
zone, and it is exceptionally difficult to get them out of that
zone. One such zone that I find particularly frustrating is the
"we-know-our-development-process-is-lousy,-but-we-take-such-comfort
in-griping-about-it-we-never-take-real-steps-to-improve" trap.
Because of this, it is often easier to promulgate process change
in organizations that do not have a culture of griping about process
problems.

>I guess management just wanted programmers to work longer hours,

One of the few things that managers can do that results in a visible
change in a short period of time is to exhort developers to 'step
up to the challenge' and 'work harder'. My experience is that such
actions are counter-productive over any but the shortest periods of
time, but most managers view things differently. For most development
organizations, output (by whatever measure) is randomized over a
fairly broad range. When managers push the 'do work' button, they
are conditioned to expect results within this range, which is to say
they are conditioned to expect just about anything. Thus, they learn
that the one thing they can do that has a visible effect is the
exhortation strategy.

>and "process improvement" is a euphemism for "increased pressure".

We run into this daily. When we tell an organization that we can help
them reduce their product cycletime, it is scary how often they
think that means showing them new ways to motivate employees to work
harder and longer. The reality is that organizations that understand
the dynamics of rational process improvement directed toward reduced
development cycletimes also find that their employees are working at
a much more sustainable pace.

Jeff Miller
Terrapin Technologies, Inc.
jmi...@cycletime.com
http://www.cycletime.com

[Jonathan Gossage]

Tim Ottinger wrote in message >

>I wasn't the first to suggest this, but rather a few years
>ago (like maybe 7) I had started talking about this. I had
>some friends on my programming team, and when we worked
>together we got not only better designs, but quicker as
>well. We could take on two jobs, do them serially or
>alternate incrementally between them, and really crank it
>out.
>
>Every time I've mentioned this to a manager I was told that
>I was making it up, it couldn't possibly be more productive
>than having two people working independently (because of
>unproductive "conversation": apparently considered to be
>a cause of most lost productivity). The idea was rejected
>with a religious ferver.

I have found you get the best results with this kind of technique where both
parties are seasoned practitioners with personalities that are stable enough
to not let ego get in the way of reality. Given the right people, though you
can get remarkable productivity.

I know because I have been involved with situations like this a number of
times and am fortunate enough to be working in this environment now. But if
the personalities and levels of technical competance don't fit it can easily
become an absolute disaster. I doubt that the technique can be legislated;
serendipity seems to be involved.

Jonathan Gossage

jgos...@cyberua.ca

[Thaddeus L. Olczyk]

On Mon, 22 Dec 1997 09:43:05 -0600, "Robert C. Martin"
<rma...@oma.com> wrote:

>Steve Furlong wrote:
>> I've suggested trial runs of this technique on three of my jobs. I got
>> nothing but resistance, not only from managers but from other
>> programmers. Managers wouldn't even give the idea a hearing; I think
>> they believed it would lead to too much chit-chat. Programmers
>> variously didn't want others looking over their code (or perhaps their
>> methods of coding) or didn't want anyone to see how they spent their
>> day.
>

>What puzzles me is why anybody would think that they needed a manager's
>approval to do this.

The way I understood it Steve was forbidden by management wehen he
brought it up, not just denied approval.

As for approval, I suspect that Steve brought it up so that a trial
could be tried. If the trial was successful, then it could be applied
in a larger part of the company, then Steve could ever influence.

As for why anyone would believe they need a managers approval.
Well some managers imply it heavily. They go around with an air of
"Them there coders. They ain't good fer anything but writing in their
newfangled C++ language. Well, they may know C++, but they don't
know how to build SYSTEMS. I have to make all the real important
decisions. Nope can't trust them to do it."

I've known a couple of managers like that. One manager had projected
it onto a developer who had more experience then he did."
------------------------------------
Thaddeus L. Olczyk

[Thaddeus L. Olczyk]

On 22 Dec 1997 08:00:40 -0500, fur...@alumni.rpi.edu (Steve Furlong)
wrote:

>The biggest lesson that I took from this is that even in organizations
>which claim that their productivity is too low and that they need to
>"do something" to bring it up, no one is willing to try anything

>new. I guess management just wanted programmers to work longer hours,
>and "process improvement" is a euphemism for "increased pressure". Not
>that I'm cynical or anything. (Another possible lesson is that my
>interpersonal skills are so bad that I couldn't persuade a starving
>man to have a bite to eat.)
>

Tom Demarco once wrote an article entitled
"Why Does Software Cost So Much?".
His conclusion: software is really dirt cheap.
Claiming that softwaree is to expensive is
management's way of making the programmer feel guilty,
so that they can extort more hours out of him.
-----------------------------
Thaddeus L. Olczyk

[Scott P. Duncan]

Insiguru wrote:
>
> As usual, good points, Scott

Thanks...and your summary of types of data was a helpful
classification.

> However, the proof is in listening to the data.

True...there just seems to be plenty of it regarding projects
schedule problems, cost overruns, and quality issues. The ori-
gional post seemed to suggest people were waiting for the proof
of these things before resisting unreasonmable schedules. I seem
to think there is plenty out there.

> The estimating models based upon similarity will provide the
> most accurate estimates of size, cost, schedule and staffing
> requirements.

Tom DeMarco in _Controlling_Software_Projects_ suggests people do
not have to estimate many projects in their career, so do not get
good at it. I also tend to think people feel projects are not
enough like one another to take any advantage of the last one's
data in any formal sense. However, I think estimation by analogy
(even when performed bottom-up) is the most common method which
says people will use experience in that way. Unfortunately, many
estimation gurus feel this is the least reliable estimation approach
to take, not because there is no comparison between projects, but
because the differences do not get factored in after the basic com-
parisons of similarities are used to estimate.

Again, I think it is better risk management as much as pure estima-
tion which is the culprit.

[Michael C. Feathers]

Tim Ottinger <tott...@oma.com> wrote in article
<349DCDD9...@oma.com>...

> > Funny story. I ran into Kent Beck at OOPSLA and he
> > was demonstrating a technique that he uses called
> > "programming in pairs." The rule is that no one in
> > an organization programs alone. One person is
> > typing and the other hangs back and usually catches
> > things that the other isn't thinking about. It looks
> > like a very good idea. Good for cross-training and
> > two minds do think better than one.
>

> Every time I've mentioned this to a manager I was told that
> I was making it up, it couldn't possibly be more productive
> than having two people working independently (because of
> unproductive "conversation": apparently considered to be
> a cause of most lost productivity). The idea was rejected
> with a religious ferver.
>

> I'm interested in the idea that Kent Beck is having success
> I wonder what the context is for such an idea to be accepted.

I think that there is something more general here.
In some other subthread of this "real projects" thread
I was replying to someone who feels that marketing
should have ultimate authority over development.
I pointed out that this causes much grief and a better
model would be to have groups with a marketing lead,
an administrative lead, and a technical lead all
with coequal authority.

What does this have to do with programming in pairs?
Well for the "management" scenario above, I pointed out
that coequal authority only works when upper management
really treats those three people as "one person." This
means that they succeed or fail as a team and there
can be no politicking between among the coequal leads.
The benefit is that the leads have to cooperate or fail.
In addition, the organization gets the benefit of a
small group of people who have goals in concert
and are more intelligent together than they are
individually.

Where I work, I for a long while had two bosses who
cooperated on everything by choice. They were
a very powerful duo. Closer to me, I have a coworker
with whom I share responsibility for a project. This
has been so for the past two years. It has been
a very positive experience.

I think that there is a very powerful organizational
pattern here, where organizations effectively treat
small groups of more than one person as
a single "person."

[Insiguru]

>Tom DeMarco in _Controlling_Software_Projects_ suggests people do
>not have to estimate many projects in their career, so do not get
>good at it. I also tend to think people feel projects are not
>enough like one another to take any advantage of the last one's
>data in any formal sense. However, I think estimation by analogy
>(even when performed bottom-up) is the most common method which
>says people will use experience in that way. Unfortunately, many
>estimation gurus feel this is the least reliable estimation approach
>to take, not because there is no comparison between projects, but
>because the differences do not get factored in after the basic com-
>parisons of similarities are used to estimate.
>
>Again, I think it is better risk management as much as pure estima-
>tion which is the culprit.
>
>

My Guru are your Gurus?

The Airlie software council sure expressed a different opinion in August's 1996
issue of CrossTalk The Airlie Software Council members include Vic Basili,
Grady Booch, Norm Brown, Christine Davis, Tom Demarco, Mike Dyer, Mike Evans,
Casper Jones, Tim Lister, John Manzo, Lou Mazzuchelli, Tom McCabe, Frank
McGrath, Roger Pressman, Larry Putnam, Howard Rubin, and Ed Yourdon.

The council developed nine principal practices for software management.
Practice number four was metric-based scheduling and management. The essential
element of metric-based scheduling and management is that to estimate cost and
schedule by using similar completed projects. Then they said to compare the
results to software cost models. After all, Rubin, Putnam, and Jones are
members of the council. In regard to project tracking, they said that project
management metrics should measure actual progress against the project baseline
plan, they warn of potential problems, and help localize problems.

Boeing STS, considered one of the most successful software organizations in the
country and NASA SEL and Raytheon, first and second winners of annual IEEE
Computer Society Software Process Achievement Award, also rely on similar
projects for estimating purposes.

"When I want to estimate new work, I take a trip to our software library to
check the procedure and to find metrics for similar work done in the past. This
facilitates realistic schedules, better planning, labor forecasting and more
efficient lab usage". Kimsey Fowler, Boeing STS in July's issue of CrossTalk

In the list of nine best practices from the Airlie software council, formal
risk management is best practice number 1. However, I think it was Ed Yourdon
who said something like if your initial estimates are off, nothing else you do
matters.

[Bert Bril]

Michael C. Feathers wrote:
> Well for the "management" scenario above, I pointed out
> that coequal authority only works when upper management
> really treats those three people as "one person." This
> means that they succeed or fail as a team and there
> can be no politicking between among the coequal leads.
> The benefit is that the leads have to cooperate or fail.
> In addition, the organization gets the benefit of a
> small group of people who have goals in concert
> and are more intelligent together than they are
> individually.

What you are suggesting seems extremely dangerous to me. What if things go a bit
worse than perfect? I have seen many projects fail because responsibilities were
shared. In many environments this means that nobody can be blamed, and everyone
takes the credit.

What you propose may work nicely in a perfect world with highly motivated people
sharing a common goal. But I am very skeptical. People that seem to be on the
right side stop being your friend when their [censored] is getting burned. Or
good people turn out to be much sloppier/too precise, prepared to take much
more/less risks, etc. This is all well and nice when there are no serious
problems.

Don't misunderstand me: I think we should work towards a situation where
everybody contributes to a common goal, where people constantly monitor whether
they are still doing the things in harmony with that goal. But working in many
environments from small to very large scale companies have made me fear the
worst.

> I was replying to someone who feels that marketing
> should have ultimate authority over development.

I interpret the above quote to indicate that you disagree. But in the context of
a company selling software (we do that, but it is probably not even the majority
of the cases) this fact is just undeniable.

Companies try to survive because they must generate a return of investment. To
do that, profit must be generated. The mentioned companies do that by selling
software and possibly some related services and goods (support, courses,
specific hardware, etc.). Software development _may_ help the marketing people
to make more money. If so, still _they_ are the ones that are dependent.

This issue must be separated from the communication issue, which is all about
getting information across from marketing to development and vice versa. No
doubt the 'vice versa' can be extremely important. And also, it can be in
marketing's advantage if development gets a degree of independence for e.g.
autonomous R&D, re-use projects, whatever. But that should be decided by
marketing. In a way, development is part of the larger marketing department.

Software development in these companies is part of the marketing strategy. Just
like designing a new box for the manuals, planning more ads, etc. Definitely
'marketing should have ultimate authority over development'.

Bert

-- de Groot - Bril Earth Sciences B.V.
-- Boulevard 1945 - 24, 7511 AE Enschede, The Netherlands
-- mailto:be...@dgb.nl , http://www.dgb.nl
-- Tel: +31 534315155 , Fax: +31 534315104

[Scott P. Duncan]

Insiguru wrote:
>
> My Guru are your Gurus?

Same ones. As a group opinion, the results are somewhat different than
when you talk to some of them individually. They would NEVER argue that
you should not use past project data. And, as you point out, they will
recommend you

> estimate cost and schedule by using similar completed projects. Then
> they said to compare the results to software cost models.

And where does the data come from to "tune" the models? Past projects,
to
be sure. But the data to use as input to the models for the current
project comes from some source other than just picking the "average" of
past projects. That's, in fact, what the models due with historical
databases. Most gurus do recommend some sizing factor be computed (FPs
for most folks these days) and then a series of answers to their ques-
tionnaires (not all of which will be exactly like the last project).

> Boeing STS...and NASA SEL and Raytheon...also rely on similar
> projects for estimating purposes.

Again, I believe you'll find they use databases of past projects. This
is
not estimation by analogy as I understand it. The latter is taking a
past
project, that is as close to the one you expect to do this time, and
more or
less adopting that project's profile as the one you propose for the new
project. No other major checks and balances. And the data on the past
project is usually fairly thin -- nothing approaching real past
histories.

Most people I know who have developed any reasonable estimation approach
do
not follow this pattern. But this approach is often used by folks who
do
not devote much effort to keeping past project histories -- lots of IT
shops are like this. Organizations who have collected significant years
of data and use it for estimation modeling are way beyond analogy
estima-
tion.

Dr. Tarek Abdu'l-Hamid has done some research on project management
behavior
in project estimation and argues against analogy estimates. He has been
using a systems dynamics approach to test people's estimation ability
and
comments that analogy leads people the most astray. (Again, analogy is
tak-
ing ONE past project, not data from many projects and using a formal
esti-
mation approach with a model for sanity checking. Perhaps, in this
forum,
it seems unthinkable to do this and it is clearly not what Airlie folks
were doing, but, where a real data collection effect has not existed to
track past projects, remembering one "like" the new one is what most
folks
have available to them.

> I think it was Ed Yourdon who said something like if your initial
> estimates are off, nothing else you do matters.

I think the risk management effort is part of coming up with the better
estimate. Once you get by sizing a project, many of the other factors
employed by estimation tools have to do with "risk" elements. One such
topic is how much new technology is being employed on the new project.
This actually gets asked several times in some questionnaire sets with
the language, computing environment, domain, etc. are all separately
queried for uniqueness.

[Stan Rifkin]

Scott P. Duncan (soft...@mindspring.com) wrote:
: Insiguru wrote:
[...]
: > I think it was Ed Yourdon who said something like if your initial

: > estimates are off, nothing else you do matters.

[...]

NOT! Tarek Abdel-Hamid and his students at the Naval Postgraduate
School published (or tried to publish! I have the draft submitted for
publication) the results of an experiment in 1992 that reproduced the
well-known work of Kahneman & Tversky on decision-making under
uncertainty. K&T have found that given a bad starting point we ALL
treat that first information as an anchor, never really giving it up,
even though (a) we had not particularly objective basis for it in the
first place, and (b) it can be overwhelmed with later, contrary
data. One thought is that this is the genesis of prejudice (=
pre-judgment).

Abdel-Hamid gave software project managers an incorrect picture (say,
scope) of a project, asked for an estimate, and then gave the project
managers accurate information from then on. As predicted by Kahneman &
Tversky, the software project managers were never able to overcome
their initial misinformation.

- Stan Rifkin

[Paul E. Bennett]

In article <67lo9o$19...@alumni.rpi.edu>
fur...@alumni.rpi.edu "Steve Furlong" writes:

> In article <01bd0e3b$e07a1b40$64a7...@feathers.icanect.net>,
> Michael Feathers <feat...@icanect.net> wrote:

> >Funny story. I ran into Kent Beck at OOPSLA and he
> >was demonstrating a technique that he uses called
> >"programming in pairs." The rule is that no one in
> >an organization programs alone. One person is
> >typing and the other hangs back and usually catches
> >things that the other isn't thinking about. It looks
> >like a very good idea. Good for cross-training and
> >two minds do think better than one.
>

> Five or six years ago (IIRC) in Computer Language magazine, Larry
> Constantine (IIRC) talked about a visit to PJ Plauger's company,

> Whitesmiths (IIRC). All or most of the programmers worked in pairs on

> the terminals. They preferred it and it was more productive.
>

> I've suggested trial runs of this technique on three of my jobs. I got
> nothing but resistance, not only from managers but from other
> programmers. Managers wouldn't even give the idea a hearing; I think
> they believed it would lead to too much chit-chat. Programmers
> variously didn't want others looking over their code (or perhaps their
> methods of coding) or didn't want anyone to see how they spent their
> day.

One wonders at the way Technical Reviews are conducted in the company or
whether they are conducted at all.

> The biggest lesson that I took from this is that even in organizations
> which claim that their productivity is too low and that they need to
> "do something" to bring it up, no one is willing to try anything
> new. I guess management just wanted programmers to work longer hours,
> and "process improvement" is a euphemism for "increased pressure". Not
> that I'm cynical or anything. (Another possible lesson is that my
> interpersonal skills are so bad that I couldn't persuade a starving
> man to have a bite to eat.)

In "The Handbook of Walkthroughs, Inspections, and Technical Reviews:
Evaluating Programs, Projects, and Products." by Freedman and Weinbverg,
the lesson seems to be that the reviews actually help to improve the
cohesiveness of the team and improve techniques through ongoing cross
fertilisation of ideas. It is often cheaper than educational seminars.

--
Paul E. Bennett ................... <p...@transcontech.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861 <enq...@transcontech.co.uk>
Going Forth Safely

[Charles Martin]

Paul E. Bennett wrote:
>
> In article <67lo9o$19...@alumni.rpi.edu>
> fur...@alumni.rpi.edu "Steve Furlong" writes:
>
> > In article <01bd0e3b$e07a1b40$64a7...@feathers.icanect.net>,
> > Michael Feathers <feat...@icanect.net> wrote:
> > >Funny story. I ran into Kent Beck at OOPSLA and he
> > >was demonstrating a technique that he uses called
> > >"programming in pairs." The rule is that no one in
> > >an organization programs alone. One person is
> > >typing and the other hangs back and usually catches
> > >things that the other isn't thinking about. It looks
> > >like a very good idea. Good for cross-training and
> > >two minds do think better than one.
> >
> > Five or six years ago (IIRC) in Computer Language magazine, Larry
> > Constantine (IIRC) talked about a visit to PJ Plauger's company,
> > Whitesmiths (IIRC). All or most of the programmers worked in pairs on
> > the terminals. They preferred it and it was more productive.
> >
> > I've suggested trial runs of this technique on three of my jobs. I got
> > nothing but resistance, not only from managers but from other
> > programmers. Managers wouldn't even give the idea a hearing; I think
> > they believed it would lead to too much chit-chat. Programmers
> > variously didn't want others looking over their code (or perhaps their
> > methods of coding) or didn't want anyone to see how they spent their
> > day.

I used to teach for Learning Tree, and the hands-on courses were almost
always done this way. However, if the class wasn't so full that every
computer was used, there would always be one person -- nearly invariably
a male, and nearly invariably one who had all the usual marks of geekdom
-- who ABSOLUTELY would not sit with someone else, no matter how
carefully I explained that they would get the topic faster if theyr
worked in pairs. They were also often the ones who I was spending a lot
of face-time with by the third day of the class because they were
havcing troubles.

>
> One wonders at the way Technical Reviews are conducted in the company or
> whether they are conducted at all.

Likely aren't. Just because they're the most cost-effective way of
improving quality short of formal methods doesn't mean people want to
use them.

>
> > The biggest lesson that I took from this is that even in organizations
> > which claim that their productivity is too low and that they need to
> > "do something" to bring it up, no one is willing to try anything
> > new. I guess management just wanted programmers to work longer hours,
> > and "process improvement" is a euphemism for "increased pressure". Not
> > that I'm cynical or anything. (Another possible lesson is that my
> > interpersonal skills are so bad that I couldn't persuade a starving
> > man to have a bite to eat.)

It's not just you, then. In fact, I tell my consulting clients about my
"Twelve Step Theory of Consulting". Step One: The Company must be
convinced that it has to change or die. But it's not management --
management pressure is often unable to introduce new methods against the
inertia of the organization. Anyone who has been watching Lou Gerstner
trying to change IBM can attest to that.

[Scott P. Duncan]

Stan Rifkin wrote:
>
> NOT! Tarek Abdel-Hamid and his students at the Naval Postgraduate
> School published (or tried to publish! I have the draft submitted for
> publication) the results of an experiment in 1992 that reproduced the
> well-known work of Kahneman & Tversky on decision-making under
> uncertainty.

Hi Stan... Yes, this is the work I was referring to in
discussing "analogy" in estimation. Not sure I ever saw
it in print, but Tarek spoke about it often. I know he
did as part of his keynote talk at one of the Applications
of Software Measurement conferences. It was the one a few
years ago in San Diego, but I forget if it was '95 or '96.
I'm not sure that anything made it into the proceedings,
though.

> Abdel-Hamid gave software project managers an incorrect
> picture (say, scope) of a project, asked for an estimate,
> and then gave the project managers accurate information
> from then on.

In his talk, one of the things he specifically discussed was
giving managers a prior project's data (which was similar to
the project they were working with) and asking them to estimate
based on this "analogous" situation. He noted behavior that
almost always tended to result in missed schedule/resources
and advocated "stretch goals". He discussed giving the client
one estimate, but giving development a more constrained one.
Like it or not, his feeling seemed to be that behavior always
indicated exceeding development estimates, especially those
created through analogy.

> software project managers were never able to overcome
> their initial misinformation.

As I recall, there were some other interesting results as well
which involved giving people higher and lower estimates of the
project behavior they would see. Those with the lower estimates
would invariably move up to meet behavior being demonstrated
in the project. Those with a higher estimate were reluctant to
move down to the behavior much, preferring to stick with the
longer schedule and higher resources. Thus, if you "cushion"
the estimate to start with, the likelihood that people will
work/manage to do better is far less than people's willingness
to increase the esxtimate to meet te behavior they see.

This was the basis for Tarek's feeling that aggressive goals for
development were wiser practice. But it did seem to me that he
was NOT advocating setting unrealistic goals. His point was to
have a realistic estimate for the customer and to see if you could
drive development to perform at a higher level of productivity
by giving them challenging goals.

Anybody familiar with (and interested in discussing) the
Abdel-Hamid and Madnick book on Software Project Dynamics
which discusses systems dynamics modeling of software projects?
I have some experience using the model on real projects and am
interested in discussion with others who also have used it or
other such models?

[Russell Wallace]

Paul E. Bennett wrote:
>
> In article <67lo9o$19...@alumni.rpi.edu>
> fur...@alumni.rpi.edu "Steve Furlong" writes:
> > Five or six years ago (IIRC) in Computer Language magazine, Larry
> > Constantine (IIRC) talked about a visit to PJ Plauger's company,
> > Whitesmiths (IIRC). All or most of the programmers worked in pairs on
> > the terminals. They preferred it and it was more productive.
> >
> > I've suggested trial runs of this technique on three of my jobs. I got
> > nothing but resistance, not only from managers but from other
> > programmers. Managers wouldn't even give the idea a hearing; I think
> > they believed it would lead to too much chit-chat. Programmers
> > variously didn't want others looking over their code (or perhaps their
> > methods of coding) or didn't want anyone to see how they spent their
> > day.

Personally I would strongly dislike this technique.

> One wonders at the way Technical Reviews are conducted in the company or
> whether they are conducted at all.

People can have valid reasons for disliking a proposed technique other
than laziness or inertia. I'm all in favor of having someone else
review my code after it's written, but I'd find having someone staring
at me all day while I'm trying to work extremely annoying and
distracting.

You also have an efficiency cut of potentially a factor of two from
having two people full-time doing the work of one. For some people, the
gains might outweigh this loss (particularly in a place which otherwise
has very poor standards and no concept of code reviews). For others it
might not.

Don't assume that because a solution works for you it has to be a
universal panacea for everyone.

--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mano...@iol.ie

[Charles Martin]

See, this is just the kind of response I got in the Learning Tree
classes. Russell, if this meant you had sort of a flash-and-bllod Big
Brother always giving you the fisheye, silently judging you, I can see
how it might give you a programmer's block big-time. But what we're
talking about is working with a peer and engageing in a dialogue about
the way the program is coming together.

[Bill Dugan]

On Sun, 04 Jan 1998 10:28:27 -0500, Charles Martin
<crma...@connix.com> wrote:

>Russell Wallace wrote:

snip

>> People can have valid reasons for disliking a proposed technique other
>> than laziness or inertia. I'm all in favor of having someone else
>> review my code after it's written, but I'd find having someone staring
>> at me all day while I'm trying to work extremely annoying and
>> distracting.
>>
>> You also have an efficiency cut of potentially a factor of two from
>> having two people full-time doing the work of one. For some people, the
>> gains might outweigh this loss (particularly in a place which otherwise
>> has very poor standards and no concept of code reviews). For others it
>> might not.
>
>See, this is just the kind of response I got in the Learning Tree
>classes. Russell, if this meant you had sort of a flash-and-bllod Big
>Brother always giving you the fisheye, silently judging you, I can see
>how it might give you a programmer's block big-time. But what we're
>talking about is working with a peer and engageing in a dialogue about
>the way the program is coming together.

Which is still something likely to work for some people and not for
others. We tend to think that our own experience with solo vs. team
activity, or diagrams vs. text, etc., must apply to everyone. That
isn't always true. We need to learn from each others experience, but
we can't always assume that what works for one will work for all.

[Thaddeus L. Olczyk]

On Sun, 04 Jan 1998 14:28:59 -0800, Russell Wallace <mano...@iol.ie>
wrote:

>You also have an efficiency cut of potentially a factor of two from
>having two people full-time doing the work of one. For some people, the
>gains might outweigh this loss (particularly in a place which otherwise
>has very poor standards and no concept of code reviews). For others it
>might not.
>

Sounds like you've never reviewed code. Reviewing code should always
take as much time as writing it. You not only have to replicate
functionality, you have to figure out the logic of the other
programer. So you waste the time the programmer could spend coding,
and you save the time that would go into a review.

----------------------------
Thaddeus L. Olczyk
(to reply send to interaccess.com instead of
underaccess.com)

[Dan Drake]

This is a very interesting discussion, which reflects a lot of what I've
seen actually happening in projects. My question is, has anyone worked
with a model in which slack time is explicit?

I mean, the CPM chart for the project, or whatever tool you use, is
based on the assumption that each piece will go well, without any
unexpected problems. This patently false assumption is balanced by a
definite budget of extra time for the nasty things that crop up, or crap
up. ("Once again the Russians have crapped up in the news" as an
announcer once read.) The project manager doles that time out with
great care.

Sure, I can see that this is hard to manage--but what else is new? It
involves a truly radical management techinique: try to be honest with
the programmers. They are to know that they _are_ to make these
subproject schedules, and there _is_ an allowance for problems when they
come up. Anybody ever tried to work this out in practice?

--
Dan Drake
d...@dandrake.com
http://www.dandrake.com/index.html

Many things are not seen in their true nature and as they really are,
unless they are seen as beautiful. Behavior is not intelligible, does
not account for itself to the mind, and show the reason for its
existing, unless it is beautiful.
--Matthew Arnold

[Dave Vance]

Dan Drake wrote:
>
> This is a very interesting discussion, which reflects a lot of what I've
> seen actually happening in projects. My question is, has anyone worked
> with a model in which slack time is explicit?
>
> I mean, the CPM chart for the project, or whatever tool you use, is
> based on the assumption that each piece will go well, without any
> unexpected problems. This patently false assumption is balanced by a
> definite budget of extra time for the nasty things that crop up, or crap
> up. ("Once again the Russians have crapped up in the news" as an
> announcer once read.) The project manager doles that time out with
> great care.
>
> Sure, I can see that this is hard to manage--but what else is new? It
> involves a truly radical management techinique: try to be honest with
> the programmers. They are to know that they _are_ to make these
> subproject schedules, and there _is_ an allowance for problems when they
> come up. Anybody ever tried to work this out in practice?
>

I've been on several projects that have done this, usually large
projects of 100-300 people spanning several years. My last project
worked this way (simplified, of course :-)!): The technical teams'
combined estimated schedule came to a 14 month effort; I told the
customer 16 months (and yes, I told them I was adding 2 months'
contingency! My answer to their objections was it was necessary to
manage the risks, and we finally agreed on it). The individual
department managers then took about 15% off their department schedules
and that was the schedule their people worked to. The 15% contingency
was the department manager's to give up when his/her folks encountered
"bumps in the road"; the 2 months were mine to give up when there were
problems outside of their control. Just slipping schedule was NOT a
good enough reason to get contingency time! If you were slipping your
_earlier_ schedule, you had to put recovery plans in place to get back
to it.

It IS difficult to manage; one of the hardest choices is how do you
represent the "true" schedule, since you have to manage to the 14 months
- 15%, in this case. I had one set of schedule charts I managed to and
another set I showed the customer. But it was all open and
above-board. If anyone cares, we came in on the 14 month milestone, and
worked a heck of a lot of overtime to do it! I did have to give up some
of the contingency I held, but we made up for it with recovery plans.

On this project we had performance-related bonuses for all key people
(which most of the programmers were) tied to customer satisfaction,
which went up if we delivered early. So people were rewarded for making
the quicker schedule. But I've seen it work without that before. You
always get doubters and grumblers, but you'd get that if you only have
one schedule too.

- Dave -

[Paul E. Bennett]

In article <34afc695...@nntp.ix.netcom.com>
wkd...@ix.netcom.com "Bill Dugan" writes:

> >> People can have valid reasons for disliking a proposed technique other
> >> than laziness or inertia. I'm all in favor of having someone else
> >> review my code after it's written, but I'd find having someone staring
> >> at me all day while I'm trying to work extremely annoying and
> >> distracting.
> >>

> >> You also have an efficiency cut of potentially a factor of two from
> >> having two people full-time doing the work of one. For some people, the
> >> gains might outweigh this loss (particularly in a place which otherwise
> >> has very poor standards and no concept of code reviews). For others it
> >> might not.
> >

> >See, this is just the kind of response I got in the Learning Tree
> >classes. Russell, if this meant you had sort of a flash-and-bllod Big
> >Brother always giving you the fisheye, silently judging you, I can see
> >how it might give you a programmer's block big-time. But what we're
> >talking about is working with a peer and engageing in a dialogue about
> >the way the program is coming together.
>
> Which is still something likely to work for some people and not for
> others. We tend to think that our own experience with solo vs. team
> activity, or diagrams vs. text, etc., must apply to everyone. That
> isn't always true. We need to learn from each others experience, but
> we can't always assume that what works for one will work for all.

There are degrees of cooperation involved. The first thing that will
help an organisation with problems is conducting more frequent reviews.
Working closely with peers does not necessarily mean a one PC between
two arrangement but more time spent talking through the difficult bits.
The really easy bits will fall into place once you have sorted the
strategy for evolving a system structure. Technical reviews help on
many different levels from informal to fully formal.

I reccommend that you all read the Freedman and Weinberg book on the
subject as this gives a clear indication of where the real improvements
in productivity and quality can spring out of properly conducted reviews.

At the end of the job you may find you have enough of an audit trail to be
able to certify the quality or integrity of your product in quite objective
terms (though that is not a promise of Freedman and Weinberg).

In any engineering effort, having a good sound process, appropriate
analysis effort and careful consideration of the design at every stage
will bring about real benefits to a development organisation.

ref: "Handbook of Walkthroughs, Inspections, and Technical Reviews;
Evaluating Programs, Projects and Products." by Daniel P. Freedman
and Gerald M. Weinberg, published by Dorset House Publishing,
ISBN 0-932633-19-6.

[Frank A. Adrian]

Dave Vance wrote in message <34B14E...@vnet.ibm.com>...
>[After much chest pounding about a project that "worked"]

>If anyone cares, we came in on the 14 month milestone, and

>worked a heck of a lot of overtime to do it.

But then doesn't the fact that you forced your people to work "a heck of
a lot of" overtime mean that your initial estimates were crap, anyway? Or
have we all bought into the current industry viewpoint that if you (and
your people) aren't working "a heck of a lot of overtime", you aren't
working hard enough.

I hope not. That way lies revolution...
--
Frank A. Adrian
First DataBank
frank_...@firstdatabank.com (W)
fra...@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.

[Dave Vance]

Frank A. Adrian wrote:
>
> But then doesn't the fact that you forced your people to work "a heck of
> a lot of" overtime mean that your initial estimates were crap, anyway?

You're jumping to a few conclusions. Leaving aside that you don't
know what my definition of "a heck of a lot" is, the implication that
the overtime was worked at gunpoint isn't true. Given the bonus
incentives, teams managed their own overtime to get the job done. We
would actually have made a 16 1/2 month schedule if we had just spent
contingency; which means I slightly underestimated. No one would have
been fired if we had done that. The overtime was because people wanted
the extra money.

Our initial estimates were definitely *not* crap, they were as good as
they could be. Anyone whose initial estimates are perfect is either
psychic or on too simple a project. Reality (at least mine) is that
even a road that you can see perfectly in front of you will have rocks
that fall down on it and work crews that will appear to move its path.
You can plan for those, but you'll never know until it's over whether
you've planned enough or not. Initial estimates are *always*
approximations of reality.

Yes, the initial 14 month estimate didn't have enough contingency.
That's why I went with a 16 month one - because that estimate was more
realistic. The original point of the example was that you *manage* to
the 14 month schedule, and you give up contingency as you need to when
things pop up. I'm sorry that the bonus stuff confused the issue.

> Or
> have we all bought into the current industry viewpoint that if you (and
> your people) aren't working "a heck of a lot of overtime", you aren't
> working hard enough.
>

Definitely not. I'll spare you my view of how overtime should be
used, but it's not that. Besides, it's not that simple. Some people on
this last project worked *way* too hard, and some people were there for
lots of extra hours and I can't say they were really working!

- Dave -

[Charles Martin]

Dan Drake wrote:
>
> This is a very interesting discussion, which reflects a lot of what I've
> seen actually happening in projects. My question is, has anyone worked
> with a model in which slack time is explicit?
>
> I mean, the CPM chart for the project, or whatever tool you use, is
> based on the assumption that each piece will go well, without any
> unexpected problems. This patently false assumption is balanced by a
> definite budget of extra time for the nasty things that crop up, or crap
> up. ("Once again the Russians have crapped up in the news" as an
> announcer once read.) The project manager doles that time out with
> great care.

Uh, no, actually the ream critical path method gives each node a median
duration and a variance (the assumption is that durations are normal-
distribution, but it's an easy extension to do something else. The
thing
is, normal distribution is so nicely additive....) This means that real
CPM DOES account for the unexpected.

Now, getting the data to assign the *variance* -- that's a WHOLE 'nother
problem.

[Marc Girod]

I like and practice this technique at times --not systematically
though. IMHO It is especially suited for debugging sessions, but can
be used in many other situations. It works better with some pairs than
with others. To be fruitful, it ought not be the same one at the
keyboard --although why? I could even imagine that some pairs could
just work like that!.

In fact, it is some kind of "process review".

I have always wondered how work the few pairs of (literature) writers
there are: Boileau-Narcejac, the Strugatski brothers...

--
Marc Girod Nokia Telecommunications INS/IPS/MS/NOMA
Valimo 1/2 P.O. Box 315 Phone: +358-9-511 63331
00380 Helsinki 00045 NOKIA Group Fax: +358-9-511 63310
Finland marc....@ntc.nokia.com

[Russell Wallace]

Charles Martin wrote:

>
> Russell Wallace wrote:
> > People can have valid reasons for disliking a proposed technique other
> > than laziness or inertia. I'm all in favor of having someone else
> > review my code after it's written, but I'd find having someone staring
> > at me all day while I'm trying to work extremely annoying and
> > distracting.
>

> See, this is just the kind of response I got in the Learning Tree
> classes. Russell, if this meant you had sort of a flash-and-bllod Big
> Brother always giving you the fisheye, silently judging you, I can see
> how it might give you a programmer's block big-time. But what we're
> talking about is working with a peer and engageing in a dialogue about
> the way the program is coming together.

Actually, I think that's a better technique in class. When doing
development, however, by the time I'm sitting down in front of my
machine I already have a pretty clear idea of what I'm doing. (If I
haven't, I shouldn't be sitting down in front of the machine yet.) The
thing then is to get on with actually doing it. Later, there'll be
reviews aimed at establishing whether I've done it correctly or not, and
if not, how to fix it; but they're two different processes, and with the
proposed system I'd find myself spending most of my time and effort
switching back and forth between them with very little to spare to do
either one of them well. In class most of the time there aren't any
large, solid blocks of development to be done, so one can pretty much
stay in dialogue mode, which works better.

[Dan Drake]

On Tue, 6 Jan 1998 11:50:07, Charles Martin <crma...@connix.com> wrote:

+...
+
+ Uh, no, actually the ream critical path method gives each node a median
+ duration and a variance (the assumption is that durations are normal-
+ distribution, but it's an easy extension to do something else. The
+ thing
+ is, normal distribution is so nicely additive....) This means that real
+ CPM DOES account for the unexpected.
+

One of us has the terminology wrong, and I admit that it's not wholly
impossible that I'm the one.

CPM (Critical Path Method), as I learned it, finds the rate-limiting
steps where the duration of each step is known.
PERT (Project Evaluation Rsomething Tsomething -- Research Technique??)
uses the mean and variance thing.

To confuse matters further, people in the computer business seem
constantly to refer to their CPM charts as Pert charts. It would be a
hell of a lot better if managers _were_ using PERT charts, but it
doeasn't happen in the parts of the software industry I've seen.
(Obviously, I haven't been working in critical DoD projects!)

So my comments were based on the project management technologies that
I've seen -- see Microsoft Project, if you can stand to. If CPM isn't
the right name, then what _is_ the right name for the technology that
does not use variances?

+ Now, getting the data to assign the *variance* -- that's a WHOLE 'nother
+ problem.

Couldn't agree more.
Well, maybe I could... Nasty things in software projects, at least those
which aren't re-implementing something already well understood, tend to
come in large lumps to which a normal distribution is just irrelevant.
So I'm not sure that PERT (though an enormous improvement over most of
what's being done (hell, honest use of CPM (in my sense) would be an
enormous improvement in many places)) is enough without some conscious
slack-time management.

[Nigel Tzeng]

In article <1y67nxy...@dshp01.trs.ntc.nokia.com>,

Marc Girod <gi...@trshp.trs.ntc.nokia.com> wrote:
>I like and practice this technique at times --not systematically
>though. IMHO It is especially suited for debugging sessions, but can

I too have done this before. The obvious caveat is that the pairs
must be carefully choosen. Bad pairs will likely cause too much
friction.

It is probably best at debugging although I find it sometimes
difficult to get into someone else's code cold in a "help me debug
this crazy thing" session. This implies somewhat more systematic use
is probably desireable.

>be used in many other situations. It works better with some pairs than
>with others. To be fruitful, it ought not be the same one at the
>keyboard --although why? I could even imagine that some pairs could
>just work like that!.

I find myself feeling less productive if I'm not the one typing. ;)
The way we were doing this the primary typer was the actual programmer
assigned to the task while the other made comments.

Part of what made this work was the learning nature of the task...we
hadn't ever done what we were doing before so a lot of technical
discussion was useful. We were writing some prototype code for a
technical evaluation of some COTS tools.

The other time we did this was when the other programmer had more of
the relevant math than I did (he was an aero and I'm a CS). When he
sat behind me and guided me through the problem domain. When I sat
behind him I gave my opinion on how things should be structured. I
also knew the case tool better than he did so I'd help him use the
tool to shake out his design.

What really made this work was we respected each other and could give
in when we disagreed. Anything domain related we went with his
judgement...anything "see-essy" was my juristiction. Another factor was
he was an early worker and I was a late worker...we both had natural
time to ourselves.

Could I do this with any members of my current team? No...not really.
There simply isn't a good fit.

As for productivity...I can make a good case for lower defects (those
I had metrics for) but in terms of FP/month I haven't a clue.

>Marc Girod Nokia Telecommunications INS/IPS/MS/NOMA

Nigel

[Charles Martin]

Dan Drake wrote:
>
> On Tue, 6 Jan 1998 11:50:07, Charles Martin <crma...@connix.com> wrote:
>
> +...
> +
> + Uh, no, actually the ream critical path method gives each node a median
> + duration and a variance (the assumption is that durations are normal-
> + distribution, but it's an easy extension to do something else. The
> + thing
> + is, normal distribution is so nicely additive....) This means that real
> + CPM DOES account for the unexpected.
> +
>
> One of us has the terminology wrong, and I admit that it's not wholly
> impossible that I'm the one.

Wrong?! Moi??

:-)

>
> CPM (Critical Path Method), as I learned it, finds the rate-limiting
> steps where the duration of each step is known.
> PERT (Project Evaluation Rsomething Tsomething -- Research Technique??)
> uses the mean and variance thing.
>
> To confuse matters further, people in the computer business seem
> constantly to refer to their CPM charts as Pert charts. It would be a
> hell of a lot better if managers _were_ using PERT charts, but it
> doeasn't happen in the parts of the software industry I've seen.
> (Obviously, I haven't been working in critical DoD projects!)
>
> So my comments were based on the project management technologies that
> I've seen -- see Microsoft Project, if you can stand to. If CPM isn't
> the right name, then what _is_ the right name for the technology that
> does not use variances?

I had it just the reverse of the way you had it -- one of us has it
right!

>
> + Now, getting the data to assign the *variance* -- that's a WHOLE 'nother
> + problem.
>
> Couldn't agree more.
> Well, maybe I could... Nasty things in software projects, at least those
> which aren't re-implementing something already well understood, tend to
> come in large lumps to which a normal distribution is just irrelevant.

Well, it kind of depends on how big the project and its pieces are: if
they're big enough, the Central Limit Theorem comes in and veverything
gets normal again.

> So I'm not sure that PERT (though an enormous improvement over most of
> what's being done (hell, honest use of CPM (in my sense) would be an
> enormous improvement in many places)) is enough without some conscious
> slack-time management.

Always -- ther's a whole risk management issue involved here -- not just
getting the mean time approximately right, but taking steps to recover
if you DO end up out at 3+ sigmas.

[Patrick Logan]

In comp.object Russell Wallace <mano...@iol.ie> wrote:

: Actually, I think that's a better technique in class. When doing

: development, however, by the time I'm sitting down in front of my
: machine I already have a pretty clear idea of what I'm doing. (If I
: haven't, I shouldn't be sitting down in front of the machine yet.)

I guess that depends on what kind of machine you are going to sit in front
of. Machines for interaction, like Smalltalk or Lisp, are good machines to
sit down in front of when you may not have much of an idea of what you are
doing. These are design-time tools for thinking. Thinking can often be
done better in pairs, but I have not actually done what might be more
narrowly defined as "pair programming".

--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com

[Dick Botting JB341]

> Tim Ottinger wrote in message >
> >I wasn't the first to suggest this, but rather a few years
> >ago (like maybe 7) I had started talking about this. I had
> >some friends on my programming team, and when we worked
> >together we got not only better designs, but quicker as
> >well. We could take on two jobs, do them serially or
> >alternate incrementally between them, and really crank it
> >out.

> >
> >Every time I've mentioned this to a manager I was told that
> >I was making it up, it couldn't possibly be more productive
> >than having two people working independently (because of
> >unproductive "conversation": apparently considered to be
> >a cause of most lost productivity). The idea was rejected
> >with a religious ferver.
>

Gerry (spelling?) Wienberg reported on managements inability to
recognize teamwork way back when in his "Psychology
of Computer Programming". He knew of a highly productive
team of four programmers. The first time they did a good job their
manager choose one of them to be promoted (because it
couldn't be the team as a whole that was good, it had to
be just one person in the team). The team resigned and
went to another firm. In this company the same thing happened.
The project was a great success. Management choose someone
else from the team as the "real programmer" and promoted them.
So they moved on.

It is rather like taking a clock to pieces to find which
part is most important... and then removing it and expecting
the "fixed" clock to still tell the time.

Key points:
The whole can be greater than its parts...sometimes.
Ifen it ain't broke don't fix it.
You often don't get a working clock by shaking random cogs etc in a
bag.

--
dick botting http://www.csci.csusb.edu/dick/signature.html
Spam will be automatically deleted before I see it.
Disclaimer: CSUSB may or may not agree with this message.
Copyright(1997): Copy freely but say where it came from.

[Thaddeus L. Olczyk]

On Wed, 07 Jan 1998 09:47:13 -0800, Dick Botting JB341
<di...@doc.csusb.edu> wrote:
>>
>Gerry (spelling?) Wienberg reported on managements inability to
>recognize teamwork way back when in his "Psychology
>of Computer Programming". He knew of a highly productive

>team of four programmers...
I wouldn't take the anecdote seriously. If you read the complete
works of Weinberg you get a sense that he confuses some of them
( from the differences in the story in different books ).

[Russell Wallace]

Patrick Logan wrote:
> I guess that depends on what kind of machine you are going to sit in front
> of. Machines for interaction, like Smalltalk or Lisp, are good machines to
> sit down in front of when you may not have much of an idea of what you are
> doing. These are design-time tools for thinking. Thinking can often be
> done better in pairs, but I have not actually done what might be more
> narrowly defined as "pair programming".

Matter of taste. I've used Lisp and I've looked at Smalltalk, and IMO
both of them have such messy syntax you end up spending more than half
your mental energy just dealing with the language. I've yet to see a
design-time tool for thinking that can beat the old-fashioned pen and
paper.

[Frank A. Adrian]

Thaddeus L. Olczyk wrote in message
<34b57c9...@nntp.interaccess.com>...

>I wouldn't take the anecdote seriously. If you read the complete
>works of Weinberg you get a sense that he confuses some of them
>( from the differences in the story in different books ).

Yes, but this anecdote has taken on a mythic aura within the software
community. As with most myths, there is enough of a kernel of truth
within it that the wise man does not so much demand accurate recounting
of "just the facts, ma'am", but heeds its lessons anyway because to not
do so would entail gigantic risk. The moral of the story (and one that
is recounted in DeMarco and Lister's Peopleware in a much more formal
manner) is "Don't commit teamicide". Unless I misunderstand you and you
believe that breaking up successful teams is a good thing :-).

[Tim Ottinger]

Frank A. Adrian wrote:
> Yes, but this anecdote has taken on a mythic aura within the software
> community. As with most myths, there is enough of a kernel of truth
> within it that the wise man does not so much demand accurate recounting
> of "just the facts, ma'am", but heeds its lessons anyway because to not
> do so would entail gigantic risk. The moral of the story (and one that
> is recounted in DeMarco and Lister's Peopleware in a much more formal
> manner) is "Don't commit teamicide". Unless I misunderstand you and you
> believe that breaking up successful teams is a good thing :-).

I'm at once kinder and harsher on this, but as Bill Nye would say:
consider the following...

Managers don't know how to reward technicians. To a manager,
the ultimate token of respect is a promotion. It's a fistful
of extra dollars, more autonomy, etc. Some managers spend
their entire career trying to get promoted higher up the chain.

How do you reward a career techie? What if you have one of
those horrible, obstinate types (like me) who isn't programming
as a way to get into management, but because he likes it?
How do you reward someone who isn't all that interested in
becoming the CEO, even when it's obvious that that's where
the money leads?

You could invent a title, but that doesn't mean anything.
Free donuts? A day off? Seems trifling. A gift? An award?
Well, it's better than nothing, but doesn't express
thanks like a promotion.

And then you get a team that succeeds? Do you promote
them all? Where do you find the positions for them to
fill? If you don't have a place to move them into,
it's just another title change, possibly with slightly
better pay. That won't do.

A lot of people do this kind of work because it suits
them, not as a way to climb the grand ziggurat to the
nosebleed suite. It's something they're good at, and
nothing sounds quite as dreary as spending your work
time in dates, dollars, and meetings. Also, some
people find politics distasteful.

All that really matters is respect, autonomy, compensation,
and development of skills. A little spot light now and again
doesn't hurt. Maybe the way to reward someone for their
good judgement involves asking their opinions on tough issues,
letting them choose their projects sometimes, or their
team members. Big, stinkin' wads of cash are still accepted,
too. It seems that the way to show respect for a team is
to give them more autonomy and allow them to ascend the
technical ziggurat to "alpha geekdome" as a team.

Not to recommend a pay cut, but many times I've been
more interested in what I get to do, and who I get
to do it with, than how much I get paid or whether
I get be the boss. I'd much rather be a truly great
developer's underling or partner than his boss.

--
Tim
+-----------------------------------------------------------+
| Tim Ottinger: http://www.oma.com/ottinger |
| Object Mentor: http://www.oma.com 800-338-6716 |
+-----------------------------------------------------------+
| Design, Consulting, Mentoring, Training |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein

[J. Kanze]

olc...@iunderaccess.com (Thaddeus L. Olczyk) writes:

|> Reviewing code should always
|> take as much time as writing it. You not only have to replicate
|> functionality, you have to figure out the logic of the other
|> programer.

If you have to figure out the logic, the code should be rejected as not
ready for review. One of the issues of the review is to ensure that the
code is readable. Not after a detailed analysis, but directly.

--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientée objet --
-- Beratung in objektorientierter Datenverarbeitung

[Phlip]

J. Kanze wrote:

>If you have to figure out the logic, the code should be rejected as not
>ready for review. One of the issues of the review is to ensure that the
>code is readable. Not after a detailed analysis, but directly.

I have to think this 'graph addresses the logic of one function. To recite
the standard rules, a function should be shorter than a page, and commented
with purposes, side effects and assumptions clauses; and most of the
assumptions should represent coded assertion and invariant statements. The
function should safely conduct exceptions, procede from top to bottom
naturally, declare variables nearest to where they act, and have a minimum
of non-exceptional exit points. It should not perform compiler or OS tricks,
rely on compiler or OS bugs, contain obsolete misleading or copied comments,
nest blocks too deeply, cram operations into one line that could work in
many lines, reference variables to which nobody granted it conceptual
access, use 'goto' pathologically, or be spaghetti. (And in the unlikely
event that I ever work with J. Kanze, it should not use any recently added
compiler or library features.)

Now, let's figure out some logic; macroscopically. Code reviews should not
dump a stack of green-bar paper on some reviewer, containing in-house
libraries or re-used packages the reviewer has never seen before. But
programs tend to consist of more than one function. That set of new or
changed classes and modules new to the reviewer must be comprehended. If
there are any coding rules that help this - beyond "minimize complexity &
sort the functions in order" - what are they?

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======
-- "ActiveX . . . is the entire universe"
- me trying to explain it to my boss --

[John D Salt]

In article <34B6A1B3...@oma.com>, Tim Ottinger <tott...@oma.com> wrote:
[snippety-snip!]

>consider the following...
>
>Managers don't know how to reward technicians. To a manager,

> [snip]

>How do you reward a career techie? What if you have one of
>those horrible, obstinate types (like me) who isn't programming
>as a way to get into management, but because he likes it?

Rather than promote the meistergeeks to posts where they have to
spend more time on meetings and paper-shuffling, why not offer
them the opportunity to do less? I have worked in plenty of places
where the managers got secretarial and goferage support, but have
never seen it given to tekkies. The message is clear: I am a
manager, so my time is important, but you merely produce software,
so you can do your own admin. This results in fatuous situations
such as $1 000-a-day consultants spending their time doing
photocopying.

I'm sure a lot of technical wizards would like nothing better than
to be the chief programmer in a chief programmer team. Has anyone
ever had first-0hand experience of a company brave enough to try
the idea?

All the best,

John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.

[Tim Ottinger]

Thaddeus L. Olczyk wrote:
> Sounds like you've never reviewed code. Reviewing code should always

> take as much time as writing it.

Gosh, I hope not! You should have pretty printers so that
you can avoid reviewing for aesthetics, and you should have
lint, so you don't have to worry so much about standard language
usage bugs, and you should have Purify or the like so that
you aren't so much concerned with those problems.

Instead, you should be looking to see if the code will really
work as designed in all of the cases you can imagine it will
be used, whether it will survive changes well, and whether it
is efficient and tidy. You might also look to see if it is
something you can learn from.

Also, lots of people keep checklists and review only the
things they see on their checklist (I love looking for
naming/readability issues). The reviewers should also
have some skill in the area for which the code is being
written (though if you use reviews for training exercises,
this may not be so).

Writing is also usually iterative. The reader doesn't
have to go through the iterations (and mistakes) the
coder went through. Sometimes the seven-line, clear,
obvious-seeming code took three times longer than
twenty pages of crap because the coder thought about
it more.

But unless you are a really quick writer or a really slow
reader, I'd be surprized if a weeks worth of coding took
someone a week to read and comment on.

[Phlip]

John D Salt escribio:

>Rather than promote the meistergeeks to posts where they have to
>spend more time on meetings and paper-shuffling, why not offer
>them the opportunity to do less? I have worked in plenty of places
>where the managers got secretarial and goferage support, but have
>never seen it given to tekkies. The message is clear: I am a
>manager, so my time is important, but you merely produce software,
>so you can do your own admin. This results in fatuous situations
>such as $1 000-a-day consultants spending their time doing
>photocopying.

I submit that a department with enough "admin" to fill the time of a
non-tech assistant represents a greater problem than simple poor promotion
policies for programmers. But put that issue aside.

What _I_ want for a perk is someone to write and maintain the simpler
programs, drag GUI elements around on a form builder, run checklists to look
for things like crossed accelerator keys on menus and buttons, develop test
rigs for components, scan USENET for links to example code, and research how
to tweak out the problems in the tools we use. This frees _my_ time to crank
up a music CD in my CD-ROM drive and, at 60 words a minute, cowhand-code.

I think the ancient, traditional term for this relationship is an
"apprentice".

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======

-- Note: Add the text NOSPAM to my address before replying --

[Robert C. Martin]

J. Kanze wrote:
>
> olc...@iunderaccess.com (Thaddeus L. Olczyk) writes:
>

> |> Reviewing code should always

> |> take as much time as writing it. You not only have to replicate
> |> functionality, you have to figure out the logic of the other
> |> programer.
>

> If you have to figure out the logic, the code should be rejected as not
> ready for review. One of the issues of the review is to ensure that the
> code is readable. Not after a detailed analysis, but directly.

A good guideline, but not always feasible. There are some logical
structures that intrinsically complex. No matter how easy they
are to read, they remain difficult to conceptualize and require
a great deal of effort.

--
**We are looking for good engineers, See our website
**for more information.

Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan

[Robert C. Martin]

Tim Ottinger wrote:
>
> How do you reward a career techie?

If he's *really* good, you pay him *really* well and let him
do more of what he likes doing.

[Mark T. Van Ditta]

Tim Ottinger wrote:

> I'm at once kinder and harsher on this, but as Bill Nye would say:

> consider the following...
>
> Managers don't know how to reward technicians. To a manager,

> the ultimate token of respect is a promotion. It's a fistful
> of extra dollars, more autonomy, etc. Some managers spend
> their entire career trying to get promoted higher up the chain.
>

> How do you reward a career techie? What if you have one of
> those horrible, obstinate types (like me) who isn't programming
> as a way to get into management, but because he likes it?

Tim,

That is the best posting I have seen in this newsgroup. I too share
your work orientation. I have been designing and developing software
systems for 18 years, am very good at it, and have absolutely no desire
to move into management. The funny thing is that other professionals,
like doctors, are not looked down upon for wanting to stay hands-on.
Why is this not the case in our industry?

Mark T. Van Ditta

[Lane Stevens]

It appears that Tim was as startled as I at the assertion that a review
"should take as much time as writing it." If you find yourself in an
organization that expends as much time in review as in the writing of
code, I suggest that you review Tim's post to see what techniques you
could add to your process to reduce the time spent in reviews.

The primary objective of a review should be to discover errors and prevent
them from advancing to subsequent phases of the development process.
Another objective would be to detect violations of local standards. The
objective of a review is not to prove correctness, nor could a review be
expected to meet such an objective. That would require more formal
methods.

Reviews that require a total time commitment from each participant that
exceeds 3 or 4 hours (prep time plus any meetings of the review
participants) have likely extended beyond the point of diminished
returns. On a similar note, the number of people involved in a review
should be carefully managed.

The focus of this thread has been code reviews. Far greater benefits will
be derived from the review of work products and development artifacts that
are produced earlier in the development process than can be expected from
reviews of code. Successful formal reviews of the requirements, models,
designs, specifications, etc. from which the code is produced will do more
to assure the production of quality code than reviews of the code.

I suspect that one of the reasons that some organizations require an
inordinate expenditure of time on the review of code is due to the fact
that the review of the other development artifacts is implicit in the
review of the code. This problem is compounded if the code is effectively
the only development artifact (maybe we're drifting back to "cowhand
coders!").

Reviews can be one of the most effective things that an organization can
do to improve the quality and correctness of software that is developed.
However, if misapplied, reviews could become an obstacle rather than an
aid to developers, jeopardizing the benefits of a review program. In a
correctly run review program, the benefits will far exceed the costs, but
the costs still need to be managed. The single most significant component
of cost is the time of the review participants.

One final note is that in today's environment, I would expect much of the
code to be generated. This both reduces the amount of code that needs to
be reviewed, and can sharpen the focus of review on the elements of code
that are produced by hand.

Tim Ottinger wrote:

> Thaddeus L. Olczyk wrote:
> > Sounds like you've never reviewed code. Reviewing code should always

> > take as much time as writing it.
>

---
Lane Stevens
Terrapin Technologies, Inc.
http://www.cycletime.com

[Graham Perkins]

Tim Ottinger wrote:
> Managers don't know how to reward technicians. To a manager,
> the ultimate token of respect is a promotion. It's a fistful
> of extra dollars, more autonomy, etc. Some managers spend
> their entire career trying to get promoted higher up the chain.
>
> How do you reward a career techie? What if you have one of
> those horrible, obstinate types (like me) who isn't programming
> as a way to get into management, but because he likes it?
> How do you reward someone who isn't all that interested in
> becoming the CEO, even when it's obvious that that's where
> the money leads?

Similar problem here in teaching. Some of us want to stick with
learning about software and teaching others about it. But no
career path. We hit top of scale aroung age of thirty-five.
Then face declining real-terms salary for another thirty years
before retiring on inadequate pension. Kudos also declining as
we're obvious failures if still not into management positions
after so long at "chalk face".

Only way out is to do lots of admin. and internal politicking
to claw up management ladder. Uggghhh. (and it's risky - I've
seen lots of people hit middle levels then lose everything
as politicking backfires)

-------------

What about military approach with Guards Divisions and Guards
Armies? Best units are given elite status, better weapons,
higher logistics priorities, higher pay, tougher duties,
extra leave, and more training. It works.

The best software developers should be allowed to work together,
on the toughest projects, but be provided with the best resources.
Between projects they should be given extra leave (yes, *force*
them to spend time with their friends/families. we don't want a
bunch of nerds!). They should also be the first to get sent on
training courses for new technology, and be given plenty of space
for learning and self-training.

.. or am I dreaming?

[William P. Milam]

Phlip wrote:
>
>
> What _I_ want for a perk is someone to write and maintain the simpler
> programs, drag GUI elements around on a form builder, run checklists to look
> for things like crossed accelerator keys on menus and buttons, develop test
> rigs for components, scan USENET for links to example code, and research how
> to tweak out the problems in the tools we use. This frees _my_ time to crank
> up a music CD in my CD-ROM drive and, at 60 words a minute, cowhand-code.
>
> I think the ancient, traditional term for this relationship is an
> "apprentice".
>

or Grad student? ;-)

--
******************************************************************
* This missive is from the screen of William P. Milam *
* The opinions expressed herein are mine and mine alone! *
* My kids don't listen to me, why should you? *
* *
******************************************************************

[P.G.Hamer]

Tim Ottinger <tott...@oma.com> wrote:

A long and thoughtful posting starting ...

>I'm at once kinder and harsher on this, but as Bill Nye would say:
>consider the following...
>

>Managers don't know how to reward technicians. To a manager,
>the ultimate token of respect is a promotion. It's a fistful
>of extra dollars, more autonomy, etc. Some managers spend
>their entire career trying to get promoted higher up the chain.

Some years ago the Harvard Business Review had an article on how
NASA turned itself round from a research organisation to a business
one. A large number of the points they made about the two cultures
have IMHO close parallels between s/w developers and their managers.

Foe example, a major reward for a manager is to increase the number
of people reporting to them. For a researcher, a major reward is
to be given a more difficult problem to solve!

Peter

[L. Darrell Ray]

Lane Stevens wrote:
>
> It appears that Tim was as startled as I at the assertion that a review
> "should take as much time as writing it." If you find yourself in an
> organization that expends as much time in review as in the writing of
> code, I suggest that you review Tim's post to see what techniques you
> could add to your process to reduce the time spent in reviews.
>
> The primary objective of a review should be to discover errors and prevent
> them from advancing to subsequent phases of the development process.

<snip>
I may be wrong but I assumed the review time included all reviews not
just the *Code Review*. Given this assumption the statement makes more
sense. Especially since IMO doing Code Reviews while not doing reviews
of workproducts from earlier life cycle phases indicates misplaced
priorities and a lack of understanding of where the greatest impact can
be obtained.

--
L. Darrell Ray
ASQ Certified Software Quality Engineer
Dade International

[Tim Ottinger]

> I may be wrong but I assumed the review time included all reviews not
> just the *Code Review*.

The statement I responded to said "Reviewing code should always

take as much time as writing it."

> Given this assumption the statement makes more sense. Especially since

> IMO doing Code Reviews while not doing reviews of workproducts from
> earlier life cycle phases indicates misplaced priorities and a lack of
> understanding of where the greatest impact can be obtained.

There's also something misleading here (I mentioned the iterations
as being important: A revewier doesn't have to make assumptions
that don't pan out, track them until they break down, and then
correct them). I think if you look at a company that is always
four months late on four month projects, and you tell them that
it takes as long to review a work product as it does to create it,
then you've convinced them that adding reviews will take their
8-month cycle (for four-month projects) and turn it into a
16-month cycle. I don't think that's the case. Reviews initially
add some time to the process, but don't double the time to
delivery. As time goes on, reviews help to chop the cycle time
due to training value, mostly IME. You don't re-make the same
mistakes you've had corrected in the past, and you tend not to
make the kinds of mistakes you've seen corrected in your peers.

Reviews also help to lead to a patterns culture, IMHO. This
also helps to reduce cycle time.

It's not untrue that reviews take time, but I think it's easy
to overstate the cost of them, and it's hard to accurately
state the impact it will have on cycle time.

--

[Dan Drake]

On Sun, 11 Jan 1998 20:32:31, "Mark T. Van Ditta"
<mvan...@NO.SPAM.acm.org> wrote:

+ Tim Ottinger wrote:
+ [excellent stuff about what good programmers want]
+
+ Tim,
+
+ That is the best posting I have seen in this newsgroup. I too share
+ your work orientation. I have been designing and developing software
+ systems for 18 years, am very good at it, and have absolutely no desire
+ to move into management. The funny thing is that other professionals,
+ like doctors, are not looked down upon for wanting to stay hands-on.
+ Why is this not the case in our industry?
+

Because we don't have Certificates that prove we're Professionals!
Therefore, we can succeed only by being promoted into a responsible
position.
Best argument for licensing software people that I've ever heard.
If you think that's damning with faint praise, you're right.

[T]he term "responsible position" shall be taken to signify a position
which, by reason of its nature, compels the holder to issue instructions
to other persons to carry out certain acts, notwithstanding the fact
that the holder has no understanding whatsoever of that which he is
instructing the aforesaid persons to accomplish.
--Weisskopf & Feynman, 1965
cited in Gleick, Genius, p. 383

[Martin Tom Brown]

In article <699qgb$j39$1...@news01.deltanet.com> te...@deltanet.com "Phlip" writes:

> John D Salt escribio:
>
> >Rather than promote the meistergeeks to posts where they have to
> >spend more time on meetings and paper-shuffling, why not offer
> >them the opportunity to do less? I have worked in plenty of places
> >where the managers got secretarial and goferage support, but have
> >never seen it given to tekkies.

I have - in fact the first place I worked we had our own technical
assistant for exactly this (shared with the R&D dept manager).

> I submit that a department with enough "admin" to fill the time of a
> non-tech assistant represents a greater problem than simple poor promotion
> policies for programmers. But put that issue aside.

Depends what you are doing - if you need lots of obscure books
papers and references for some development or patent work then
chasing them up can easily become a full time job!

> What _I_ want for a perk is someone to write and maintain the simpler
> programs, drag GUI elements around on a form builder, run checklists to look
> for things like crossed accelerator keys on menus and buttons, develop test
> rigs for components, scan USENET for links to example code, and research how
> to tweak out the problems in the tools we use. This frees _my_ time to crank
> up a music CD in my CD-ROM drive and, at 60 words a minute, cowhand-code.
>
> I think the ancient, traditional term for this relationship is an
> "apprentice".

We even had one of those once (pinched off the metalwork shop).
And ending up defining the terms of reference for a "software apprentice"
for the NW (a heck of a lot of tedious paperwork) as a result.
It was a success and in time he made a great software engineer.

Ask and you might just get - iff you can make the business case stick!

The other major job that gofer support gets in a smaller organisation
is sorting out basic user problems on PC's and Mac's. Problems which
otherwise have a bad tendency of distracting highly skilled workers.
Come to think of it lots of big organisations have problems with
highly skilled worked distracted into fixing trivial PC problems.

Regards,
--
Martin Brown <mar...@nezumi.demon.co.uk> __ CIS: 71651,470
Scientific Software Consultancy /^,,)__/

[Todd Smith]

Phlip wrote:

snip...

>
> What _I_ want for a perk is someone to write and maintain the simpler
> programs, drag GUI elements around on a form builder, run checklists to look
> for things like crossed accelerator keys on menus and buttons, develop test
> rigs for components, scan USENET for links to example code, and research how
> to tweak out the problems in the tools we use. This frees _my_ time to crank
> up a music CD in my CD-ROM drive and, at 60 words a minute, cowhand-code.
>
> I think the ancient, traditional term for this relationship is an
> "apprentice".
>

This brings up an issue our company has been discussing for a long time
but have never figured out what to do about it. The issue is the role of
a software technician. There are many activities (as pointed out by
Philip) that could be delgated to such a person so as to most
efficiently use the engineer's skills. Our problem with this concept is
that there seems to be little precedence for the role of software tech.
While hardware technicians are widely used by hardware engineers, there
seems to be no widespread use in software. I was wondering if there are
any of you who have experienced the use of software techs. What were the
roles? How well does it work? What is the necessary level of
training/education?

--Todd

[Brad Appleton]

In article <34BA385D...@cycletime.com>, Lane Stevens
<la...@cycletime.com> writes:

> The primary objective of a review should be to discover errors and
> prevent them from advancing to subsequent phases of the development

> process. Another objective would be to detect violations of local
> standards.

This is not always true. This is usually true for one type of review
which is called an "inspection". There are other types of reviews
(even code reviews) where the primary objective should not be to
discover errors, but to understand the document or code being
reviewed. The primary purpose here is to disseminate knowledge and
broaden the base of understanding. If the attendees *truly* understand
the artifact they are reviewing, then discovering errors will be a
natural side-effect when reconciling the understood intent of a
snippet versus what it actually does/means.

Please note that I'm NOT saying this is how all inspections/reviews
should be done. But it is one type of review that is very effective
which does *not* have defect identification and removal as its *primary*
goal.

Cheers!
--
Brad Appleton <bra...@enteract.com> | http://www.enteract.com/~bradapp/
"And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng

[Phlip]

Martin Tom Brown escribió:

> Depends what you are doing - if you need lots of obscure books
> papers and references for some development or patent work then
> chasing them up can easily become a full time job!

In general, thanks - this all was just the kind of back-up I was looking for.

But by "set that issue aside" I was hoping the thread would not blast off into
endless refutations of my blanket assumption that programmers should not fill out
their own forms. No harm done (so far 8-).

> We even had one of those once (pinched off the metalwork shop).
> And ending up defining the terms of reference for a "software apprentice"
> for the NW (a heck of a lot of tedious paperwork) as a result.
> It was a success and in time he made a great software engineer.

What's an "NW" - more "admin" paperwork, right?

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======

-- All sensors report Patti having a very good time --

[Phlip]

Todd Smith escribió:

> Phlip wrote:
>
> ...maintain the simpler

> > programs, drag GUI elements around on a form builder, run checklists to look
> > for things like crossed accelerator keys on menus and buttons, develop test
> > rigs for components, scan USENET for links to example code, and research how

> > to tweak out the problems in the tools we use...

> This brings up an issue our company has been discussing for a long time
> but have never figured out what to do about it. The issue is the role of
> a software technician. There are many activities (as pointed out by

> Phlip) that could be delgated to such a person so as to most

> efficiently use the engineer's skills.

Okay. Now remember that "legacy software maintenance" is typically a brutal job -
reading miles of code written in the idioms of yesteryear seeking bizarre bugs,
adding minor features without breaking major ones, and generally putting on your
hip waders and slogging thru nasties. The only way not to throw good money after
bad here is to put the gurus on it and let them smite it once with their staffs.
Get it over with quickly.

This job was not on my list - "maintain the simpler programs" means keeping the
in-house tools (test emulators and tiny glue programs) up to date.

> Our problem with this concept is that there seems to be little precedence for
> the role of software tech. While hardware technicians are widely used by
> hardware engineers, there seems to be no widespread use in software. I was
> wondering if there are any of you who have experienced the use of software
> techs. What were the roles? How well does it work? What is the necessary level
> of training/education?

Could someone explain to me why our under-grad hireling was assigned to both light
programming duties, help file building, _and_ legacy maintenance??

That's a rhetorical question. Don't answer it, because the only answer is "because
you all are lame!"

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======

-- Shock Value Added --

[Robert C. Martin]

Tim Ottinger wrote:
>
> It's not untrue that reviews take time, but I think it's easy
> to overstate the cost of them, and it's hard to accurately
> state the impact it will have on cycle time.
>

There is a fine line to be walked here. One should not expect
to review a module in a single afternoon that took fifteen days
to write. A significant module will require a significant amount
of time to review. Granted there are efficiencies. These
efficiencies lead to a formula something like:

Tr = Tc * F

Where Tr is Coding time.
Tc is Review time.
F is some factor in the open interval (0,1)

We should expect F to be on the order of 0.5 to 0.2. That is,
review may take between one half to one fifth the coding time. We
should become suspicious if F gets larger than 0.5 or smaller than
0.2. (These numbers are brown and greasy).

The effect of a good review strategy is to greatly shorten the
development cycle. The reasons are manyfold. First, errors caught
in review are much less expensive (in terms of time) than errors
caught later. Secondly, reviewers learn about the code and design
produced by others, they see techniques that they can use themselves,
novices learn by reviewing their mentors, and mentors learn the
il-practices of the novices they review.

The absolute worst strategy of any organization is to waive reviews
when the schedule gets tight. Such a policy abolishes any hope that
the project can be completed on time.

Having said that, I abhor large, tedious review sessions. IMHO,
reviews should not be conducted as meetings (I am not talking about
walkthroughs here). Rather one (or possibly two) reviewers should
take the work product and review it independently of the author. The
reviewer should prepare a review document and give it to the author.

[Dick Botting JB341]

Dan Drake wrote:
>
> On Tue, 6 Jan 1998 11:50:07, Charles Martin <crma...@connix.com> wrote:
>
> +...
> +
> + Uh, no, actually the ream critical path method gives each node a median
> + duration and a variance (the assumption is that durations are normal-
> + distribution, but it's an easy extension to do something else. The
> + thing
> + is, normal distribution is so nicely additive....) This means that real
> + CPM DOES account for the unexpected.
> +
>
> One of us has the terminology wrong, and I admit that it's not wholly
> impossible that I'm the one.
>
> CPM (Critical Path Method), as I learned it, finds the rate-limiting
> steps where the duration of each step is known.
> PERT (Project Evaluation Rsomething Tsomething -- Research Technique??)
> uses the mean and variance thing.
> s I recall from a brief stay in an OR and Stats
group in the 1960's, and from BS degree courses. There
is an algorithm called
Critical Path Analysis
which assume fixed durations for steps in a project and
separates the "Critical Path" from the non-critical steps.
You can let the "non-critical steps slip and slide
without delaying the whole project. I have found it
useful for small projects (by hand) and for 5-year plans
(using MacProject).

PERT: Project Evaluation and Review Technique certainly
includes the idea that the steps in a project are "random
variables" but I think that they assumed Beta or Gamma
distributions? I've not used this.

I can't recall a CPM offhand... it might mean any mixture
of CPA PERT and things like that.

--
dick botting http://www.csci.csusb.edu/dick/signature.html
Junk EMail will be deleted unread.
Disclaimer: CSUSB may or may not agree with this message.
Copyright(1998): Copy freely but say where it came from.

[Thomas Beale]

Graham Perkins wrote:

>
> Tim Ottinger wrote:
> > Managers don't know how to reward technicians. To a manager,
> > the ultimate token of respect is a promotion. It's a fistful
> > of extra dollars, more autonomy, etc. Some managers spend
> > their entire career trying to get promoted higher up the chain.
> >

[]

> What about military approach with Guards Divisions and Guards
> Armies? Best units are given elite status, better weapons,
> higher logistics priorities, higher pay, tougher duties,
> extra leave, and more training. It works.
>

You are probably dreaming, but the principle is right IMO - the
simple-minded idea of merit in most human endeavour in
modern societies is the $ (Y, F, etc). Interesting sub-cultures
like the army, religion orders, charity organisations fly
in the face of this wisdom.

Actually this whole problem comes up in many previous conceptions
of a utopian society. I think someone said that as long as there
was a little gold badge to wear, for people who do well,
everything would be fine. Kind of like the army. Q: does this
mean we all crave recognition, or power?! (since stars in the army
usually mean the right to demean those with fewer stars...)

- thomas beale

[Matt Kennel (Remove 'NOSPAM' to reply)]

On Mon, 12 Jan 1998 17:07:23 +0000, P.G.Hamer <P.G....@nortel.co.uk> wrote:
:Some years ago the Harvard Business Review had an article on how

:NASA turned itself round from a research organisation to a business
:one.

Was this talking about the long decline of NASA or the recent turnaround?

If the latter, then it's backwards---NASA has been trying to be more and more
a focused research organization, and is trying to get out of the operational
side of ''business'' as much as possible.
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address.
*

[Murray Spork]

Tim Ottinger <tott...@oma.com> wrote in article
<34BA581D...@oma.com>...

> Reviews also help to lead to a patterns culture, IMHO. This
> also helps to reduce cycle time.

> It's not untrue that reviews take time, but I think it's easy
> to overstate the cost of them, and it's hard to accurately
> state the impact it will have on cycle time.

**WARNING** Newbie post coming up.

Excuse me for butting in - but an old saying comes to mind - "a stitch in
time saves nine". For example - if you don't discover an error in the
Requirements spec until you are reviewing or testing code, it is likely to be
a hell of a lot more expensive to rectify, both in terms of time and
resources, than if you discovered it before entering the design phase. i.e.
the earlier you discover errors the better (obvious I know) - but more than
that - undiscovered errors in the initial stages of the life-cycle
(e.g.requirements analysis) are likely to be compounded throughout the rest
of the development process and are therefore likely to be *extremely* costly
to correct unless discovered early on.

Murray,
who has a knack for stating the bleeding obvious.

[Jeff Miller]

"Murray Spork" <mu...@freeman.net> writes:

>**WARNING** Newbie post coming up.

>Excuse me for butting in - but an old saying comes to mind - "a stitch in
>time saves nine". For example - if you don't discover an error in the
>Requirements spec until you are reviewing or testing code, it is likely to be
>a hell of a lot more expensive to rectify, both in terms of time and
>resources, than if you discovered it before entering the design phase. i.e.
>the earlier you discover errors the better (obvious I know) - but more than
>that - undiscovered errors in the initial stages of the life-cycle
>(e.g.requirements analysis) are likely to be compounded throughout the rest
>of the development process and are therefore likely to be *extremely* costly
>to correct unless discovered early on.

If that's a newbie post, then we need more newbies.

You are exactly right, of course. The "more or less generally accepted"
notion is that it is an order of magnitude more expensive to resolve a
defect after each step in the development process. Whatever the actual
number, and naturally it is going to vary tremendously case by case,
astute organizations emphasize up front activities.

As my partner Lane Stevens mentioned in a previous post on this thread,
the concept of reviews should be extended to all development artifacts:
design and architectural documents, etc. Code reviews alone come way
too late in the development process. I have seen studies that put the
cost of coding and debugging (that is, looking for *code* defects, not
design flaws) at only about 8% of the overall cost of the system.

For a number of reasons, there remains a tremendous amount of resistance
to these ideas in certain development organizations. A number of
managers, when faced with schedule pressure, quickly fall into the 'code-
by-the-pound' trap. They need to see tangible results so they can feel
comfortable that progress is being made toward the schedule.

It is very easy to measure the fact that the developers added 500 lines
of code to the repository in a given day. That is both obvious and
quantifiable. It is more difficult to measure the impact of a good design
decision, even though the impact can be multiple orders of magnitude
more important than the 500 lines of code. That is a paradox of this
business: The most important things we do are less quantifiable than
the least important things we do.

Ultimately, this is why you do reviews. You have to get away from the
idea of reviews interferring with your coding time. That's just 'code-
by-the-pound' thinking. Instead, think of reviews as a systematic way
of applying a greater number of minds to a conceptual problem. That is
where massive improvements can be found.

Jeff Miller
Terrapin Technologies, Inc.
jmi...@cycletime.com
http://www.cycletime.com

[Scott P. Duncan]

Mark T. Van Ditta wrote:
> The funny thing is that other professionals,

> like doctors, are not looked down upon for wanting to stay hands-on.

> Why is this not the case in our industry?

In many ways, I tend to think of lawyers and doctors as equivalent
to independent consultants rather than employeees of a company.
They work as such in a field with high entry costs and requirements.
They have some stiff penalties that can be levied for poor work
and they can loose their right to work in their profession through
removal of their licensing.

Most people in software are not subject to such costs or constraints.
(They can lose their jobs, but they cannot to the extent that they
could no longer be allowed to program by law.)

The independent nature of doctors and lawyers (though they may form
partnerships and small practices) addresses much of the issue of
maintaining the hands-on nature of work. They are their own mana-
gers, for the most part. Most doctors in hospitals are there, not
as employees (the way nurses, technicians, pharmacists, etc. are
usually present), but as associates with priveleges at the hospital.
The hospital gets room fees, etc. and you also pay a doctor bill.
That's why they are separate: the doctors are not hospital employees.
(You do not pay individual nursing bills, for example, because they
do work for the hospital.) A given doctor may have priveleges at a
number of hospitals in a lartge city.

I think the work relationships are very different. I would never
suggest, by the way, that nurses are not "professional," but they
are not independent practitioners, for the most part.

[Phlip]

Murray Spork escribió:

> ..."a stitch in time saves nine". For example - if you don't discover an error

> in the Requirements spec until you are reviewing or testing code, it is likely
> to be a hell of a lot more expensive to rectify, both in terms of time and

> resources, than if you discovered it before entering the design phase...

This illustrates the main reason why OO design techniques work. You must test and
review a design before committing any code. Alternate languages for prototyping -
including screen builders, concept languages like SmallTalk, and graphical
modeling "languages" - give the team something to review during the correct phase
of the project - not after it is too late.

-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======

-- Founding member of NuGWa;
Nudists for Global Warming --

[Scott P. Duncan]

In an attempt to drag this back to the original topic, I
reiterate the question of whether anyone else is interested
in systems dynamics applied to software development?

(Perhaps the fact that the thread went right off this topic
immediately, suggests there isn't any one? :-) )

[Tim Ottinger]

Andrew Gabb wrote:
> > The funny thing is that other professionals,
> > like doctors, are not looked down upon for wanting to stay hands-on.
> > Why is this not the case in our industry?
>

> Strange question.
>
> When you compare yourself with doctors, do you consider how much you
> earn compared with how much they earn? How can you think there is any
> basis for comparison?

Andrew, it's a strange argument, also.

Are you saying that doctors are not looked down upon for
staying hands-on because they make a lot of money? If
programmers were paid at least six digits, would it be
be more acceptable to stay hands-on and not join management?

[Eric Gregori]

Todd Smith wrote:
>
> Phlip wrote:
>
> snip...
> >

> > What _I_ want for a perk is someone to write and maintain the simpler

> > programs, drag GUI elements around on a form builder, run checklists to look
> > for things like crossed accelerator keys on menus and buttons, develop test
> > rigs for components, scan USENET for links to example code, and research how

> > to tweak out the problems in the tools we use. This frees _my_ time to crank
> > up a music CD in my CD-ROM drive and, at 60 words a minute, cowhand-code.
> >
> > I think the ancient, traditional term for this relationship is an
> > "apprentice".
> >
>

> This brings up an issue our company has been discussing for a long time
> but have never figured out what to do about it. The issue is the role of

> a software technician. There are many activities (as pointed out by
> Philip) that could be delgated to such a person so as to most
> efficiently use the engineer's skills. Our problem with this concept is

> that there seems to be little precedence for the role of software tech.
> While hardware technicians are widely used by hardware engineers, there
> seems to be no widespread use in software. I was wondering if there are
> any of you who have experienced the use of software techs. What were the
> roles? How well does it work? What is the necessary level of
> training/education?
>

> --Todd
Our software techs strictly TEST software. Releases also go through our
product testing department. The idea behind our software techs is
pinpoint testing. The product testing department is concerned with the
whole overall product. Our techs do things like, test this feature and
only this feature, put it through all its paces.

emgr...@wwa.com

[Dave Gill]

In article <01bd2018$28cd77a0$LocalHost@murray>, Murray Spork
<mu...@freeman.net> writes
>
>Excuse me for butting in - but an old saying comes to mind - "a stitch in

>time saves nine". For example - if you don't discover an error in the
>Requirements spec until you are reviewing or testing code, it is likely to be
>a hell of a lot more expensive to rectify, both in terms of time and

>resources, than if you discovered it before entering the design phase. i.e.
>the earlier you discover errors the better (obvious I know) - but more than
>that - undiscovered errors in the initial stages of the life-cycle
>(e.g.requirements analysis) are likely to be compounded throughout the rest
>of the development process and are therefore likely to be *extremely* costly
>to correct unless discovered early on.
>
>

At the same time the user community do not often know thier true
requirements until someone sits down with them and puts them in a
physical form. Then when you have done some devlopment based on this
they get a true feel of what they do not want and this is where you get
problems in requirements.

As far as i am concerned this is just part of the iterative process and
emphasises the need for coders with domain knowledge so that these
things can be corrected early on.

@@@@

Dave Gill

@@@@

[Andrew Gabb]

Mark T. Van Ditta wrote:

> That is the best posting I have seen in this newsgroup. I too share

> your work orientation. I have been designing and developing software

> systems for 18 years, am very good at it, and have absolutely no desire

> to move into management. The funny thing is that other professionals,

> like doctors, are not looked down upon for wanting to stay hands-on.
> Why is this not the case in our industry?

Strange question.

When you compare yourself with doctors, do you consider how much you
earn compared with how much they earn? How can you think there is any
basis for comparison?

Please go back to your cubicle.

Andrew
--
Andrew Gabb
email: ag...@tpgi.com.au
phone: +61 8 8342-1021
fax: +61 8 8269-3280
-----

[Murray Spork]

Jeff Miller <ct...@probe.net> wrote in article <69g0gb$86$1...@jake.probe.net>...

<snip>

> If that's a newbie post, then we need more newbies.

Thanks - it is nice to know that the theory I am learning on my SE course bears
some correlation to your real world experience.

<snip>

> You are exactly right, of course. The "more or less generally accepted"
> notion is that it is an order of magnitude more expensive to resolve a
> defect after each step in the development process. Whatever the actual
> number, and naturally it is going to vary tremendously case by case,
> astute organizations emphasize up front activities.

<snip>

> For a number of reasons, there remains a tremendous amount of resistance
> to these ideas in certain development organizations. A number of
> managers, when faced with schedule pressure, quickly fall into the 'code-
> by-the-pound' trap. They need to see tangible results so they can feel
> comfortable that progress is being made toward the schedule.

Is there a danger that the development team can become paralyzed by fear and
uncertainty in the early stages of the life-cycle? i.e. when you realize how
important it is to get the early stages right (I am thinking specifically of
Requirements Specification and then Design) is it possible that you become so
obsessed with this that you find it difficult to move into the next stages of
development. I imagine that there comes a point, say in the preliminary design
phase, where even if you're not sure which way to go with a particular design
decision, that you just have to make the decision and go with it. I know there
are paradigms that attempt to address this with iterative and evolutionary
approaches - but I am wondering if there is another side to this coin -
i.e. can you go overboard with reviews?

> It is very easy to measure the fact that the developers added 500 lines
> of code to the repository in a given day. That is both obvious and
> quantifiable. It is more difficult to measure the impact of a good design
> decision, even though the impact can be multiple orders of magnitude
> more important than the 500 lines of code. That is a paradox of this
> business: The most important things we do are less quantifiable than
> the least important things we do.

I like this last line - it seems to me to go to the very core why software
development is so difficult to manage. I shall remember this statement come
exam time - thanks : )

Murray Spork

[Scott P. Duncan]

Murray Spork wrote:
>
> it is nice to know that the theory I am learning on my
> SE course bears some correlation to your real world experience.

The particular case of cost of defects through the lifecycle
is relatively well-accepted through experience. I can't say
what othe theories might or might not be greeted with the same
enthusiasm in comp.software-eng! Some SE programs spend some
time on process methods and evaluation. This is NOT always
greeted favorably in the real world or in the newsgroup.

> Is there a danger that the development team can become
> paralyzed by fear and uncertainty in the early stages of
> the life-cycle?

Never seen it happen. Delays occur for other reasons, but
the fear of not gertting it right isn't one of them!

> i.e. can you go overboard with reviews?

Sure and with lots of other things as well. Usually, what
happens to "go overboard" is some misguided edict about
the % of code to be reviewed. I've seen senior management
put 100% code inspection policies in their quality systems
and then have to back off because the result isn't what they
really meant. Sometimes the results is just creative reinter-
pretation of what "100%" means or what category of software
such a % will be applied against, e.g., new code, not all code
touched, etc.

[Andrew Gabb]

Tim Ottinger wrote:

> Andrew Gabb wrote:
> > Strange question.
> >
> > When you compare yourself with doctors, do you consider how much you
> > earn compared with how much they earn? How can you think there is any
> > basis for comparison?
>

> Andrew, it's a strange argument, also.
>
> Are you saying that doctors are not looked down upon for
> staying hands-on because they make a lot of money? If
> programmers were paid at least six digits, would it be
> be more acceptable to stay hands-on and not join management?

No, it was a feeble attempt at satire. So is some of what follows. I'm
trying to make a point here, not flaming Tim or anyone else.

What I was really suggesting that the reason that programmers go into
management is the money and the power (and because they feel looked down
upon because they're paid less, which is the same thing). Doctors don't
have this problem. Most of them in this country, and in yours I
suspect, already earn 2 to 5 times what an average programmer earns, and
most of the populace respects them for some strange reason. They don't
_feel_ looked down upon.

Now the reason that programmers are paid what they are is simply because
that's all they need to be paid. Some of the really good ones are paid
much more, so they're obviously worth more, but there are not many of
them.

You might also take a look at what pilots earn. Not big airline pilots
or fighter pilots, but the rest. Peanuts! Why? Because they enjoy
doing the job and that's what they'll work for.

Come on, admit it, you feel superior or at least equal to doctors and
managers, don't you? You may feel superior to your clients too (I see a
lot of client and manager flaming in this group). Are you sure these
feeling are justified? Do you have objective evidence to support it,
that will convince anyone except the gal in the next cubicle, and the
boys in the bar?

Now I've got up everyone's nose, please calm down and think about why
you're angry. It's probably because you feel you're not appreciated,
and that's the real problem. I know this feeling. It's a cruel world,
no?

Andrew (the Heretic)

[Scott P. Duncan]

Andrew Gabb wrote:
>
> most of the populace respects them [Doctors] for some
> strange reason.

Part of that is clearly the knowledge they have which is clearly,
in the minds of the public, not something you can go to a local
bookstore and by how-to manuals, e.g., how-to program in X, etc.
It certainly is the sense in the U.S. that "programming" is an
occupation/career/profession that most anybody can get into if
they want to do so. Medicine and law are not regarded in that
light. I don't find the reasons strange at all. The public
has little contact with programmers (or others software careers)
in any professional capacity.

> Come on, admit it, you feel superior or at least equal to
> doctors

Not because of professional reasons. I object to the high-handed
treatment of patients that many display, but that's an aspect of
client/customer service, not technical proficiency.

> (I see a lot of client and manager flaming in this group).

More the latter, I believe, by a good bit.

> Are you sure these feeling are justified?

Of course we are! :-) Management is just no darn good! :-)

> Do you have objective evidence to support it

'Course not, this is a newsgroup about software! :-) -- need I keep
doing this...perhaps so! :-)