Comments on: Software of Today Loves the Hardware of Tomorrow

By: JesterXL

JesterXL — Sun, 27 Jun 2004 19:08:46 +0000

I usually build a project from a series of tests. Some of the classes and layout and messaging I already know in my head, the rest I sketch out, which isn’t much. The majority of my time is spent testing code prototypes, like, loading XML via RPC, and making sure I understand how the class works, and how I should best integrate it with others that I may already know I want to build. I’ll then go build the things I either don’t fully know how to do, or do, but want to make sure it’ll work in the way I want to do things.

Once all the little, 200 line testers are operational, and it’s easy to debug them, I then start building bigger testers; which are just combinations of my coding prototypes (XML-RPC class loading XML from LiveJournal using my Login Form). Does it work? Is it easy to debug? Can the rest of my work in this way? Does it feel right? Later down the road can I modify it? Extend it?

I can only usually answer 70% of those questions. I only find out 20% more once I’ve reached near completion of a project. At that point, if I have time, I’ll re-write it from the ground up, using existing classes a little bit, but re-factoring across the board. Usually, the 2nd time around she “feels good to work with”, both in production, and when I have to start adding last minute weirdness from the client.

As far as optimization goes, I woulda caught most of that stuff up front; the exception being having everything playing together, and then having to realize there are so many moving parts, it really comes about optimization of messaging between them.

Sorry dude, I hope that helps better explain how I do things and what I run into. I think the difference is, I can re-write a lot of my core architecture really quickly while re-using some of the old stuff merely to modify my approach. Go RAD development…..

By: Phillip Kerman

Phillip Kerman — Sun, 27 Jun 2004 07:35:21 +0000

Hmm. In every project I include a stage where I revisit the general programming approach to see if I can improve performance. Often I’ll do a test early on to make sure there aren’t any absurd performance hits. If you find performance is lacking you can’t just take another approach. I mean, how do you know the new approach will be better?

I’m still surprised you don’t come across this often.

By: JesterXL

JesterXL — Sat, 26 Jun 2004 18:20:10 +0000

Typically, when I had problems in Flash MX, I took the stance that if my stuff didn’t run well, I was designing it wrong. Rather than try to tweak and algoritm, or find out why something was loading too long, I just designed it so it ran acceptable. Forest for the trees kind of thing. If it was too slow, I was doing something wrong; not like “it should work”… well duh, it should run, but it’s not, so what’s the pragmatic thing to do.

By: Phillip Kerman

Phillip Kerman — Sat, 26 Jun 2004 07:58:10 +0000

I don’t understand how you don’t run up against Flash limitations. Are you just naturally efficient?

By: JesterXL

JesterXL — Fri, 25 Jun 2004 18:18:04 +0000

No, Flash 8 will implement features which will allow us to do more, thus use more hardware, and push the limits again… at least I will try!