Re: [flexcoders] Re: Flex prototype - production approach

Sat, 05 Nov 2005 08:43:38 -0800

Thanks all for taking time to detail out the issues.
Lots of good info to digest, and research.
 
I especially get Anatole last point about remembering to focus on DB design as well in the early stages.
I think that is as important to nail down initially as it is to get the application look and feel, and in most cases affect how the application look and feel can be achieved.
 
I think I need to get on a team that has some experienced Java Enterprise Devs ! !
 
- superabe
 
 
On 11/5/05, Anatole Tartakovsky <[EMAIL PROTECTED]> wrote:
superabe,
    If I may, I would like to suggest the environment I like to use. Most of the applications I have been working with had to do very few things - database access ( read and update), navigation and reporting. There are fun parts here and there but I like to keep them to myself so it is not completely boring.
    How would you go about developing and maintaining ever evolving codebase with a lot of repetitve "utility" fuctionality driven by trial and error design process? You do not write application code till the very end. Instead you build or get automation tools that allow you to prototype data access, navigation and reporting - and use it in production later on.
    Let me illustrate. I need to be able to maintain customer info - let us say it is trivial "select * from customer where id=?". I can write regular Java code to do all retieve, update, insert and delete methods - all 500 lines of it actuall - by hand. I would also need to create value object to hold the data and maintain that as the DB expands. not to forget - need to create model objects coming in and out, bind, and work through the changes with  code that would be able to figure out what user did and submit one of those methods. Do fine stuff (validation and formatting), debug protocol with server as some undefined/null value would blow it randomly, and have part of weekend free before the inevitable changes will start flowing in.
 
    Alernatively I can use Doclets to process some comments embedded in my java interface and generate the following :
1. All Java code
2. All synchronized value objects - java and AS
3. Forms and grids and master details screens along with  Formatters/validators - can use to cut and paste those
 
Add a set of high level objects like Foms and DataProviders that automatically keep state/track changes and have retrieve/update API embedded, transactions, progressmeters, and othe high-level objects you need in any app - and you can cut-and-paste your wireframes from those resources much easier then BAs can move Visio shapes. Best thing you can tell users "now I need to work on making it working" and take really nice vacation.
 
Now the change comes - they added a field. Time to regen - that takes care of Java and VO, You will need to cut-and-paste new field in "prototype" - but hopefully, thats it.
OK, they want something drastic - database driven comboboxes, expandable treeviews,  you name it. Take a deep breath and look around. DO NOT MAKE APPLICATION SPECIFIC CODE. Chances are you might need database driven combobox somewhere else! Rather, create object that you can use across the screens, think hard about caching, read about problems with "prompt" and "value" properties, prepare yourself for those wireframe meetings. Make a management decision if you want to make that generic object upfront or you want to "hardcode" it during session and get the scope on functionality it has to support.
 
        It is true that "generalized" code takes 3 times longer to write. It is also true that on average you will be able  in more then 3 occasions. The "next best" productivity method (some call it cut and paste) is guaranteed to turn the project in development nightmare even before it goes into maintenance.
 
    Here is the ultimate goal for the "perfect" maintainable application - it has to have very little code. It has to use as much as possible of pre-tested, reviewed consistent objects instead.
During design/wireframe stages try to concentrate on database design, usability and identifying objects/supporting tools.
 
HTH,
Anatole Tartakovsky
 
 
 
 
 
----- Original Message -----
From: JesterXL
Sent: Friday, November 04, 2005 9:27 PM
Subject: Re: [flexcoders] Re: Flex prototype - production approach

 
Absolutely!  9 out of 10 times I'm building, & re-factoring production code as I go.
 
I think the important thing to note here is the purpose of milestones via iterations is to get a build done, working, and testable by a real user, not just a developer.  This garners relevant feedback, the kind that promotes work to be focused on the 80% of the app that matters.  Additionally, this gives you a chance to challenge the wireframes, the information architect's work, and/or the designers.  You constantly have proof of improvement, recognizable & documentable milestones, and a sense of accomplishment that actually has meaning.  Working towards meeting the users' needs, and making progress doing it is a lot more relevant to a project's success than working towards the developer feeling comfortable with his architecture and showing progress doing it.  Just because I love my implementation of MVC in the app means jack of the app doesn't work for the user.
 
Now you can see how my view of commenting code & using tools like ASDoc is slanted; I'm too busy improving & changing the design as I go to ever really get to the point where the app is so stale it needs to be documented.  Why spend time on it if you are possibly going to change it?  It's wasted effort.
 
