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?? |
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 Section
Seekers of Perl Wisdom
|
|