Other Software > Developer's Corner

Serena to offer free apps prototyping tool

(1/2) > >>

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.

--- End quote ---


http://www.infoworld.com/article/07/11/02/serena-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.)

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page