SPUG: There's only one right way to do it? (was: software libertarianism (was: Scope question))

[Richard Anderson]

This idea of TOORWTDI (there's only one right way to do it) is contrary to
the design of Perl and what we know about computer science.  The classic
algorithm books (Knuth, Sedgewick) give many examples of {sorting |
searching | optimization | etc.} algorithms, all of which solve the problem
satisfactorily and each of which is optimum under the right circumstances.

I'd like to propose an alternative view of solutions to coding problems.
There is a small class of solutions that are Nearly Optimum in the sense of
maximizing certain qualities (conformance to spec, usability,
maintainability, flexibility, conformance to standards, etc.) while
minimizing other qualities (bugs, run/response time, consumption of system
resources, programming effort, time-to-market, etc.).  There is a larger
class of solutions that are O.K. But Not Great that score lower on the
optimization scale, an even larger class of Really Crappy solutions and a
practically infinite class of Doesn't Work "solutions".  I have omitted an
Optimum class because, for other than trivial problems, getting a group of
programmers to agree that a body of code is optimum down to a line-by-line
basis will never happen.

The trick, of course, is selecting the optimization criteria and weighting
factors.  The programmers, product managers, CIO and end user community will
all disagree on this.  What makes software development so interesting is the
strategic challenges of managing the technical and organizational problems
simultaneously and the tactical challenges of translating this into the
decisions we make as we write code.  The project cancellation cited by Mr.
Pommert might have been averted if the programming team had weighted the
time-to-market factor more heavily in their actions.  Or not.

Cheers,
Richard
richard at richard-anderson.org
www.richard-anderson.org
www.raycosoft.com
----- Original Message -----
From: "dancerboy" <dancerboy at strangelight.com>
To: <spug-list at pm.org>
Sent: Friday, June 14, 2002 4:43 PM
Subject: RE: SPUG: software libertarianism (was: Scope question)


> At 3:44 pm -0700 2002-06-13, Bradley E. Young wrote:
> >jason,
> >
> >Changing scope (poor management) killed the project, based on his
> >statements.  The language didn't have anything to do with it.
>
> Of course I don't actually know the details of what killed this
> project -- most likely it was a combination of factors, with choice
> of language being one of them, though not necessarily the most
> significant.  My point was that, if one is feeling uncharitable (as
> apparently I was when responding to that post) one could easily
> interpret that post as a list of *excuses*, blaming management for a
> failure that had more to do with the developers.  Yes, the OP
> *claimed* that the death of the project was due entirely to
> management, but "reading between the lines" one could easily come to
> a different conclusion.
>
> BTW, it's somewhat unreasonable to complain that a project was killed
> by "changing specs".  Specs *always* change!  Part of one's job as a
> developer is to create an architecture that's flexible enough to
> accommodate changing specs.  Yes, there are reasonable, minor spec
> changes and unreasonable, radical spec changes.  But part of my point
> is that working in a language like Java can make it much more likely
> that you'll be able to accommodate even radical spec changes in
> large-scale applications.
>
> >
> >I still haven't seen anything that you can point to that offers even
> >a whit of proof that Perl is less capable than, say, Java for large
> >scale projects.
>
> Based on the (mostly constructive) criticisms people have made,
> here's my new, improved take on the Java vs. Perl thing:
>
> It seems to me that there are essentially two different kinds of
> solutions to any coding problem:  there's the Correct way, and
> there's the Clever Shortcut.  (I'm not going to try to define exactly
> what those terms mean; and there are, of course, gray areas.  But I
> think anyone who's been coding for any length of time will understand
> intuitively what I'm talking about.)
>
> Java is designed to encourage Correct solutions.  Most Clever
> Shortcuts are difficult or impossible to code in Java.  Perl, on the
> other hand, is the Clever Shortcut language par excellence.  It's
> *very* easy to code Clever Shortcuts in Perl.  However, Perl is also
> reasonably good at Correct solutions as well, *if* the developers
> choose to use it that way.
>
> Now understand that Clever Shortcuts are not necessarily Bad: they
> are *shortcuts*, which means that they do speed things up (usually
> development time, but sometimes Clever Shortcuts are used to reduce
> system resource usage instead).  Whether to use a Correct solution or
> a Clever Shortcut is really an optimization problem, based on the
> following observations:
>
> * The advantages of Clever Shortcuts (decreased resource usage,
> whether those resources are system resources or development
> resources) relative to the corresponding Correct solutions tend to
> increase linearly with code size.
>
> * Correct solutions and Clever Shortcuts are both apt to contain bugs.
>
> * The difficulty in finding and correcting bugs in Correct solutions
> tends also to increase linearly with code size.
>
> * The difficulty in finding and correcting bugs in Clever Shortcuts
> tends to increase *geometrically* (or perhaps even exponentially)
> with code size.
>
> So, for small applications, Clever Shortcuts are clearly
> advantageous.  For large applications, Clever Shortcuts become a
> nightmare.  And the larger the application, the less room there is
> for the occasional Clever Shortcut here and there in the code.
>
> The problem is, most developers (myself included) find it very
> difficult to eschew Clever Shortcuts altogether.  When faced with
> some specific problem that seems trivially solvable with a Clever
> Shortcut, but for which a Correct solution would be a real
> pain-in-the-ass, most of us will give in to temptation and use the
> Clever Shortcut "just this once". (One little global variable isn't
> going hurt anything, right?)  But with large projects, these little
> deviations from Correctness have a way of adding up, until an
> originally clean and tidy architecture becomes a jury-rigged mess.
> Java is sort an answer to the Lord's Prayer, as applied to software
> development: "lead us not into temptation, but deliver us from
> evil..."
>
> Now, if you can find a team of Perl programmers who are able and
> willing to code everything using nothing but Correct solutions, whom
> you can depend on never to indulge in Clever Shortcuts, then building
> a large-scale application in Perl might work just as well as doing it
> in Java.  But 1) such developers are hard to find, and 2) what this
> really means is that you need your developers to code in Perl *as if*
> they were coding in Java.  And if you're going to use Perl *as if* it
> were Java, then... why not just use Java?
>
> (And just to clarify: I never said that you *couldn't* code
> large-scale application in Perl, only that it was a poor choice in
> terms of the development resources needed.  Of course it's *possible*
> to code a large-scale application in Perl.  You can code a
> large-scale application in assembler, given enough time, developer
> resources, and masochism.  That doesn't mean it's a smart choice.)
>
> -jason
>
>
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
>       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
>   Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
>  For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
>      Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org
>
>


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org