Ya like prototyping, XP style spike solutions are a very good idea.
Reach a proof of concept prototype asap. Do it dirty, do it by stealing,
do it whichever way you can do it as long as it's fast. And from the
experiences garnered during this spike, a better solution of the problem
can be deducted. It feels awful planning to do something you haven't
done before, so a minimum of a day or two just for experimenting with
solutions and learning about the real scope of the problem is pretty
much a given for me at work these days. Then again i haven't worked on
anything small and quick in years. I miss the quick stuff :( year-long
flashdev on the same project gets so demotivating... But i digress.
Important to remember that people, at least most people, are monkeys
that like playing and pushing and pulling and kicking stuff. Feeling the
texture of a surface will tell you more about it than any picture.
ryanm wrote:
After spending a couple of hours, tracing my codes , pulling
my hair out, and smoking 2 packets of cigarettes, I felt that
rewriting it from the scracth was a better way. So, I did that
and the result was satisfying. However, I think working twice
on the same codes is not good at all. So here I am, asking for
your guidance about how to code/design Flash applications
(not only Flash sites) efficiently, as simple as possible, without
making things overcomplicated. Or maybe it is just a matter
of experience?
Planning, that's all. Work it out in your head, on paper, on a
whiteboard, whatever, before you write the first line of code. If you
are unsure about how something will work, prototype it. Don't get hung
up in the details, just test whatever it is you need to test, and
figure out how to make it work how you want, and then go back to
planning. Once you know how it all should work, writing the code is
more like taking dictation than experimenting. As with anything, the
more complex the app, the more necessary good planning becomes. If
it's a quickie, one-off interactive ad, maybe all you need is to
scribble out a few diagrams on a whiteboard for 15 minutes. But if
it's a large-scale application, you might need several months of
planning resulting in a substantial document that describes what
components are to be built, how they work, and how they integrate.
Once you have a good plan, though, writing clean, efficient code is easy.
Even with good planning, there will be times when things don't work
out as expected and you have to rewrite some code. But with good
planning, you usually don't have to rewrite the whole thing. That is
another advantage of that whole OOP thing that many people turn their
noses at. One of the major benedfits of using OOP techniques is that
it often saves you from having to rewrite the whole thing, and instead
you may only have to rewrite a single function, class, or component,
while the rest of the app works just like it is.
The bottom line, though, is that you answered your own question.
After you spent a few hours making sense of exactly what you wanted to
accomplish, you found a much better way to do it. The question you
need to ask is if you can put those couple hours at the beginning of
the project, and skip over the whole first draft completely. Two hours
up front to save you 8 hours of writing code that will end up in the
trash anyway is a 63% increase in efficiency (assuming it took 8 hours
both times you wrote it). It *more* than cuts your development time in
half, because you spent those 2 hours working out how to build the
thing either way. And I'll bet it was much faster to write the second
time (when you really knew what you wanted to accomplish and how to
accomplish it), too, wasn't it?
ryanm
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
