Other Software > Developer's Corner

Serena to offer free apps prototyping tool

<< < (2/2)

tinjaw:
Valid arguments CWuestefeld, however Agile doesn't mean no documentation, it means only what is necessary, and nothing that can be found in the code, comments, or auto-generated documentation. The code should be your primary source of documentation for matters involving development. There should be some documentation for explanation of why the software was built and how it is meant to be used, as well as user manuals and training materials.

Ralf Maximus:
Even once you're done with coding the whole system, having a document that describes the whole thing is invaluable. Right now I'm working on a project that's replacing a 10-year-old system that's grown like a cancer, and one of the biggest problems we have is trying to figure out exactly what the old system really is.
-CWuestefeld (November 14, 2007, 04:55 PM)
--- End quote ---

That is the design document, and should be completed (or at least roughed out) prior to coding.  When the finished product deviates from the design, as it most certainly will, the document should be updated to reflect the final results.  Then sealed in carbonite and buried at the bottom of an abandoned salt mine for future generations of coders to discover when needed.

I'm not arguing against the necessity of that.  It's how the design is created, and tools like Prototype Composer are as beneficial as giving chainsaws to monkeys.  In the hands of a skilled analyst, Prototype Composer might be useful -- but most analysts probably wouldn't want to use a toy.  No, the target audience is quite clear: people who have no business designing software.  And that gives me the willies.

Believe me, I WANT non-professionals to help design software.  I love the unwashed masses, gritty from the honest filth of a day's toil, describing what it should do, and how it should work.   Nothing beats the perspective from the trench, shells exploding among mixed metaphors.  However, that input has to be processed by a trained ear, the actual needs distilled from the stream-of-conciousness that so often happens when normal folk are asked, "what the hell do you do, anyway?"  I fear products such as Prototype Composer will short-circuit the process, allowing anyone to document anything as a requirement to do everything, without regard for physical laws or sanity.

And the more I think about it, the more certain I am it probably has wizards.

tinjaw:
And the more I think about it, the more certain I am it probably has wizards.
-Ralf Maximus (November 14, 2007, 07:51 PM)
--- End quote ---
And, FSM forbid that somebody from marketing get a hold of it.

||Application Wizard||
Which components would you like to add to your product?

Marketing Guy: "Where is that Select All button?"

iphigenie:
In the planning phase, often a set of mockups (i.e. wireframes / visuals / not-doing-anything-except-show-the-task-flow clickable app / html clickable images)  really helps clarify what is meant by a feature and how it ought to work in the user's mind.

That is especially true in agile methodologies which imply the participation of client/user throughout.

A tool like this which might allow someone to sit with the user and on-the-fly react to a user comment, eg. "how could I change X" "well we would use a standard config list, like this"  --click click drag drag drag refresh-- "no, i dont think I would know what to do with this" "how about tabbed? and we could add a colour picker" --click click tick refresh -- "ah yes, less confusing"

Handing something like that together with a func spec/user stories/whatever the flavor of the month is for defining the works of the required app  *really* would help the developers who inherit bits of the work.

Of course in a 1-2 developer setting where the devs are involved early on in the planning this is maybe less helpful, but in the typical pre-sales / project manager / architect passing the buck to developers, this is could be quite helpful

I totally understand some of the things you are saying (especially the "why does it take so long") but i think it could still help, because I have found that forcing people to go through a phase of mockups can really avoid huge tension later down the road - and also set expectations

app103:
In the planning phase, often a set of mockups (i.e. wireframes / visuals / not-doing-anything-except-show-the-task-flow clickable app / html clickable images)  really helps clarify what is meant by a feature and how it ought to work in the user's mind.

That is especially true in agile methodologies which imply the participation of client/user throughout.

A tool like this which might allow someone to sit with the user and on-the-fly react to a user comment, eg. "how could I change X" "well we would use a standard config list, like this"  --click click drag drag drag refresh-- "no, i dont think I would know what to do with this" "how about tabbed? and we could add a colour picker" --click click tick refresh -- "ah yes, less confusing"

Handing something like that together with a func spec/user stories/whatever the flavor of the month is for defining the works of the required app  *really* would help the developers who inherit bits of the work.
-iphigenie (November 17, 2007, 05:01 AM)
--- End quote ---

Isn't that what Delphi is for?  ;)

click click drag drop...instant GUI...fill in the code that makes it work later.

At least this is how I do it when I get an idea for something. I see the application in my head, see what it will do when you click this, or do that...make a quick GUI and save it with a text file describing the rest, so I don't forget.

Navigation

[0] Message Index

[*] Previous page