Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • "Making Tons Of Money By Writing Down Linux's Internet Based Design And Implementation Method (But Without The Internet Part) And Telling Businesspeople It's Really Cool (Like OO)"
    • They got the Linux kernel wrong, then, as "refactoring" should be called "throwing it all away and starting over from scratch every release" and "automated testing" should be "ask users to debug it for you and berate them for not reading the development mailing list religiously". :)

      Lots of open source projects succeed because their leaders are exceedingly brilliant at project management without discipline. Lots more projects succeed because there's a point at which you can throw many, many warm bodies at

      • Free software is worker control. This means:

              1) workers aren't forced to work on the boss's bad ideas -- the bad ideas
                    have to attract the workers on their own (see java stuff :)
              2) no boss deadline pressure
              3) no boss backward-compatibility pressure

        These three things are, in my experience, responsible for the bulk of stupidity
        in boss-run proprietary software organizations.

        Now, of course,
        • But how can you say the Perl 5 guts don't have backward-compatibility pressure? :)

          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
          • Of course there is backward compatibility pressure -- but it doesn't compare to
            a proprietary shop, where the boss says "We can't lose this big account -- so
            don't change anything, anywhere, that might cause them problems."

            One of the reasons that proprietary software sucks in general is that the
            programmers are first rushed, then told not to change anything. Developers of
            free software have much more freedom to say "The next major version will change
            things; stick with the old version if you want; fork the pro
            • Right, open source software is less affected by economic pressure. That's probably the largest pressure that leads to an immature release, but it's not the only one.

              (Sidebar: This weekend, Ward Cunningham and I discussed the idea that open source's biggest advantage is not necessarily improved communication, it's scalability in the sense that a thousand hackers can throw themselves at a problem and a few might eventually come up with a solution. I'll continue to argue that practicing a little m

              • W.R.T. "scalability" -- thousands of hackers are not needed, and generally not
                involved. It takes only a few really good ones to solve a particular problem.
                And those really good hackers produce much better work when they have control.

                In my experience it is proprietary shops that use the "hordes of programmers"
                approach, trying to crank out software quickly by throwing lots of mediocre
                programmers at the problem. The "wizard in the tower" approach, though
                sometimes slower, gets better results.

                Now, one could bring up the linux kernel as a counter-example, but even there
                there are a few main programmers for each subsystem. Besides, I would wait for
                2.6 to work well in practice before holding up linux as an example of good
                development methodology.