Loading ...
Sorry, an error occurred while loading the content.

Re: Notable YAGNI Violations -- Perl

Expand Messages
  • Jeff Grigg
    ... I ve written plenty of shell-awk-sed-tr scripts. They quickly become a performance and maintenance nightmare. When the alternative is to rewrite these
    Message 1 of 16 , Jan 2, 2004
    • 0 Attachment
      > Asim wrote:
      >> Larry Wall invents Perl because he was too lazy to use awk
      >> [http://www.linuxjournal.com/article.php?sid=3394].

      --- Ron Jeffries <ronjeffries@X...> wrote:
      > There's nothing wrong with creating a tool that you need,
      > and Larry needed it.

      I've written plenty of shell-awk-sed-tr scripts. They quickly become
      a performance and maintenance nightmare. When the alternative is to
      rewrite these scripts into C, as I've done in several cases, one
      quickly realizes that there was a desperate need for "a better awk
      language."

      Larry had some good ideas about string processing, and combined them
      with the features of the most commonly used Unix scripting tools.
      The result proved very useful.

      In fact, much of the power of Perl comes from its extensive
      libraries, which were developed in an evolutionary fashion after the
      language itself. Perl libraries tend, as influenced by Perl culture,
      to be simple and practical -- rather than over engineered to handle
      all theoretical possibilities. (...a common failing, IMHO, of the
      Java community. ;-)
    • Jeff Grigg
      ... 30TenYearsWWW/Story/WelcomeStory.html] ... Take ftp, gopher, and a few other commonly used pre-http protocols. Say, Gosh, wouldn t it be easier if
      Message 2 of 16 , Jan 2, 2004
      • 0 Attachment
        > From: "Asim Jalis" <asim.at.pair.com@y...>
        >> Tim Berners-Lee invents the web to allow high-energy physicists
        >> to share data and abstracts.
        >>
        > [http://info.web.cern.ch/info/Announcements/CERN/2003/04-
        30TenYearsWWW/Story/WelcomeStory.html]

        --- yahoogroups@j... wrote:
        > That was certainly a place where there was a significant
        > problem and user requirement. In fact, the Web is notorious
        > for being someplace which grows incrementally.

        Take ftp, gopher, and a few other commonly used pre-http protocols.
        Say, "Gosh, wouldn't it be easier if scientists (who have much better
        things to do with their time than learn all the quirky commands of a
        bunch of Unix programs) had one client program that gave them access
        to all of this?" Add, "A little text formatting, with some simple
        embedded graphics would be an improvement too -- as many scientific
        papers have graphs, charts, and pictures."

        Pretty soon you end up with something quite like the web browser
        concept.

        I think most of the navigation concept was already there with the
        gopher protocol. (...which my firewall, unfortunately, won't allow
        me to touch. )-: See:
        http://directory.google.com/Top/Computers/Internet/Gopher/

        OK, maybe SGML was a little heavy-handed. Would you prefer an ugly
        hack like Rich Text Format (RTF)? ;-> Do we have any X-roff lovers
        out there? ;->
      • William E Caputo
        ... These are all examples of where the system outgrew its original goal. I can see why some would call this a YAGNI violation -- in each case the programmer
        Message 3 of 16 , Jan 2, 2004
        • 0 Attachment
          Asim Jalis:
          >Here are some notable violations of YAGNI that have made the
          >world a better place:

          >James Gosling invents Java (Oak) to program set-top boxes
          >[http://java.sun.com/features/1998/05/birthday.html%5d.

          >Larry Wall invents Perl because he was too lazy to use awk
          >[http://www.linuxjournal.com/article.php?sid=3394].

          >Tim Berners-Lee invents the web to allow high-energy physicists
          >to share data and abstracts.
          >[http://info.web.cern.ch/info/Announcements/CERN/2003/04-30TenYearsWWW/Story/WelcomeStory.html%5d

          >These are all cases where YAGNI was thrown the wind, and the
          >world is a better place for it.

          These are all examples of where the system outgrew its original goal. I
          can see why some would call this a YAGNI violation -- in each case the
          programmer seems to be adding features beyond what was asked for -- but
          this macro level view is IMO not where one can see (or not see) YAGNI at
          work.

          YAGNI is a micro-level prescription. Its purpose is to prevent speculative
          generalization *at the micro level*

          "well we are only being asked to support SQL Server, but I figure someday
          we might need to support other RDBMS's so let's abstract the entire data
          access connection and querying system. I have this idea how you could
          abstract that because this one time I...".

          That line of reasoning is rarely valuable (the user isn't actually
          connecting to anything other than SQL Server) -- or elegant (the
          programmer guessed what a *future* feature -- not a present one -- would
          need for its implementation).

          At the macro level, we can't see if the code has these types of
          speculations. The features (e.g. the story perspective of what the system
          does) can be as simple or complex as the wishes of the Customer. In each
          of the above examples, the Customer role started getting played by the
          Programmer. In each of these cases, the Programmers in question seemed to
          be better choices as Customers in that they envisioned systems that were
          really needed by their actual Customers -- I wonder how many times the
          programmers have chosen wrong.

          So IMO this is not about YAGNI. The way I view YAGNI is a micro-level
          prescription on speculative generality. It reminds us to generalize only
          when an external feature of the system needs that generalization. IOW Its
          a YAGNI violation if the generalization is there, but the user of the
          system can't access a feature that uses it (because that feature has yet
          to be implemented). That's not the case above, so the above examples are
          just situations where the Programmer played Customer (very common on
          non-XP projects).

          Best,
          Bill

          William E. Caputo
          ThoughtWorks, Inc.
          http://www.williamcaputo.com
          --------
          idia ktesis, koine chresis
        • yahoogroups@jhrothjr.com
          ... From: William E Caputo To: extremeprogramming@yahoogroups.com
          Message 4 of 16 , Jan 2, 2004
          • 0 Attachment
            ----- Original Message -----
            From: "William E Caputo"
            <wecaputo.at.thoughtworks.com@...>
            To: "extremeprogramming@yahoogroups.com"
            <extremeprogramming.at.yahoogroups.com@...>
            Sent: Friday, January 02, 2004 3:35 PM
            Subject: Re: [XP] Notable YAGNI Violations


            > Asim Jalis:
            > >Here are some notable violations of YAGNI that have made the
            > >world a better place:
            >
            > >James Gosling invents Java (Oak) to program set-top boxes
            > >[http://java.sun.com/features/1998/05/birthday.html%5d.
            >
            > >Larry Wall invents Perl because he was too lazy to use awk
            > >[http://www.linuxjournal.com/article.php?sid=3394].
            >
            > >Tim Berners-Lee invents the web to allow high-energy physicists
            > >to share data and abstracts.
            >
            >[http://info.web.cern.ch/info/Announcements/CERN/2003/04-30TenYearsWWW/Stor
            y/WelcomeStory.html]
            >
            > >These are all cases where YAGNI was thrown the wind, and the
            > >world is a better place for it.
            >
            > These are all examples of where the system outgrew its original goal. I
            > can see why some would call this a YAGNI violation -- in each case the
            > programmer seems to be adding features beyond what was asked for -- but
            > this macro level view is IMO not where one can see (or not see) YAGNI at
            > work.
            >
            > YAGNI is a micro-level prescription. Its purpose is to prevent speculative
            > generalization *at the micro level*
            >
            > "well we are only being asked to support SQL Server, but I figure someday
            > we might need to support other RDBMS's so let's abstract the entire data
            > access connection and querying system. I have this idea how you could
            > abstract that because this one time I...".
            >
            > That line of reasoning is rarely valuable (the user isn't actually
            > connecting to anything other than SQL Server) -- or elegant (the
            > programmer guessed what a *future* feature -- not a present one -- would
            > need for its implementation).
            >
            > At the macro level, we can't see if the code has these types of
            > speculations. The features (e.g. the story perspective of what the system
            > does) can be as simple or complex as the wishes of the Customer. In each
            > of the above examples, the Customer role started getting played by the
            > Programmer. In each of these cases, the Programmers in question seemed to
            > be better choices as Customers in that they envisioned systems that were
            > really needed by their actual Customers -- I wonder how many times the
            > programmers have chosen wrong.
            >
            > So IMO this is not about YAGNI. The way I view YAGNI is a micro-level
            > prescription on speculative generality. It reminds us to generalize only
            > when an external feature of the system needs that generalization. IOW Its
            > a YAGNI violation if the generalization is there, but the user of the
            > system can't access a feature that uses it (because that feature has yet
            > to be implemented). That's not the case above, so the above examples are
            > just situations where the Programmer played Customer (very common on
            > non-XP projects).
            >
            > Best,
            > Bill

            Good set of points. We also tend to forget that while Perl was
            the brainchild of Larry Wall, he took user (read customer) input
            from a relatively early date, and both the Web and Java started
            out as official projects with an official charter and direction.
            Larry Wall is now redesigning Perl *from customer input.*

            Very few if any *successful* programming languages and
            systems adhered to their creator's original vision without
            extensive feedback from the people actually using them.
            Of the three mentioned, Java is probably the most resistant
            to user feedback.

            John Roth

            >
            > William E. Caputo
            > ThoughtWorks, Inc.
            > http://www.williamcaputo.com
            > --------
          • Asim Jalis
            ... Okay. ... Was the more elegant design something that happened by chance or does the programmer playing the customer make it more likely. Another way to
            Message 5 of 16 , Jan 2, 2004
            • 0 Attachment
              William E Caputo wrote:
              > Asim Jalis wrote:
              > > Here are some notable violations of YAGNI that have made the
              > > world a better place: James Gosling invents Java (Oak) to
              > > program set-top boxes. Larry Wall invents Perl because he was
              > > too lazy to use awk. Tim Berners-Lee invents the web to allow
              > > high-energy physicists to share data and abstracts.
              >
              > These are all examples of where the system outgrew its original
              > goal. I can see why some would call this a YAGNI violation --
              > in each case the programmer seems to be adding features beyond
              > what was asked for -- but this macro level view is IMO not
              > where one can see (or not see) YAGNI at work.
              >
              > YAGNI is a micro-level prescription. Its purpose is to prevent
              > speculative generalization *at the micro level*

              Okay.

              > In each of the above examples, the Customer role started
              > getting played by the Programmer. In each of these cases, the
              > Programmers in question seemed to be better choices as
              > Customers in that they envisioned systems that were really
              > needed by their actual Customers --

              Was the more elegant design something that happened by chance or
              does the programmer playing the customer make it more likely.
              Another way to look at these situations might be that the
              customer requirements were really vague which gave the
              programmers a lot more leeway, or wiggle room, to play with the
              parameters, and create something elegant. They did not reduce the
              degrees of freedom like detailed requirements might.

              > I wonder how many times the programmers have chosen wrong.

              Judgement evolves through making lots of mistakes.



              Asim
            • William E Caputo
              ... You listed three projects. Are these typical of what happens when programmers are given unlimited budget and leeway? ... Perhaps, but does it follow that
              Message 6 of 16 , Jan 2, 2004
              • 0 Attachment
                Asim Jalis:
                >Was the more elegant design something that happened by chance or
                >does the programmer playing the customer make it more likely.

                You listed three projects. Are these typical of what happens when
                programmers are given unlimited budget and leeway?

                >Another way to look at these situations might be that the
                >customer requirements were really vague which gave the
                >programmers a lot more leeway, or wiggle room, to play with the
                >parameters, and create something elegant. They did not reduce the
                >degrees of freedom like detailed requirements might.

                Perhaps, but does it follow that providing lots of wiggle room is the best
                way to get a valuable product for those paying the bills?

                >> I wonder how many times the programmers have chosen wrong.
                >Judgement evolves through making lots of mistakes.

                If it wasn't their money to make lots of mistakes with, then were they
                correct in doing so? Or perhaps did all concerned just get lucky?

                Let's grant that in these three cases, these three designers, left to
                their own devices made good customers (I think that's debatable as each
                went and built something other than they were asked to do, but OK let's
                grant that), then all we have shown is something that a lot of XP'rs
                forget -- but is (or still should be) core to the approach we advocate:

                People are more important than process.

                These three guys built useful products. As an Agilist, I am willing to bet
                they have a propensity to design useful products -- and that further,
                their success is not primarily because of what process they use.

                XP doesn't provide wiggle room on requirements -- it says the Customer
                decides -- because the goal of XP is not to maximize the chances of
                discovering elegant, ground-breaking software, but to strike a good
                balance between the Programmer's desire to be creative, and Customer's
                desire to manage risk -- something that is much more commonly a problem in
                professional software development.

                One more reminder that XP is not a silver bullet, just an elegant solution
                to a common problem.

                Best,
                Bill

                William E. Caputo
                ThoughtWorks, Inc.
                http://www.williamcaputo.com
                --------
                idia ktesis, koine chresis
              • Fred Ballard
                It s always bothered me that customers may not know what they want. That the role of invention can be directly or indirectly excluded from designs. I think, in
                Message 7 of 16 , Jan 3, 2004
                • 0 Attachment
                  It's always bothered me that customers may not know what they want. That the
                  role of invention can be directly or indirectly excluded from designs.

                  I think, in essence, customers were asking for the web, but nobody specified
                  it until Tum Berners-Lee specified it -- that customers and programmers
                  specified solutions that effectively excluded solutions as elegant as the
                  web. (I think customers and programmers are still doing this. Your company
                  can buy a behemouth content management system and spend years installing it
                  and training everyone how to use it, but YAGNI. Instead you could use the
                  power of the web by showing everyone weblogs, then give them one, and use a
                  good search engine to mine the content.)

                  David Parnas used the example of specifying the first missile guidance
                  system, the first automated navigation system. If you went with the common
                  way navigation was being done then, you'd end up with a system that used an
                  mechanized astrolab, looking at the sun and the stars, but YAGNI. Instead,
                  someone (inspired by dead reckoning?) came up with the inertial guidance
                  system.

                  Double entry bookkeeping is another example.

                  As with Java, Perl, and the Web, truly inventive solutions often solve more
                  problems than were initially envisioned.

                  Fred



                  Asim Jalis wrote:
                  > William E Caputo wrote:
                  > > Asim Jalis wrote:
                  > > > Here are some notable violations of YAGNI that have made the
                  > > > world a better place: James Gosling invents Java (Oak) to
                  > > > program set-top boxes. Larry Wall invents Perl because he was
                  > > > too lazy to use awk. Tim Berners-Lee invents the web to allow
                  > > > high-energy physicists to share data and abstracts.
                  > >
                  > > These are all examples of where the system outgrew its original
                  > > goal. I can see why some would call this a YAGNI violation --
                  > > in each case the programmer seems to be adding features beyond
                  > > what was asked for -- but this macro level view is IMO not
                  > > where one can see (or not see) YAGNI at work.
                  > >
                  > > YAGNI is a micro-level prescription. Its purpose is to prevent
                  > > speculative generalization *at the micro level*
                  >
                  > Okay.
                  >
                  > > In each of the above examples, the Customer role started
                  > > getting played by the Programmer. In each of these cases, the
                  > > Programmers in question seemed to be better choices as
                  > > Customers in that they envisioned systems that were really
                  > > needed by their actual Customers --
                  >
                  > Was the more elegant design something that happened by chance or
                  > does the programmer playing the customer make it more likely.
                  > Another way to look at these situations might be that the
                  > customer requirements were really vague which gave the
                  > programmers a lot more leeway, or wiggle room, to play with the
                  > parameters, and create something elegant. They did not reduce the
                  > degrees of freedom like detailed requirements might.
                  >
                  > > I wonder how many times the programmers have chosen wrong.
                  >
                  > Judgement evolves through making lots of mistakes.
                  >
                  >
                  >
                  > Asim
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to:
                  extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  >
                  > Yahoo! Groups Links
                  >
                  > To visit your group on the web, go to:
                  > http://groups.yahoo.com/group/extremeprogramming/
                  >
                  > To unsubscribe from this group, send an email to:
                  > extremeprogramming-unsubscribe@yahoogroups.com
                  >
                  > Your use of Yahoo! Groups is subject to:
                  > http://docs.yahoo.com/info/terms/
                  >
                  >
                  >
                • Amir Kolsky
                  I think that HTTP is a bad protocol. It s not bad because it wasn t a YAGNI solution (XP is YAGNI). It s bad because it grew incrementally and unchecked -- no
                  Message 8 of 16 , Jan 3, 2004
                  • 0 Attachment
                    I think that HTTP is a bad protocol. It's not bad because it wasn't a
                    YAGNI solution (XP is YAGNI). It's bad because it grew incrementally and
                    unchecked -- no refactoring. HTTP is really a family of protocols in
                    one. In fact, if it was done (along with HTML) non-YAGNI, we might have
                    been in a better position right now...

                    Amir Kolsky
                    XP& Software
                    www.xpandsoft.com

                    ]-----Original Message-----
                    ]From: William E Caputo [mailto:wecaputo@...]
                    ]Sent: Friday, January 02, 2004 10:35 PM
                    ]To: extremeprogramming@yahoogroups.com
                    ]Subject: Re: [XP] Notable YAGNI Violations
                    ]
                    ]
                    ]Asim Jalis:
                    ]>Here are some notable violations of YAGNI that have made the world a
                    ]>better place:
                    ]
                    ]>James Gosling invents Java (Oak) to program set-top boxes
                    ]>[http://java.sun.com/features/1998/05/birthday.html%5d.
                    ]
                    ]>Larry Wall invents Perl because he was too lazy to use awk
                    ]>[http://www.linuxjournal.com/article.php?sid=3394].
                    ]
                    ]>Tim Berners-Lee invents the web to allow high-energy physicists to
                    ]>share data and abstracts.
                    ]>[http://info.web.cern.ch/info/Announcements/CERN/2003/04-30Ten
                    ]YearsWWW/
                    ]>Story/WelcomeStory.html]
                    ]
                    ]>These are all cases where YAGNI was thrown the wind, and the
                    ]world is a
                    ]>better place for it.
                    ]
                    ]These are all examples of where the system outgrew its
                    ]original goal. I
                    ]can see why some would call this a YAGNI violation -- in each case the
                    ]programmer seems to be adding features beyond what was asked
                    ]for -- but
                    ]this macro level view is IMO not where one can see (or not
                    ]see) YAGNI at
                    ]work.
                    ]
                    ]YAGNI is a micro-level prescription. Its purpose is to prevent
                    ]speculative
                    ]generalization *at the micro level*
                    ]
                    ]"well we are only being asked to support SQL Server, but I
                    ]figure someday
                    ]we might need to support other RDBMS's so let's abstract the
                    ]entire data
                    ]access connection and querying system. I have this idea how you could
                    ]abstract that because this one time I...".
                    ]
                    ]That line of reasoning is rarely valuable (the user isn't actually
                    ]connecting to anything other than SQL Server) -- or elegant (the
                    ]programmer guessed what a *future* feature -- not a present
                    ]one -- would
                    ]need for its implementation).
                    ]
                    ]At the macro level, we can't see if the code has these types of
                    ]speculations. The features (e.g. the story perspective of what
                    ]the system
                    ]does) can be as simple or complex as the wishes of the
                    ]Customer. In each
                    ]of the above examples, the Customer role started getting played by the
                    ]Programmer. In each of these cases, the Programmers in
                    ]question seemed to
                    ]be better choices as Customers in that they envisioned systems
                    ]that were
                    ]really needed by their actual Customers -- I wonder how many times the
                    ]programmers have chosen wrong.
                    ]
                    ]So IMO this is not about YAGNI. The way I view YAGNI is a micro-level
                    ]prescription on speculative generality. It reminds us to
                    ]generalize only
                    ]when an external feature of the system needs that
                    ]generalization. IOW Its
                    ]a YAGNI violation if the generalization is there, but the user of the
                    ]system can't access a feature that uses it (because that
                    ]feature has yet
                    ]to be implemented). That's not the case above, so the above
                    ]examples are
                    ]just situations where the Programmer played Customer (very common on
                    ]non-XP projects).
                    ]
                    ]Best,
                    ]Bill
                    ]
                    ]William E. Caputo
                    ]ThoughtWorks, Inc.
                    ]http://www.williamcaputo.com
                    ]--------
                    ]idia ktesis, koine chresis
                    ]
                    ]
                    ]
                    ]
                    ]To Post a message, send it to: extremeprogramming@...
                    ]
                    ]To Unsubscribe, send a blank message to:
                    ]extremeprogramming-unsubscribe@...
                    ]
                    ]ad-free courtesy of objectmentor.com
                    ]
                    ]Yahoo! Groups Links
                    ]
                    ]To visit your group on the web, go to:
                    ]http://groups.yahoo.com/group/extremeprogramming/
                    ]
                    ]To
                    ]unsubscribe from this group, send an email to:
                    ]extremeprogramming-unsubscribe@yahoogroups.com
                    ]
                    ]Your use of Yahoo! Groups is subject to:
                    ]http://docs.yahoo.com/info/terms/
                    ]
                    ]
                    ]
                  • Ron Jeffries
                    ... Huh? What do you mean by non-YAGNI? Why didn t we just refactor it? Ron Jeffries www.XProgramming.com My advice is to do it by the book, get good at the
                    Message 9 of 16 , Jan 3, 2004
                    • 0 Attachment
                      On Saturday, January 3, 2004, at 3:26:13 PM, Amir Kolsky wrote:

                      > I think that HTTP is a bad protocol. It's not bad because it wasn't a
                      > YAGNI solution (XP is YAGNI). It's bad because it grew incrementally and
                      > unchecked -- no refactoring. HTTP is really a family of protocols in
                      > one. In fact, if it was done (along with HTML) non-YAGNI, we might have
                      > been in a better position right now...

                      Huh? What do you mean by non-YAGNI? Why didn't we just refactor it?

                      Ron Jeffries
                      www.XProgramming.com
                      My advice is to do it by the book, get good at the practices, then do as
                      you will. Many people want to skip to step three. That's OK too.
                    • Amir Kolsky
                      ]Huh? What do you mean by non-YAGNI? Why didn t we just refactor it? I mean that HTTP was built piecemeal, with functionality added as it was needed. It was
                      Message 10 of 16 , Jan 3, 2004
                      • 0 Attachment
                        ]Huh? What do you mean by non-YAGNI? Why didn't we just refactor it?

                        I mean that HTTP was built piecemeal, with functionality added as it was
                        needed. It was never cleaned up tho... Why it wasn't refactored is
                        probably because it was used too much to pull out and refactor.

                        HTTP advanced but it always retained all the old junk. There are
                        attempts to undo some of the HTTP mess in things like SOAP...
                      Your message has been successfully submitted and would be delivered to recipients shortly.