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!

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...

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