RE: Two persons per product"

<WARNING...!  Loooong post, incoming...!>


Man, Lief...!

It's like you lined 'em up, just for me to shoot 'em down...!

So I'll start with YOU...  LOL...!


But before that, I'll say I've REALLY enjoyed this thread...!  (This
discussion goes back even further than the "Age-Old Debate" on using the
primary cycle...;-)  But where I see all the points of disagreement, I
mainly see where there is an awful lot of overlap in what appears to be
contradictory statements.  In fact, not to mention any names (Brad ;-), but
I sometimes see more contradiction in one individual's posts, than in the
apparently conflicting viewpoints.

I wish time permitted me to comment on each post.  Generally I agree with
what everyone said, with just a few exceptions.  All that to say...:



...Now, Leif.. If you're saying there's no room for creativity in
programming, then I disagree with you completely.  I don't think that's what
you're saying, however, and I don't REALLY believe that you think that.  I
think you're just trying to point out the problems in the industry.

===> That problem is stated, precisely, by the comparison of coding to art,
rather than craft.  I'll drive that point home, very easily, by asking the
question:  How many of you have a Picasso or Van Gogh hanging in your
livingroom...?!?

IOW, programmers are pricing themselves out of the market, IMV.  At some
point, tools will replace a lot of programmers, for this reason.  Been going
on for a long time now (Synon, Lansa, BCD, MRC, etc.) but the process is
only gonna be speeded up unless programmers achieve greater levels of
effectiveness.  Hardware/software costs are going down.. personnel costs are
going up...



Another point of disagreement I have is where Brad commented on the need for
strong individualism, but then layed out a set of coding standards that are
stricter than anything I've ever seen, except in my own shop...!  And if
those coding standards are written down anyplace, then Brad's got me beat.
;D



The analogy about comparing program to creating art clearly illustrates one
of the fundamental problems in the industry.  I think that the analogy is
not so close as it appears, however.  IMHO, this analogy is a closer
parallel to the process of programming:


Programming is a lot more like writing, than painting.  I s'pose there could
be some debate about this, but I'm working on the assumption that most folks
understand their job isn't to create, in and of itself, but to support the
company they work for.  There is a fair bit of confusion about this, but I
think most would understand this point.  Anybody who's fought back a
downturn in the company knows...:  It doesn't matter if you're producing
Picasso's of programming.  If the company loses money for too many years,
yer outofa job...!  Period.

Company cultures differ, and the IT dept is can be more closely aligned with
the business, or less.  That balance is achieved because those both within
and without the IT dept want either a closer alignment or an IT department
that is more aloof.

But there is a direct connection between what IT does, and how the company
functions, no matter what the view...


