Brother, I mean no disrespect, but I fear I must disagree.

I see no reason why the approach you are taking couldn't benefit from using UML for each iteration/version of the code.

Remember, the purpose of UML is not to make you do busy work, drawing diagrams. It's to make you think about & explore your design from many angles. I believe that it can enhance the specification process, and allow you to negotiate properly with a client, rather than "build what I mean, not what I say."

It's true that it takes experience to learn how to ask the right questions as a designer & how to specify what you really want as a client. Furthermore it takes even more experience to then be able to give estimates that actually stick.

Since most of my work is done as a consultant I have heavy expectations put on me from the start to answer accurately "How long will this take?"

It's for that reason, plus the budgetary constraints of business, that we have and MUST have firm specifications. What you describe is affectionately called "feature creep" and that approach precludes any sort of deadline. Rather, "it will be done when it's done" which leads to the infamous "it's 90% done 90% of the time" syndrome elloquently outlined by Fred Brooks in The Mythical Man-Month.

First you create a specification, with as much detail as possible, then you validate & verify. Validate that your spec matches what was asked for & then verify that's what they really want. Then you code. Then you validate & verify again. Validate that the code matches what the spec demands & verify that's what the client still wants.

& if not... Then you Negotiate! I'm not trying to sound like a money-grubber, or someone who is obsessed with process, but there are certain realities that developers have to face.

Brooks summarized that there was no "magic bullet" to speed up software development. I think that reflects the time when the book was written. Today I would say that code re-use is the magic bullet, possibly coupled with OOP, though I'm still not convinced of that part. I know that the CPAN has saved me more time coding than OOP in general ever did. UML, in my mind, is a helpful tool for dealing with the mundane and repetative nature of OOP syntax. If used properly, all I'm left to do is to fill in the meat code. Which is where all the fun really is anyway, no?

I see it as part of 'Cultivating Laziness as a Virtue.'



Wait! This isn't a Parachute, this is a Backpack!

In reply to Re: Re (tilly) 3: UML for PERL? by gregor42
in thread UML for PERL? by gregor42

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.