Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Arg! (Score:3, Interesting)

    I've got a paper copy of a lot of that. Part of my study a few years ago in a project management unit. The unit that got my vote as wankiest unit. Not just atrocious academic writing, but management writing too.

    It's scary stuff.
    --
      ---ict / Spoon
    • Re:Arg! (Score:5, Insightful)

      by gnat (29) on 2003.06.30 1:16 (#21550) Journal
      I had an interesting talk at YAPC with someone who's doing a PhD in software management. He pointed out that software management is trying to do what people management does: obtain consistent quality through well-specified standardized processes. They're trying to get away from relying on brilliant programmers, in other words.

      I pointed out, and he agreed, that it's yet to be shown to actually work. It's one thing to take anybody and have them operate the deep fryer to produce a McNugget indistinguishable from any other, but software is a completely different kettle of fish. Err, chicken. Err, software. I've worked with fuckwits for whom no amount of process would help, because they just don't have the ability. I've worked with geniuses who can see elegant solutions that no process could come up with.

      On a similar note, I'm still quite astonished by the games industry's reliance on last-minute crunches. Every game generally requires a month or more of 18+ hour days from programmers and artists. Every game. You cannot go to the shelves of Best Buy and find a popular computer game that was not created in this fashion.

      And yet every software management book you read says this doesn't work. Programmers burn out. You should never ever design a schedule that includes such a crunch. But the games industry breaks this rule every time, and still survives. How the buggery do they do it?

      Is it the economics? Does the sheer number of shekels from a successful game mean that even a programmer's cut is enough to make up for the torture? Do they not have any employees over 30? I don't know, but it's mighty curious.

      --Nat

      • He pointed out that software management is trying to do what people management does: obtain consistent quality through well-specified standardized processes.

        Remember that programming is a craft, so forget what the b-school types tell you about management. Look at how carpenters self-manage.

        In the olden days, when there was a progression from apprentice to journeyman to carpenter to master carpenter, there was no set pace to advancement. There was no expectation that you deserved a higher status sim

        • Re:Arg! (Score:2, Informative)

          In the olden days, when there was a progression from apprentice to journeyman to carpenter to master carpenter...
          Hmm...that sort of thing seems to mirror Advogato's trust metric.
          --

          ------------------------------
          You are what you think.
      • But the games industry breaks this rule every time, and still survives. How the buggery do they do it?

        In one episode of Futurama, Zapp Branigan describes how he defeated a legion of killer androids. All it took was throwing wave after wave of troops at the androids until their internal counters overflowed. The androids shut down.

        I'm starting to wonder if the people who think software engineering will work "if it's just done right" even have counters.

        • In another episode of Futurama, Zapp Branigan attempts to defeat the alien mothership from Omicron Persei 8 by launching wave after wave of ships in an attempt to clog up the alien "Death Ray".

          Hm. I think I see a pattern here. All problems can be solved if you have an infinite supply of troops to send on suicide missions. :-)

  • Martin Fowler has taken a look [martinfowler.com] and doesn't like what he sees...

    -Dom

    • Well duh. That's like Dave Rolsky taking a look at "101 Ways to Torture Bunny Rabbits" and not liking what he sees. Fowler's an XP low-process guy. The SWEBOK is all about process.

      --Nat

      • While I appreciate being used as an analogy, I'd hope that pretty much anyone who looked at "101 Ways to Torture Bunny Rabbits" would dislike such a thing. I doubt I'm unique in this respect ;)
      • Oh, I agree. But more than I care about either lots of process or little process, my main complaint from reading about it is that it might be forced onto people as the One True Way. I guess I was alarmed by reading about it being made into some kind of "legal" thing. Not that it'd probably affect me as a non-US citizen.

        -Dom

        P.S. Bunny make good pie!

      • Well, that's an unfair dismissal of Fowler's dislike of SWEBOK.

        If you read his commentary (it's very brief), he dislikes the SWEBOK because the field is both too young and too broad to have a formed a generally accepted view of "what works". Plus, it's definition of the "body of knowledge" is needlessly shallow, and excludes things like the Gang of Four.

        • the field is both too young and too broad to have a formed a generally accepted view of "what works"

          That's nonsense. People have been studying software engineering since the 70s. I agree completely that the idea that there's anything that works in software engineering other than luck is optimistic, but the disciplines that SWEBOK describes (requirements, testing, SCM, etc.) are valid and mature.

          The big problem, I think, is that SWEBOK manages to be tedious and pointlessly theoretical about topics tha