Change?  Having View's that aren't tied to the Model and emit useful events.  Having, as Steven has said in the passed, Commands (chunks of controller code) that actually map to user cases; they do something the user would do like "open a document", "save a record", etc.  Doing your best to use MVC & frameworks like Cairngorm and ARP allow things to be extremely flexible.  Most of my changes come from design, not from business process, so most of the time it's pretty easy, like moving some MXML around, or deleting it entirely and just using code.  Other times, the actual logic changes, and I have to sometimes move code around, etc.  Again, modularizing techniques keep this to a minimum; meaning you are most of the time creating & modifying vs. destroying what you created.
 
The phrase "signed off" to me sounds like the contracting advice I see thrown around the lists.  I admittingly do not understand their pain.   I recognize that they are trying to protect themselves, as their stories of past problem jobs are telling, but I've never had that experience.  Additionally, and more telling, I've never had a wireframe that was rock solid.  While I do hate doing wireframe changes 6 weeks into a project, I'd rather be doing that then following a failed cause.
 
So, to me, signing off on a wireframe sounds like a death warrant... but I never deal with those sides of the project; my managers, designers, or sales dudes do.
 
Yes, skins add considerable time, but one must understand that a designer developing a rich app is creating, hopefully more often than not, something extremely brandable and compelling compared to the simplisitic nature of web page designs, which have to be created that way to fit into the HTML/CSS paradigm.  Those boundaries to design do not exist in Flex since the sky's the limit, so it's actually time well spent; time you couldn't do at all in HTML development.  On the flipside, I've seen web designers take weeks to get a design to work on a website... and one I wasn't really impressed with at all.  Spending 6 hours on getting a margin to work seems a lot less valuable to me than spending 6 hours implementing a phat PSD into PNG parts for use in skinning Flex components.
 
Flex, and Flash, both are still evolving.  Although we've had years, and one can go on Google and find thousands of components that are free, there isn't a lot of cream in the crop.  QA is a nightmare because some were written for Flash 4 before ActionScript existed, some are AS1, and the majority are tied to FLA's in some way.  A lot of time in Flex is spend custom components for a specific job, yes.  But, it's worth it; you build up an impressive reproitoire of components in the long run.
 
_javascript_ has definately got us on that front with the options of frameworks out there, both commercial and non.  But... they are about AS1, and don't look as cool as ours!
 
Remember; an app can look good and not work as well, but still sell better than one that does.
 
...data... hrm... tough.  Usually, I've found the backend guys I've worked with follow this pattern:
- in the beginning, they know everything, and spell out the data model to me, and involve me in business logic discussions to see what I can handle on the client; I in turn push as much as I can their way
- in the middle, I work like mad, and get feedback on how I'm doing from them, and ask questions
- I reach one of my later milestones, and am ready for real data; at this point, I start breaking the hell out of their back-end services.  So, getting relevant data takes a few days
- once I get the data, I recognize problems with it (usually associated with OpenAMF; .NET and real Flash Remoting installs I rarely have this problem) and either ask for changes that they usually consider extremely minor, or slightly massage to what my component wants (in a ViewHelper for example).
- at that, point, I'm finishing business logic, wrapping things up, and in the end I'm waiting on the back-end guys to fix bugs so I can re-test my front-end for the 50th billion time.
 
That's pretty much stayed true every project involing serious back-ends.  I've always tried to utilize dummy data early on and get confirmation from the back-end guys on what I'm getting, so I havne't run into the problem you are describing.
 
 
 
----- Original Message -----
Sent: Friday, November 04, 2005 8:26 PM
Subject: Re: [flexcoders] Re: Flex prototype - production approach

 
Thanks for all the replies.
 
So the majority seem to favour approach A and iterative development.
Question though, doesnt iterative mean you are building towards a production app?
Meaning the prototype would constantly get refactored and eventually become the production app.
 
As opposed to a protoype that is done real fast and then the production app is started from scratch (i.e none of the code is re-used , but you gain all the UI design, usability and input from domain experts experience from the prototype design phase)
 
Also, having just been through an iterative process for a Flex project, some questions :
 
How do you manage constant change in iterative development ? 
Especially when you start without signed off comps/wireframes ?
 
Also, what about where you have very custom designs (using skins , transitions etc, custom display mechanisms),  does that not add extra dev time trying to do it in Flex at the prototype stage (as opposed to a quick mockup in Flash say for e.g or a Photoshop comp)
 
And in the process that Dave calls LookFirst, do you ever run into issues, where once the UI is done and decided on, the nature of the data in the data store (as decided by the business logicl) proves inefficient for display process. (might have been fine using static dummy data, but when the real-life data comes along...things prove too convoluted)
 
Once again thanks for all the comments.
Very useful. Just trying to get a better handle on how to plan out larger Flex projects.
 
