Flex & Agile Software Development

I took a stab at Agile Software Development on my latest Flex project. I haven’t read much on Agile Software Development. I really didn’t have to. Many blogs I read pretty much summarized it into “weekly builds”. Those 2 words don’t do it justice, but they certainly imply the “release early, release often” mentality. This greatly changes the way I’m used to doing things.

First, I’m used to coding a bunch of classes; compiling them to ensure my ideas work. If they do, then I start building an architecture of code I’ll learn to live with, start bringing in the ARP classes, and building my Views first since View’s are easy, and pretty much drive HOW you use the app. From there, it’s building Commands that equate to “doing” things, and finally the dreaded Delegates. They contain all your server methods, data mangling… er, I mean handling, and call your back-end via Remoting (CFC’s, PHP methods, Java methods, etc.). Finally, you start wiring things together… and do your first big compile.

All of that crap above usually equates to a 2 weeks to a month. You don’t ever really see your software taking shape until you get true data coming in from the back-end.

Not with ASD.

Instead, every week, I complete some milestone through a series of goals. By Friday, you can not only compile, see your targeted functionality working, (damn this is a good mix, rave, rave, rave…), but you can more quickly tell if the functionality is “right”. Meaning, you can throw it in front of a user or your client, and go “What do you think?”. Suddenly, that’s one less thing to worry about prioritizing. You either were madly successfully, or screwed up big time. Screwing up early on the main functionality is fantastic! You can more quickly make it right, when it matters most. You can either wax the functionality, mark it off on your list as done, or tweak it next week.

The trade-off? You have to write code that compiles. Suck. I know, right? Writing code that compiles… imagine that. Seriously, though, you can flesh a TON of stuff out, and more easily see your designed masterpiece more quickly and easily if you pretty much tell the compiler required code to f’off for a few days/weeks while you flesh out your ideas. Getting something compile-able, especially in a larger project even with a framework takes a lot of finishing touches, final nuts and bolts details to be written, and overall a lot of duct-tape that is a pain in the ass to write.

Granted, it doesn’t take all of that long to write, but it is very volatile code, doesn’t flow from your fingers, and you are definitely not emotionally attached to it. After all, it is not what makes your architecture a masterpiece… it just allows the compiler to understand it. Examples include THE import statement that runs attachMovie on your main component, or the code that throws fake data at your view to show it’s working… crap like that that is usually a lot more involved and larger in scope that what you use to initially test. All of that to compile.

Again, however, the results are well worth it. You suddenly aren’t recoding functionality milestones. You very quickly know whether or not they hold up in terms of being useful to the user, or liked by the client. They are done. The d-word is the hardest thing to say in software development. Seriously, how many times have you cheapened that word’s meaning by saying it so many times, thinking that if you repeat it like Dorthy repeated being home, that it would actually manifest its details and happen.

So, seriously, you’re done… and if your not, you know usually exactly what NEEDS to be done to make it so. Good feeling.

The down-side, is, someone either needs to update the wire frames after doing the iterative sweep, unless it’s a minor tweek, or there aren’t many developers involved.

The other benefit, at least I thought, was “proof of progress”. As I recently told someone via email advice, design projects are more subjective & visual, thus visual changes delivered via a calm, positive voice imply progress. You do the same thing with 50,000 lines of brand new code, but no one gives a shit if nothing changed visually. With a working build, however, you can clearly click the same button 50 times and go, “SEE!!! A new error alert comes up; I worked all weekend for that error checking… my alert dialogue will p@wn you client! IT’S MODAL… IT MUST BE OBEYED!”

Since code, while objective to track, is subjective to show, it suddenly becomes more objective; you can clearly show something working that wasn’t working last week. The cool thing, too is that ALL of your other stuff usually doesn’t break. Why would it? You’re already “done” with it. See where this is going?

However, I’ve found in practice this didn’t hold up. nTier development usually consists of a server that doens’t truly work without a client, and a client that doesn’t truly work without a server. Both have to be developed to their extent, and tested in concert.

Regardless, weekly builds, while not getting the proof of progress emotional effect I wanted, clearly smoothed communication between my boss and I. We can waaaaaaay more easily judge what was completed, what wasn’t, and where we needed to go specifically. Anything that helps communication in software is a good thing!

So, in conclusion, while it was hard writing code that was compile-able more early than I’m used to, as well as ensuring it compiled every week to working state to ensure a feature did in fact work as the client intended, it was REALLY nice to never touch a specific command, delegate, and view (mvc basically) again, unless something needed to be changed because of scope creep or it needed to be changed because it was looked at the very same day. That made me feel like I was actually making progress.

I think a lot of developers feel like they coded something, only to write 10,000 lines of code that equate to 100; since they’ve written that many lines just to change the same 100 through the course of a project’s lifecycle.

Second, while perceived progress didn’t give the emotional effect I wanted, it certainly made me feel good about how the project was going, and helped communication with my boss.

Finally, it was a lot easier to project time-frames; I knew what was truly “done” so could clear my mind of other concerns when calculating timeframes of what needed to be done for the next milestone.

I guess I was under the impression that ASD would give my clients a warm feeling that we were truly making progress because they could “see it working” but that is a false perception. Live and learn. It’s really for me, the developer, to be more successful, not to make people feel good. Bottom line, I’m successful when my software is done.

So, where does Flex fit into this? This is the first project where less than 10% of my problems where related to the tool I’m using to complete my task. The rest were coding & testing errors on my part. This 10% included undocumented lower level classes dealing with the Flex framework, lack of true strict typing to catch misspellings resulting from more dynamic ways of coding, and extra time that it took to debug using FlexBuilder.

My experience in the past has been 30 to 40% when dealing with Flash. That portion of your time is figuring out “wtf Flash is doing” vs. “wtf is my code doing”; which a lot of time one blurs into the other, mainly in regards to use of components.

This time, however, Flex came through and I felt like I had very little problems when doing this project from a coding standpoint. The only problems I DID have were communication wise, and that’s pretty good considering I telecommute.

I think I’ll use Agile Software Development on every project from now on, from big to small in scope. It feels like I’m building pretty prototypes, and I have the option to use the word “beta” in a pinch during client/user testing. Overall getting more done, and getting it done better. I know for damn sure I’ll be using Flex; she came through like I expected her to.

…this assumes my definition of what Agile Software Development is, let alone my implementation, is even accurate. Even if it’s not, it’s certainly better compared to “the big compile”.