|
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 -----
From: superabe superabe
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 -- 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
YAHOO! GROUPS LINKS
|
- Re: [flexcoders] Re: Flex prototype - production appro... JesterXL
- Re: [flexcoders] Re: Flex prototype - production ... Anatole Tartakovsky
- Re: [flexcoders] Re: Flex prototype - product... superabe superabe
