Brother, I don't understand. I mean, certainly you are entitled to your opinion. But isn't one of the precepts of programming that you do your planning properly up front?

In (my) reality, object relationships change.

If you take the time to plan out your project from the beginning, you should be able to reduce the amount of coding time, by skipping the "throwaway" prototype phase. Are you talking about their relationships changing with subsequent versions or during the initial development cycle?

I mean I suppose it depends on what you're doing. CGI's for example, benefit very little from UML, but then I don't write CGI's using OOPERL. That's just me...

I don't know that a project has to be very big to benefit from a decent UML tool either. I for one, mostly use UML to build code skeletons for Java. I was thinking that it might be nice to have a tool that could do the same for me in PERL. That's all. Call me lazy, but laziness can be a virtue too.

Planning from the start involves having a good spec. Demanding this is a case of making life easy for the developer at the cost of making it impossible for the customer. Thereby giving both sides plenty to complain about.

People typically are unable to envision the consequences of the spec they hand you without the feedback of seeing how it would work. With a rigid product cycle this leads to the classic conflict where the developers complain that the spec is incomplete and changing, and the clients complain that the developers do not understand what they want and are unresponsive to their needs. And they are both right. The spec is changing and that is a real problem for the developers. But human and fallible clients are unable to give you a decent spec 18 months out, things change!

Various incremental design techniques exist that try to get a rapid feedback cycle. A little more is specified, a little more is developed. Clients try it out and can figure out what they want added. Developers aim to have a design that can be readjusted and refactored.

This strategy is emphatically not a question of not taking time out to plan the project. Rather it is a question of intentionally using design strategies that have evolved to avoid the classic problems that come with more rigid strategies.

And yes, I have seen this kind of thinking applied (OK applied slightly hapazardly) to reasonably complex CGI projects that were based on a backend that deliberately had a lot of OO in it. (Well it didn't up front, but after a few iterations it did. :-)

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!