Serena to offer free apps prototyping tool

[app103]

Serena Software plans Monday to release Serena Prototype Composer, a free tool intended to make it easy to prototype business applications.

Prototype Composer is a requirements visualization and prototyping tool designed to simulate how applications will look and function before a developer writes any code, Serena said. The intent is to ensure that an application will meet business requirements from the onset, thus avoiding costly, time-consuming rework.

With the Prototype Composer product, Serena is attempting to solve the problem of business users not always describing everything they want in an application, or being cryptic about it, Nathan Rawlins, Serena senior director of product marketing, said.

http://www.infoworld...rena-composer_1.html

[tinjaw]

< rant on > (read this and imagine me speaking 200 kph with spittle flying from my lips while coffee spills from my mug as I gesture violently.)

Serena Prototype Composer is a poster child for all things bad. I have watched one of their overview videos and it was like watching a car wreck. I have chosen my religion and it is the complete opposite of the methodology Serena seems to be promoting. It promotes waterfall development, when I am for spiral development. (Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.) It promotes reams and reams of (virtually useless) documentation when you should Working software over comprehensive documentation. It claims to help get the business people talking with the developers. That is a load of crap. You get business people playing with this, this, monstrosity, creating these diagrams and forms that are completely useless to the programmer who has to build them all over again in their development tools. Duh! DRY!! What's worse is these business puke's now have the attitude of "What's taking you stupid lazy programmers so long to build an application THAT WE ALREADY BUILT IN OUR (TOY) IDE!!". I am not saying the programmer's guild needs to keep our secret meetings secret so others don't find out all we do is read news feeds all day. It is the same principle that makes me prefer to mockup UIs via a tool like Mockup Screens. (As they say on their website, "Create screens which can't be mistaken for '90% done' application".) Additionally, although it may sound good in theory, I can tell you that this will just result in even greater division between the "business people" and the developers. Instead of working together, the business people will stop communicating with the programmers because they will go off to their offices (empowered by this  "prototyper") and "build it themselves". They will then throw it over the wall to the developers and their only reply to questions will be, "Didn't you look at the prototype? It's all there in the prototype. Don't bother me with these sophomoric questions, look in the requirements documents." The two groups need to work together, not separately using different, and incompatible, tools. (Business people and developers must work together daily throughout the project.) Ideas should be discussed in person. (Individuals and interactions over processes and tools. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.). I can go on and on, but I will leave the further berating of Serena's Prototype Composer as an exercise for you readers.

< rant off >

[tinjaw]

Ugh! Heretics!

[attach=#1][/attach]

Somebody please explain to me what is agile about this behemoth!

[Ralf Maximus]

(read this and imagine me speaking 200 kph with spittle flying from my lips while coffee spills from my mug as I gesture violently.)

"Waiter, I'll have one of whatever he's having."

Well said, spittle and venom included.  I've been on both sides of the hideous trainwreck caused by these prototyping exercises, where the Suits try their hand at designing software.  But I assure you, evil can be accomplished with naught but a dry-ink marker:

One day I was working in my cube (circa 1996) and the head of marketing plops down some Polaroid photos he took at his last client meeting.  The photos showed a whiteboard with flowcharty looking crap.  "What's this?" I ask, a sense of dread growing as I recognize the names of some of our software modules written in teeny little bad handwriting.

"We reorganized the workflow of the productl; this is the results of our JAD [joint application design] session."

"Um, you got any notes to go with these?"

"Everything's there.  When can you start?"

Flash forward, out of the nightmare, to today's new nightmare.  Products like Prototype Composer can so easily fall into the wrong hands, and trivialize the real design process.  The only thing that stopped my boss in 1996 was that they ran out of whiteboard; what horrors will be unleased when creating the next Unusable Interface is as easy as click-n-drag?

I bet it even has wizards.

[CWuestefeld]

I think you're jumping to conclusions.

An agile process (at least any sane one) doesn't mean that you shouldn't document the system.

It's true that there are zealots who claim that the code (or, more to the point, the test harnesses) are the documentation; if I ever need to work with any of these people, I will shoot either myself or them. (Sorry, I'm in a grumpy mood right now with a developer arguing that she wants to use DateTime.MaxValue to indicate null)

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.

Anyway, the point of agile development is built things incrementally, constantly correcting course as you go. Why can't the documentation get this same treatment you're giving the code? As your codebase is evolving, keep iterating the documentation as well.

That seems to me perfectly consistent with the agile philosophy, and something that this tool ought to be able to handle.

[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)

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)

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)

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.