Re: Software reuse

[Bob Stout <bobstout@neosoft.com>]

Ari Lukumies <Ari.Lukumies@la.ccfo.carel.fi> wrote:

>> I heard a talk by Plauger once where he suggested there was a fundamental
>> difference in mindset between the two types of programmers (this is true >> no matter what you call the two groups, applications =
vs. libraries,
>> applications vs. systems, etc.) I tend to agree with this and believe it >> has a lot to do with an individual's most natural way=
 of deconstructing a
>> problem. The top-down people are apps programmers, the bottom-up people >> are library/systems programmers.

>This is a very interesting problem that I've been wondering about for a >long time, since I've been working for years in (agreed, s=
omewhat small)
>projects involving 10 to 30 programmers. It seems that many programmers do >not "see" that some particular piece of code could be r=
eused (when taken >out of the current context with perhaps some modification) and yet some do >(there are not as many of these peopl=
e, though, it seems). It seems that >this does not have anything to do with the educational level, position or >experience. One thin=
g I've recognized is that the people that write with >reusable code in mind (even when they would be writing a program to do >someth=
ing very dedicated) often (but not all of them) play chess, too. So >it might have something to do with pattern recognition or somet=
hing like >that.

Possibly, but I think not. I'm definitely a library programmer by nature, 
but I'm only a mediocre chess player. I am, however, *really* good at 
Scrabble. ;-) Seriously, though, the same principle would tend to apply. To 
be good at Scrabble, you have to be good at visualizing complex interlocking 
systems. (Hint: In Scrabble, the good players aren't always the ones who can 
come up with the big obscure words, but the ones who can drop 2 letters into 
a crowded board and get credit for 4-6 interlocking new words.)

>About the top-down (apps programmers) vs. bottom-up (lib/sys programmers), >I don't quite agree. I've seen many people start off wi=
th the general >problem, breaking it down to smaller pieces and resulting to well reusable >code.

Think back on the programmers you've known... The art/science of program 
design involves deconstruction of a problem. In all cases, you look at the 
big picture, then iterate until you have a defined set of components. Some 
people can begin designing a program with little more than a picture of the 
user interface. Most CASE tools work well with this mindset. These people 
are applications programmers.

Some people, though, can't really begin to think in terms of an overall 
design until they've deconstructed down to the component level. These people 
are library programmers. As you say, education, experience, etc. are 
secondary to mindset. It's also interesting that there's a really spiffy 
CASE tool called Utah that works backwards from others in that you design 
the data first before designing the screens around it. I would say that this 
is designed by and for this second class of programmers. Naturally, I think 
it's really a great tool.

>Also, I've seen many people starting with some small piece of code >(reusable) and building on top of it, still retaining as much r=
eusability >as possible.

Been there, done that! ;-) Had an idea of something really elementary that 
struck me as useful and built it. Afterwards, other people found it to be as 
useful as I had suspected.

>Finding out why these distinguished groups of people are distinguishable >would result to better ways to divide the work between pe=
ople (resource >allocation). I've seen some projects where the writing of common parts were >given to people who didn't have the "in=
sight" to do it properly, or where >some people able to write reused code where given tasks that did not need >(or needed very littl=
e) generalization. This always slowed the projects >down somewhat. As a designer/programmer/analyst and teacher of computing >and pr=
ogramming, this problem is very close to my heart, not to mention >that it might add something to our understanding about how a huma=
n mind >works. I think there must be many people with many ideas about this out >there. Am I correct?

One of the points of Plauger's talk seemd to be encouraging organizations 
that could afford to keep both type of programmers on staff, to identify 
them and treat them as equally valuable, but different, resources.

It's something that I've spent a lot of time observing and thinking about. 
As a software manager, I've been in positions to try to identify the skill 
sets and mindsets to do the best job in the least time. As a programmer, 
I've always wondered why I could write library code so easily that everyone 
seemed to like, yet I sweat bullets every time I have to work with some 
"visual" tool doing top-down CASE design. As you note, there doesn't seem to 
be a 50-50 split, either - good library programmers are hard to find. A 
causal look at things like gets() from the standard library tells you that a 
lot of people have written libraries without much thought!

As I final note, I'd add that in a discussion of this topic over in the 
FidoNet C_Echo recently, someone suggested, based on experience, that 
there's a built-in bias in the job and education market against the people 
who have an aptitude for library/system programming rather than application 
programming.