Looking at producing code is a false point to start from, then, in this
view.  The question is how to produce systems.  And I think it is generally
recognized that systems are produced, not for their own sake, but to help a
company make a profit (even in not-for-profits).  To help companies provide
better goods and services to their customers.  I think this is actually what
a lot of this here debate is about, but it's not phrased in that way.  But
in this view, IT departments are a service organization within the company.
So in this view, even if you're not working for an ISV, the users of the
software are "customers".  (Of course, that's not always easy to see it that
way, especially when the users don't view themselves as customers.)

But I'm not even gonna attempt to address the issue of creating systems, but
only the issue of creating programs.


I think programming is VERY much like writing.

===> Except that you don't see a whole lot of debate about how to form each
and ever letter of the alphabet that forms a story, like you do in the
programming world.

There is an assumption that if you want to gain some efficiency in the
programming world, you are necessarily talking about resorting to stamping
out programs like an assembly line produces cars.  Nothing further from the
truth, in my mind (although I don't know, for sure, about Leif).

What I'm talking about is not spending so much time creating a work of art,
and not spending a whole lot of time making each single letter in a story as
artistic as possible.  Because that doesn't provide any value-add to the
company you work for.


I'm NOT TALKING ABOUT ELIMINATING CREATIVITY.  Can I make that any
clearer...?

Maybe by extending the analogy...

IMV, the creativity just needs to be redirected.  Not so much put into the
forming of each letter that goes into the story, or even in each word and
paragraph (a la CASE tools).  The creativity is in understanding the subject
matter, organizing the story, and phrasing it so it makes sense and gets
some points across.

In programming, the code represents the tiniest tip of the iceberg of
creativity that goes into solving the business problem.  The bulk of the
creativity goes into understanding what the user needs (when frequently that
is the exact opposite of what they tell you...;-).  The creativity goes in
making balanced judgments...

One of the most difficult classes of decisions that go into coding involve
when is going quicker just gonna result in cut corners, and when it doesn't.
When it's better to try new techniques, and when it's better to clone what
you know has worked.  Determining in what ways this job is similar to what
you've done in the past, and what ways it isn't.  Seen folks re-invent the
wheel, plenty of times, just to try out some new techniques.  Also seen
folks take a square peg and jam it into a round whole, just because the last
job called for a square peg.

Some people say that what I'm talking about takes the creativity and the
challenge out of programming.  Funny...  After 23 years of doing this, I
still find plenty of challenge.  How FAST can I get this job done
**five-nines correctly**.  That's still a challenge for me.  I'm sure some
people think that when I refer to the fact of the Law of 80/20 Rule, that
doesn't apply to coding.  Well, it certainly does..  At all times...  I need
the code to be five-nines, but how I get it there requires judicious use of
the 80/20 rule.  That is, if I'm going to accomplish the task in any kind of
time-frame, anyway.


So when I talk about 2 people working on a program, it's in order to get the
story out, without resorting to a rough draft or two.  Get it out in "one
take", as they say in the flicks.  Get the program written or changed with
one or two compiles, and have it execute the way I intended, in one run.
Doesn't always happen that way, that's for sure, but it isn't rare either.
I'm talking hundreds of lines of new code or changes (just in case you're
thinking sure, I do that all the time, myself, without anyone helping).

In my experience, this is easier when you have someone watching for typos,
or logic errors, or reversed logic.  Not only that, but if you have someone
who knows more about writing, the best way to teach that to another is by
way of example.  I'm not even going to emphasize the points about turnover,
maintenance, and all that.  These facts exist, in most shops.


So when people ask about spending double the time to produce a program:

First of all, it may not halve the time, but it may.  It should reduce the
time involved, if it's done correctly.  This is not at all easy, and can in
fact take double the time of one person working on a program if it's not
done correctly.  Like anything.. depends on HOW it's done.

Second of all, how much value do you put on bringing those less-experience
on par with the more-experienced?  How much value do you put on
cross-training?  If you don't have any turnover or vacations, you might not
have these issues.  If you have a great excess of staff, you might not have
these issues.  If you have a great excess of budget, you can make sure your
programmers don't walk down the street.  But even in these rare cases, there
are benefits of cross-training and training apprentices.  (Also works
between two masters of the 400, because nobody I know of knows everything
about a 400.)


At one time, I placed an extremely high value on how technical a programmer
was.  But in my experience, I've found that frequently a less technical
person can see the issues around how well the program actually solves a
problem the business has, than a more technical person.

The best solutions that I've found are simple, yet elegant, code that solves
a business problem, in the most cost-effective manner.


I ***know*** we've ALL seen examples where absolutely great code, not only
*didn't* solve a user's problems, but ***made it harder for a user to do
their jobs***.  Or they spend more money on a program than the original
problem they're facing costs...  Most people wouldn't consider these
successful projects.  (I cite the InfoCenter as one such example...  I'm
sure the code behind the project was extremely good.)

If you think, well, *I* don't do that, then I wonder if you're as objective
about your work as your users would be.  *I* know *I* DO do that, when I'm
not careful.  And if you've been in the biz for less time than I have, then
the laws of probability dictate that you are more likely to make this
mistake, on any given project, than I am.  Not a rule, but that's the
probability.  (Didn't get to visit the age/experience thread on RPG-L, but
that probably sums up my views on the subject.)

If writing GREAT software was THAT easy (or at least software the users are
not constantly complaining about ;-)... Well, then everyone could do it.
You wouldn't see a factor of 10 to 20 times, between the top and the bottom.

I think this becomes a fair bit easier when things compile the first or
second time, and work as planned the first or second run.  Things start
clicking into place.  You address more problems with simpler solutions.

If done properly, this can become easier to do, because two eyes are better
than one.  Some things are as simple as that, at least in concept.


IM(maybe NS)HO.

jt



| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Leif Svalgaard
| Sent: Monday, December 10, 2001 12:49 AM
| To: midrange-l@midrange.com
| Subject: Re: Two persons per product"
|
|
| From: Brad Jensen <brad@elstore.com>
|
| Brad and Steve (and the many others that will jump on this
| over the next few hours), I have heard all these arguments
| before (pride of ownership, creativeness, etc) and they are
| *precisely* what is wrong with our "profession". I'll compare
| (some will say that I can't) programming a large system as
| akin to producing the engineering blueprints of a major
| building. In order that the blueprints be understandable
| and hence useful now and 20 years from now, there is
| very little room for "creativity" and "personal style". If
| the original creator of a portion of the blueprint leaves
| the project another engineer can and should be able
| to complete the piece without having to start from
| scratch. The pride in your work comes not from being
| original but from executing your job in a professional
| manner. This argument can go on and on and on.