RE: Unix philosophy under the gun?

[Thornley, David]

> -----Original Message-----
> From: Ralph Mack [mailto:address@hidden
> Sent: Thursday, August 02, 2001 11:23 PM
> To: address@hidden
> Subject: RE: Unix philosophy under the gun?
> 
> 
> > No, I just believe in building tools that can work together and that
> > each do one job to the best of their ability....  If you want a tool
> > that slices and chops, but not dices, then you can write a little
> > program that hooks a slicing tool and a chopping tool 
> together in the
> > way you find most desirable.  
> > Please see:  "UNIX Style, or cat -v Considered Harmful", by 
> Rob Pike;
> 
> Greg, 
> 
> This requires you to take the time out from being a tool user to 
> becoming a toolsmith, no? It means you have to take the time to become
> facile in the "glue" languages for your environment so you can whip 
> things together as needed. 
> 
It is not hard to learn enough Perl to slap things together, and that's
very multi-platform.  (I haven't written anything in shell script for
years.)
Nor is it necessary for everybody in a shop to be a toolsmith.  The Unix
way of doing things seems to work very well with a relatively small (but
greater than zero) number of toolsmiths.

> Most of the developers that I know who take this approach are 
> the kind who are rabid about their craft and pack an Automake manual 
> in their baggage for a beach trip. The developers who write solid 
> code from 8-5 and then go home to immerse themselves in their 
> families, 
> forgetting they know anything about programming until they 
> get to work 
> in the morning, simply don't have time or the interest. 
> 
If all the people in your organization are 8-5 and have no particular
interest in improving their abilities, you're in trouble.  Period.

> I am rabid, but I can't seriously contemplate a work style 
> that doesn't 
> work as well for solid developers who aren't rabid. When I 
> move on, as 
> all developers must every few years, someone will need to maintain 
> whatever I leave behind. I owe it to them to ensure that any 
> mechanism 
> I use has a negligible learning curve. The point is actually 
> rather moot - 
> there is no time to build such things anyway. It requires 120% of my 
> available time just to meet my current P1 commitments.
> 
If your company hires only "solid developers" by the definition you're
using, and doesn't make sure they have people around who are good by
my definition, it's in trouble.  I don't see that "negligible learning
curve" makes sense, as most things that are worth doing can't be
trivially understood.  Most of what you leave behind will require some
sort of maintenance, and maintenance typically involved understanding
what has already been done.

As far as your time commitments go, it reminds me of the saying "There's
never time to do it right, but always time to do it over."    While I
understand deadlines and the extreme importance in some cases of time-
to-market, headlong coding is not a very reliable way to construct
quality software, and some attention to fundamentals is usually better
in terms of quality and in terms of time.  In many cases, this means
hiring one person who is not tasked with cranking out the application code
but rather with helping other people crank out code.

> The do-it-yourself philosophy common to Unix only works if software 
> is your life, not just your job, and if your job affords you time 
> to do something that doesn't directly drive aggressive delivery plans 
> forward. Since I started in the eBusiness software vendor arena, I 
> haven't personally met a professional software developer face to face 
> who has the leisure to pursue this kind of approach on their day job.
> 
It works if your job is to provide what is needed to effectively drive
aggressive delivery plans.  Creating software is a bit more complex than
butchering hogs, and it is usually desirable to have some specialization
of function.  Taking somebody out of the horde and making that person
support the horde can easily shorten time to delivery.

> As it stands today, just about everything that you do with CVS aside
> from checkout, update, and commit to head requires a level of study 
> and experimentation that is prohibitive for the kind of shops I am 
> familiar with. I think I've now been through most of the 
> learning curve
> but it took me a couple of months. Training time for busy people is 
> measured in minutes or at worst hours.
> 
The checkout/commit/update is enough to be productive with CVS if you don't
use branches.  If you do, then somebody can create a script to automate
merging in a way that is useful for your organization.  If the developers
don't understand source code management, they aren't going to learn it in
minutes, and you'd have the training time problem in any case.  If they
do, but don't understand either CVS or the way your organization does it,
then add the necessary additional functionality in Perl or some more
aesthetically
pleasing form, and teach that to them.

You can learn and use CVS out of the box for simple things within minutes.
If you are going to do more complicated things, you can either pay money
for a commercial system or pay money for somebody (perhaps internal) to
customize CVS for your use.

Any industry that practices code cranking without infrastructure
development,
and believes that money spent elsewhere will produce instant gratification
but that internal resources must go into the code cranking, is setting
itself up for a shakeout.