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.
  • Every software engineering course/text I've had preaches the "picture is worth 1000 words" principle. I believe it, but I've never had a course or a book teach me anything useful about diagramming. We've got wonderful standards like UML and such, but I can't use them because the examples always teach me how to use UML to define an elevator or a zoo instead of how to define a program. I've learned three to five diagramming standards that I cannot use at work because while I can read the diagrams, I have n

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • I've learned three to five diagramming standards that I cannot use at work because while I can read the diagrams, I have no clue how to use the diagramming conventions to represent even the simplest one-off tool programs I write.

      This is one of the problems with current diagramming techniques IMO. They actually work somewhat in reverse. More complicated programs are more easily represented than less complicated ones. Whereas a one-off tool would probably not have more than a class or two (and more-often none at all) and has a low degree of headspace-to-knowledge requirements (ie, the amount of headspace you need to know what the program does and how it is designed) larger pieces of software have far more classes and interactions, and therefore a higher degree headspace-to-knowledge is needed. In the former case there is far less benefit to any design or documentation[0].

      Software design using UML is just as hard as software design without it - you need to be able to identify core classes early on. One of the most important things that UML has given software people is a (more) formalized vocabulary when talking about software.

      [0] I'm not saying there is no benefit, just far, far less
      • To rephrase, I've learned three to five diagramming standards that I cannot use at work because I have no clue how to use the diagramming conventions to represent even the simplest one-off tool programs I write, let alone a large program. The problem is I don't know how to use these diagramming conventions to represent a program. I know how to use them to represent a giraffe or an elevator or an automobile. In the book you see an example like this, in class the professor goes over the same example, then

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers