Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Re (tilly) 3: UML for PERL?

by gregor42 (Parson)
on Mar 29, 2001 at 02:19 UTC ( [id://67976]=note: print w/replies, xml ) Need Help??


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

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!

Replies are listed 'Best First'.
Re (tilly) 5: UML for PERL?
by tilly (Archbishop) on Mar 29, 2001 at 04:01 UTC
    I fear you halfway missed what I meant. I was not talking about UML tools. I was saying that there are good reasons to program in a way where you do not start with final specs, and there are many cases where code is incrementally rethought and redesigned as you go. In particular it is not sufficient to say as a hard rule that people should always have solid specs up front.

    For two very different references showing that what I am talking about is not just "do not plan" under different words take a look at Extreme Programming and Rapid Development by Steve McConnell. The first is a specific methodology that uses incremental planning and refactoring. The second is a survey of best practices for producing software, chapter 7 in particular contains comparisons of different lifecycle planning techniques and the tradeoffs you make in choosing them. Most of the options discussed follow some variation on ready, fire, aim.

    As for magic bullets. I disbelieve there is a magic bullet. There are a lot of incremental improvements. Put them together and you get order of magnitude improvements, but anyone who is saying their technique can solve all of your problems is selling something you probably don't want to be buying...

Re (PotPieMan) 5: UML for PERL?
by PotPieMan (Hermit) on Mar 29, 2001 at 03:52 UTC
    I did not mean to sound demeaning, gregor42. I apologize if I did in any way.

    My planning is simply not structured enough for me to justify using UML diagrams. My projects just aren't long enough at this stage of my career (I'm in college, working as a student Web developer for my university).

    I am certain that, at some point, I will want to use a tool such as ArgoUML to plan my projects. I just want to avoid being forced to fall back to a specification that is inflexible for whatever reason--because the other programmers can't bend from their UML diagram, for example.

    Please don't take this as a personal attack--I respect your decision to use a UML tool. I just worry about some of my classmates in computer science courses that I am taking. We are taught to think that a strict analysis and design process is absolutely necessary for all programming projects, so I am skeptical of the use of UML diagrams in general.

    --PotPieMan

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://67976]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2024-03-29 05:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found