- superabe
 

 
On 11/4/05, Dave Wolf <[EMAIL PROTECTED]> wrote:
We feel very strongly about this subject.  We developed all our
Flex/RIA solutions so far using a "front to back" approach.
Effectively we do what we call a Model & Design phase where we develop
out the entire UI in Flex.  In the past we would call this "wire
framing" and would use static images to represent the UI.  Witht he
productivity of Flex we now just do it right in Flex.  We work hand in
hand with the domain experts to layout and develop every screen in
the application.  Once that is done, in the next phase we bind static
data to the UI, implement validations and flow and actions.  Finally
using the domain knowldge we got from the M&D the back-ends are
developed and finally integrated into the UI.

This approach has tons of advantages but the biggest being this.  JAD
sessions are *boring*.  Business domain experts get very bored very
quickly looking at data models, object models, functional specs etc.
Well as they get bored, they stop caring.  So when you ask "Can we
just skip field X here" they just go "Yup".  Now you do the back-end,
the API's build out the UI without field X.  Wanna guess what happens?
Yep, they tell you X is missing and the app is flawed because of it.
Now you have to layer fixes into three to four layers of the
application.  Add the field to the data store, add it to the
persistance layer, add it to the API, add it to the UI, etc.

Domain users are *a lot* more likely to stay engaged in the user
experience.  Then you use those lessons learned to drive back at the
enterprise tier.

We've coined this approach as LookFirst(tm) and use it pretty much
religously.  There are other side benefits like the app is
demonstrable before its finished, blah blah.

We actually sell an offering to our clients for the M&D itself.
Includes all the screens, data model, project plan, test plan, etc.
Its been very successful.

I would vote for a LookFirst like front to back approach.

--
Dave Wolf
Cynergy Systems, Inc.
Macromedia Flex Alliance Partner
http://www.cynergysystems.com

Email:  [EMAIL PROTECTED]
Office: 866-CYNERGY




--- In flexcoders@yahoogroups.com , "JesterXL" <[EMAIL PROTECTED]> wrote:
>
> Jesse Warden does A, Darron Schall does B (I would think).
>
> I like to build stuff quickly, ironing out the weird, diffucult
things, and just continually kneed the mofo like dough, improving, and
releaseing working builds to prove progress.  Sometimes, you realize a
re-write is best, and you can re-use some functions and assets, but
not much (which is why I call it a re-write).  Since Flash & Flex make
that sooo fast, you do that about 3 times.
>
> I've done B, but that sucks.  I hate UML, as long as you have an
awesome Information Architect, who cares; take the wireframes, and go;
then iterate when you can show a build, and double-check your
assumptions about both the wireframes & the implementation.
>
> To me, B works in better in a team, and I've had success working
with others, but the pressure at the forefront to "plan it perfectly"
seems like I'm being setup to fail, and when the transition from
prototype to production comes; it feels cheap because the code itself
wasn't really a prototype; it was a planned production piece from the
get go.
>
> Obviously, I'm leaving out all of the important factors that affect
the above such as investment, leeway, deadlines, # team members,
accountability, aptitude, experience, etc. but bottom line, I dig A.
The only really big thing about A is deadline; you're emotional
attachment to building re-usable code should be inversely proportional
to the amount of time you have left.  So, if you have a week, don't
care about it.  If you have a month, definately.  Obviously, I'm
implying scope here, but you get the gist.
>
>
> ----- Original Message -----
> From: superabe superabe
> To: flexcoders@yahoogroups.com
> Sent: Friday, November 04, 2005 5:19 AM
> Subject: [flexcoders] Flex prototype - production approach
>
>
> Just curious about what folks here on the list think / have
experienced about the prototype based approach to RIA developemnt with
Flex.
>
> Am evaluting a potential project that needs to be prototyped first
and eventually built using Flex, and trying to decide what to use for
prototyping and how much of the prototype can be re-used in the final app.
>
> The two options I see, are :
>
> A. do a quick prototype in Flex or Flash for the purposes of feature
gathering / usbility. The start the production app from scratch in Flex.
>
> B. Do a more planned out / better architected prototype in Flex ,
that can be re-used substantially towards the production app.
>
> Am interested to know what pros' and cons people have faced with
both approaches.
> TIA
>
> - superabe
>
>
>
>
>
> --
> Flexcoders Mailing List
> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> Search Archives:
http://www.mail-archive.com/flexcoders%40yahoogroups.com
>
>
>
> SPONSORED LINKS Web site design development  Software design and
development  Macromedia flex
>       Software development best practice
>
>
>
--------------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>   a..  Visit your group "flexcoders" on the web.
>
>   b..  To unsubscribe from this group, send an email to:
>    [EMAIL PROTECTED]
>
>   c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
>
--------------------------------------------------------------------------------
>






------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM
--------------------------------------------------------------------~->

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/flexcoders/

<*> To unsubscribe from this group, send an email to:
   [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
   http://docs.yahoo.com/info/terms/






--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com



SPONSORED LINKS
Web site design development Software design and development Macromedia flex
Software development best practice

YAHOO! GROUPS LINKS





--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com


YAHOO! GROUPS LINKS



Reply via email to