From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,e2e7624a3542400a X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,e2e7624a3542400a X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,e2e7624a3542400a X-Google-Attributes: gid1014db,public X-Google-Thread: fc89c,e2e7624a3542400a X-Google-Attributes: gidfc89c,public X-Google-Thread: 1089ad,e2e7624a3542400a X-Google-Attributes: gid1089ad,public From: Bob Stout Subject: Re: Software reuse Date: 1996/08/15 Message-ID: X-Deja-AN: 174448145 x-nntp-posting-host: freddie.wins.compaq.com sender: news@twisto.eng.hou.compaq.com (System Administrator) references: <320EF9AB.42877E5C@sh.bel.alcatel.be> <3210AA4B.2578@tus.ssi1.com> <32133648.4CBA@la.ccfo.carel.fi> content-type: text/plain; charset=us-ascii organization: Compaq Computer Corp. mime-version: 1.0 newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada,comp.lang.vhdl x-mailer: Mozilla 1.22 (Windows; I; 32bit) Date: 1996-08-15T00:00:00+00:00 List-Id: Ari Lukumies 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.