The parent utilizes a mask so that the 4000 pixel timeline is shown zooming in a 700 pixel area.  Works great… sometimes.  I keep getting random results.  It all comes down to the fact that things like “masks” are extremely low-level, at least as far as the Flex SDK is concerned.  Unlike other Flash tweening engines such as TweenLite, the Flex 2 & 3 ones must contend with a significant amount of information about the objects they are tweening.  For example, you can’t just move a UIComponent across the screen and think everything is ok.  There are a multitude of things you need to do and handle.

You can attempt to temporarily cache the object in question as a bitmap to speed up the animation.  You must make the decision whether the parent should clip the content you are moving.  You need to reset the CSS margins to 0 and horizontal & vertical centering of the component to ensure it, and its parent, doesn’t unnecessarily redraw.  You may need to force clipping on the parent if you go beyond its boundary’s.  You need to ignore other move events, handle redraw events that could interupt the tween, and finally reset everything when you’re done as best you can.

If you’ve ever looked at the life cycle of a Flex component, it’s actually pretty simple to build upon, but quite complex to really understand all that goes on under the hood from a redraw perspective.  The multitude of redraw events, classes involved, and internal properties that super-cede built in ones (clipping content vs. mask/scrollRect and cacheAsBitmap for example) makes it extremely complicated to debug when you are doing low-level stuff that may not play nice in the Flex sandbox.  What works perfectly in a vanilla, Flash / pure AS3 environment could fail in a Flex one.  You just need to understand the Flex SDK.

I clearly don’t; my mask keeps screwing up.  If I turn it off, everything worked fine.  Every time the Move effect was done, the mask would be slightly off target.  After digging in the effect code, the only thing I can gather is that multiple calls to having the parent of the tweened component reset its scrollRect value somehow misaligned mask… or perhaps that in combination with a caching, and then subsequent un-caching, as bitmap.  Even though I’m compiling for Flash Player 9, I believe they upped the cacheAsBitmap limit from 2880×2880 pixels to over 9000 or something.  So, maybe it is in fact succeeding and thus this is what’s screwing up my mask.

Not sure, at this point and don’t care.  Solution?  When the tween is done, reset your mask.  If you’re paranoid, set it in invalidateDisplaylist although that’s pretty heavy handed… but hey, I can guarantee it works! 

1. Part 1 - Stressful
2. Part 2 - Code Refactoring
3. Part 3 - Branch Workflow

This entry is about utilizing branches for each developer in Subversion, Merge Day, and how while cool, it’s an ivory tower process.

Note: This isn’t a tenet of the Agile methodology itself, it’s just something that works well when you have a bunch of developers collaborating together rapidly, and a specific workflow our client requested we follow.

Branch Workflow

We’re utilizing a Branch Workflow on my current project.  What this means is that each developer creates their own branch in Subversion.  If you’re utilizing Tortoise SVN on PC or Versions on Mac, this is effectively a folder.  As you may know, Subversion has 3 default folders that you typically utilize in a repository, and hopefully each project gets its own repository.  These are branches, tags, and trunk.

Some people choose to ignore these.  Some put multiple projects into the same repo.  Both are fine because the mere fact people are utilizing source control in the first place, even if its just for disaster recovery, is great.

These folders, however, really do have a few reasons for their existence that have been well thought out.  Each source control system tries to out-do the next.  In Subversions case, the simple definitions are trunk is for the current version of your project, tags are for multiple older versions of your project, and branches are for experimental features or code that will possibly be merged back into trunk later.

Those are EXTREMELY simple definitions.  If you read the SVN book as well as other people who incorporate SVN into their workflow, the definitions and purposes can get quite complex.  For the project I’m currently on, branches take on a new meaning.  Not only are they where experimental code goes, but they each represent a user story.  Meaning, if I’m working on completing the user story where the user can modify their hardware device settings via a Flex form, that’ll go in it’s own branch.  Using source control to do this is pretty straight forward.  Instead of checking in here:

https://svn.server.com/repos/project/trunk/

You instead check-in here:

https://svn.server.com/repos/project/branches/sprint2/deviceform/

And the other developer with me would be working from:

https://svn.server.com/repos/project/branches/sprint2/registration/

Pretty easy right?  It gets even easier to check in.  No more, “Dude, have you checked your shiz in?” to another developer, or the cardinal rule of doing an update before checking in.  Now you can check in to your hearts content knowing it’s your own repo to abuse how you wish.

This has the side benefit of NOT breaking trunk… usually.  Again, the point of having frozen code you KNOW for a fact works is to use a tag, or a series of tagged builds.  A lot of developers get seriously bent out of shape if you break the trunk.  At one job, whoever broke the trunk had to use this monkey icon for their IM icon for one week.  It was funny until the 50th person asked why I had a silly monkey icon, and by that point, I was swearing I’d never break ANY trunk ever again.  This can possibly have the effect of keeping ‘em happy.  At the very least, this reduces the possibility of it happening because no one is working from trunk.

Instead, you check into trunk at the end of every sprint, or for my team, from Merge Day onwards.

Merge Day

Part of Agile is to have a day a few days before your UAT where everyone merges their working user stories into the same code base and “works out the kinks”.  Since everyone was coding in a different direction, this can be good and bad.  Good because they are working on completely unrelated things, but in GUI coding, we all know some things are extremely related.  Specifically, these are your data model in the form of ValueObjects, calls to a framework such as the use of Event classes in Cairngorm and PureMVC Mediators, and modifying settings in higher level view’s or CSS.

Since this can potentially have major consequences for some portions of a user story, or set of stories, it’s important to devote a pre-scheduled time where the team knows their code will be merged with everyone else’s code.  This is called Merge Day on my project and it happens every other Wednesday.  I take my branch and my co-workers, and merge his code into mine.  Then, I fix things that explode.  This could be as simple as just merging code over, or a complex verbal discussion to work towards resolving 2 different implementations.  No code is trivial.  If another developer added a style to MXML for example, setting the background color may seem small to you, but could be the difference between working or non-working code for the other developer’s code, so its important you do these merges together.

Once that is done, I merge into trunk, test again, fix explosions, and finally check in the working build.  I then upload a new build, or in the case of my current project, deploy a new build in a new sandbox utilizing Django’s web interface.  It can deploy to the web the latest bin-release that’s checked into SVN by merely clicking a button.  I’ll send an email to all members of the team identifying what’s new in the build.  This includes user stories, fixed bugs, and other things of note that are different from previous builds.

For fellow developers, this is a courtesy.  For Project Managers, it’s a necessity for them to set client expectations for Friday’s UAT.  For everyone it’s a Sprint milestone as well as reality check.  You can identify what user stories are done, which ones aren’t, what older ones you may have broken, and which current ones have issues.  You can then plan with your team what to spend the next day and a half on.  This is also where the rules can potentially break down.  What I’ll usually do is check my local copy into a new branch, and either fix partially completed or broken user stories, or just finish what I can.  The temptation here is to abandon branches since you only have a day and a half and it isn’t worth the trouble; just don’t break trunk in the meantime.

…riiiight.  The last thing you want to have happen the day before UAT is get all stressed out because trunk is broken.  To me, it’s worth the extra time in using the process to ensure your UAT prep goes smoothly.  I’m conservative.

I say that all high and mighty like, but on Sprint #2, I did just that.  Did I get lucky or was it just mad skillz?  Luck.

Conclusions

Now, all of the above processes could have been done with just utilizing trunk.  As you can hopefully see utilizing a branch for each developer, or multiple since creating a new folder is really easy, helps things go a lot smoother without surprises.  You can also plan for the chaos on Merge Day, which while extremely stressful for whoever is doing the merging, is at least expected and a concerted team effort.  I really have enjoyed the Branch Workflow so far.

…however, I don’t see it catching on.  Every Flash & Flex developer I’ve ever talked to doesn’t use branches.  Sam Robbins mentioned over Twitter they might start adopting this workflow at their place of work, and that’s great, but again, it seems to me most developers feel trunk is good enough and branches are just an unnecessary complication.

Stay tuned for #4 in the Agile Chronicles series where I talk about the POC (Proof of Concept), business strategy, and design challenges.

1. Part 1 - Stressful
2. Part 2 - Code Refactoring
3. Part 3 - Branch Workflow

This entry is about the joy of coding quickly, finding the balance between getting something done quickly vs. architecting for the future, and dealing with the massive amount of re-factoring that’s entailed in iterative Scrum development.

Coding Quickly

I’m coding like I’m in Flash again. Instead of spending 3 weeks setting up Cairngorm or PureMVC with all your use cases, agreeing on the framework implementation details with coworkers, and getting enough of a foundation together that you can actually compile the application and start seeing screens, you instead make a mad dash to get app working in just a day or less. Rather than discussing with your team what the best ValueObject structure is and how your service layer should work, you instead get a login service working in under 40 minutes. If something changes massively, such as the data structure of the user object returned, you just modify or delete & rewrite the entire ValueObject. You didn’t spend a lot of time on it anyway, so it’s not like your “architecture masterpiece” is getting deleted; it’s just some scaffolding code to get you up and running.

Coding For the Future

…yet, it’s not scaffolding; it’s real code that needs to work, and work the entire project. Deciding how much to write well & encapsulated vs. just getting it done is extremely challenging, and fun. When do you git-r-done and when do you over-architect? How much and where? Hard questions to answer, fun times. Part foresight, part gambling, all calculated risk taking.

You know your service layer, the code that talks to the back-end probably WON’T change.  It’s extremely unlikely that in the middle of your project, you’ll switch from .NET and XML to PHP and AMF.  Therefore, spending more time architecting that portion can be done so with confidence in using the extra time it takes.

Anyone from a design agency should already find that very familiar.  You have a series of impossible deadlines, and arrogant programmers (like me) exclaiming you must utilize OOP, design patterns, and frameworks.  You’re challenged with meeting your deadline(s), trying to do right where you can, and learning throughout the process.

This is slightly different in Agile for product development (or even service development) in that once launched, your application doesn’t have a limited shelf life.  It’s an actual product.  Traditionally software is used 3 to 5 times its original intended lifespan, although, I’d argue with web software that is lessening.  Even before launch, you’ll be extending certain areas, and expecting it to perform solidly.  Deciding what to hack together for deadline’s sake, and what to invest well thought out architecture time in is really hard.  REALLY hard.  And fun!

UAT’s As Checkpoints

During sprint UAT’s (every other Friday for my team), or even just posting the latest working build for the team to see, you’ll inevitably question certain functionality and performance.  ”Why is that screen so slow to load?”, “Getting to this screen is more tedious than it should be…”, or “My RAM and CPU usage are through the roof!”.  The designer may see their designed creation in action, and totally change their mind on how it should look or work.  The stakeholders, after using it, may realize that it totally doesn’t solve their original goal(s) like they thought it would.  You may even notice a bunch of positive enhancements to make on already working sections.

This may sound frustrating, but it’s good for a bunch of reasons.  First off, this is the main reason Waterfall fails as a process.  None of these things can happen until the project is COMPLETE, in the Validation phase where you validate the software is on spec.  A lot of you may already have had those things happen during a project; now imagine none happening until the entire product is complete.  It’s a lot harder to change that much code that late in the game.  You now have the opportunity to fix bad decisions, improve design implementations, and add enhancements… early!  This is when they can have the most positive impact, reduce risk, and get battle tested more.

Secondly, when you go to fix something, you can code with more confidence since the functionality has at least been used.  Programmers second-guess themselves all the time.  They have to; early decisions made incorrectly can have disastrous consequences later (quoted from one of the Pragmatic Programmer authors in an interview).  It’s really frustrating to be insecure about how a user story actually works.  After getting it “working” in a reasonable timeframe, and using & discussing it, you can have confidence in what you code is more “correct”.  Well… almost.

Third, your design gets more real.  After banging on the implemented version of the design comps, your designer/UX person can make better decisions if their design is actually working, and the programmers can collaboratively discuss how to change/improve it.  This assumes your designer/UX person hasn’t moved onto another project by this point; keeping them on retainer for at least 4 hours a week is helpful for the project.

Fourth, you get confirmation certain problems are in fact real problems.  You may think something is slow, but if no one notices but you, does it really matter?  Naturally, your ego as a programmer is inclined to fix it anyway, but remember, your goal is get things done, not fix something that isn’t broken.  Same goes for problems you know of and other people see; it is just an iron-clad check mark that something is in fact a problem and needs to be addressed.  If you have performance problems for full-screen video on your Mac in Safari and Firefox, and so does your project manager in Windows in IE, Firefox, and Safari, then you can confidently infer that the majority of other people will too.  Granted, testing with more than 2 people is preferred, but the point here is that you get a helpful checkpoint with a 2nd set of eyes.  Coding this quickly without too much care to architecture, juggling a lot of moving pieces is a lot to handle.  Having a helpful team member confirm an issue early is better than finding it months later in QA, even if you knew about it and forgot.

Bottom line, using a UAT as an early checkpoint for completed user stories ensures they truly are complete and good and points out problems or potential enhancements early.

Refactoring

The above leads to refactoring; re-writing or modifying existing code.  A lot of times refactoring is a pipe dream. Usually you’re so focused on getting things done, having time to make something work better or faster, even the possibility, is the carrot that can keep you going.

Not in Agile. Based on the past 5 weeks and talking to Darrell (my project manager at Enablus), you re-factor on average 30% of your code per Sprint. You’re coding so fast and so furiously, that not everything is encapsulated as much as it could be (except for my service layer, it’s tight baby!). Not only that, but as you see the software in action, you can then start making valid changes. Maybe the functionality didn’t work as good as you originally thought it would, or perhaps you suddenly realize, now that you see it, that it needs something added. While this is easy from a user story perspective, just modifying an existing user story or adding a new one, it may not be so straightforward in code. A lot of times, there was no way you could foresee the change you are now tasked at making. If we COULD see those changes ahead of time, there’d be no need for the Agile process in the first place. This means that some of your code needs to be majorely re-worked, or even just thrown away and done from scratch.

While you’re technically working on a user story, you’re potentially breaking another. It’s not necessarily spaghetti code, but it’s certainly not Orgathoganal by the Pragmatic Programmer’s definition… unless you’ve architected that section out already, you’re a bad ass, or lucky. I’d argue the 30% is a loose average. In the first sprint, I didn’t re-factor anything, nor the 2nd week into Sprint #2. In the 2nd and 3rd sprint, I was re-factoring up to 40%. In Sprint #4, it’ll definitely be at least 40% again. The 40% arose from taking 3 tries to get a piece of functionality the designer wanted correct. The 40% next Sprint accounts for my bitmap caching engine suddenly needing to save not just 1, but types of ValueObjects, and all the existing View’s that now need to support both. Not to mention the fact we were working with the server-side team for the first time and still figuring things out.  The percentages are not indicative of the entire code-base, but rather, my time spent the entire sprint (2 weeks).  All this while working on new user stories…

For example, while you originally stated a user story would only be a “2 - mostly easy”, it ended up taking you a total of 5 days to complete because you were re-factoring and fixing other existing user stories that it related to. This can lead to the perception that your original point estimations are inaccurate when in reality, your point estimations are accurate, it’s just there is no adjustments made for re-factoring. This isn’t always necessarily taken into consideration when forming a point average for what your team can complete each sprint. Some sprints, you hit your “20 average” and another, you only hit 15, but you could have possibility re-factored 7 points worth of existing user stories, thus skewing the results.

Refactoring really confirms how much you wish you could predict the future.  As I’ve stated before, sometimes it’s easier to just start from scratch again on a certain component now that you know better how it’s supposed to work.  The original piece of code may have been really small and not well thought out in the first place for the sake of time.  That’s totally fine, as the mere fact you’re deleting it and starting from scratch atests to it being a good decision at the time.  Other times, however, you’ll notice you’ll have to do some major changes to a bunch of different classes, of which because not everything is encapsulated, you may suddenly feel like it’s spaghetti code; changing one thing breaks another, totally unrelated piece.

I will say with ActionScript 3, strong-typing and runtime exceptions have really helped me refactor A LOT faster than in the past.  I can “break with confidence”, even if I know my code is crap (it isn’t, I’m just going for dramatic effect here… *ahem*).  This has really helped remove the “fear” factor you can get with touching code.  It’s one thing to have your code build trust with you.  You really thought about its architecture, beat on it some, and it held up.  Cool, your code has built some trust with you.  In coding quickly in Scrum, however, how much trust do you really have when only parts are uber-solid?  Knowing that your code is going into a real world product people are paying for doesn’t lessen the pressure and stress.

Again, AS3 has really helped me here.  If there is a problem, I’m more likely to find it now, and find it quickly.  Additionally, KNOWING that fact allows me to, again, code with more confidence, try more ideas, and end up with better code.  Now, you might think you should start coding for every eventuality, at least from assuming errors such as checking for null and isNaN like crazy, but quite the opposite.  A lot of the runtime errors can point out problems pretty quickly, and the catch here is they point them out in both quickly written code AND well architected code.  The point here is that even well architected code will have problems you don’t forsee.  What I end up doing is using my best guess at the time, using foresight based on our past UAT and other project detail discussions, and moving on with life.  Stressing too much about one section is a waste of time; if it works, rad, move forward.  You may rewrite it again later anyway…

What Doesn’t Change and What Does

Experience has really taught me what to code quickly, what to architect well, and all the in betweens.  I haven’t got it all figured out yet, but I DO know of some sections that usually never change, and ones that change all the time.

The ones that never change are the service layer.  This is your Business Delegates in Cairngorm, or your Remote Proxies in PureMVC (or if you’re like me, your Business Delegates that your PureMVC proxies call).  If they DO change, it’s because the server-side developer changed the the name of the service, or the location.  Whoop-pu-dee-doo… 1 line of code in either the class or your ServiceLocator.  If you’re delegates/proxies use Factories to actually parse the server’s returned data (XML, JSON, AMF, etc.) then you’re even more insulated.  Again, middle tier technology doesn’t really change in the middle of a project.

A data model change usually affects your entire application.  For example, if you change the data structure of a Person object (PersonVO), suddenly your Factory changes, your VO’s change, any Controller classes modifying PersonVO’s (such as Commands in Cairngorm or Proxies in PureMVC, and potentially Commands as well), and any View’s that represent or edit them.

If you’re creating complicated View’s, whether based on a design comp with little detail, or it’s not a conventional GUI control, it will definitely change over time once someone uses it and gives feedback.  Any View based on a list of dynamic data that needs to draw a bunch of children that represent a ValueObject, such as a repeater or a custom Chart will go through extreme refactoring; both modifications of item renderers and drawing performance improvements if you don’t extend List and do your own drawing routines.

View’s such as your main Application file, an optional MainView, a Login, and Menu’s do not change assuming you use 1 CSS file and straight forward skinning.

Most Event and Utility classes just get added to; you don’t really change them, rather you add or remove class properties and/or methods, but their names and package structure stay the same.

For Cairngorm Commands, they just grow in scope as the development age of your application increases.  Since PureMVC Commands delegate a lot of this Model modification off to Proxies, those Proxies tend to grow in scope as the complexity of your data interactions increase.  They only get waxed or massively changed if your data model does.  This doesn’t really happen later in the project.

The above is totally a case by case basis, but has been consistent on a lot of my projects.  Your mileage may, and most likely will, vary.

The Con to Refactoring

There are a few cons to soo much refactoring.  The first is, some clients don’t understand why you’re coding the same thing twice… or more, especially when Scrum is supposed to be about getting it done quickly vs. over-thinking it.  In my experience, if you can speak intelligently at a high level, you can explain each refactoring part away.  I can’t, so usually explain it to a project manager who’s capable of translating it in lamens terms to a client.

The second thing is that it makes merging on Merge Day a TON harder.  You may have already refactored like twice the week before, and totally forgotten all the details of why you did.  Suddenly, 4 days later (every other Wednesday in our case), you’re having an insanely hard time merging code from your branch(es) into trunk.  This may require a long conversation with your team members, and you are struggling to remember why you made such massive code changes.  Even if you do remember, the other developer may feel a little frustrated if you didn’t invite them into the code refactoring change discussion for something you may at the time have felt was trivial.  It probably was trivial, it’s just blown out of proportion now since merging is always stressful.  Either that, or you just spend a few hours getting trunk working again.  If I totally wax something, I’ll usually put a large drawn out code comment to explain why.  Additionally, I’ll do the same thing in SVN check in comments.

The third thing is it’s a project manager’s nightmare.  If she doesn’t have enough forewarning of these and their possible affect on not getting a single or set of user stories done by the end of the sprint, it can be a bad surprise.  Communicating these during the daily standup meeting with potential ramifications is best.  It can also make planning future sprints challenging as well.  If your team has been chugging along at an average 12 points per sprint for 3 consecutive sprints, and suddenly in sprint #4 you spend 60% of your time refactoring, you’re clearly going to finish with a lot less points in user stories completed.  This sets the project manager up for failure.  They cannot effectively communicate projected progress to the client, nor visibility into the current progress of the app since something that worked for awhile may suddenly break in the next UAT.  You’re supposed to be completing user stories, not creating new ones that break old ones.  Again, forewarning is the only thing I know immediately to do.  I’m not sure what doing too much refactoring is a symptom of yet.  Most so far on my current project, and past ones, have been for random reasons.

Conclusions

I really like how fast I can code some things in Agile.  Other things have stayed the same, but the overriding goal of “get it working, but don’t write crap code” is such a high bar… and I love it.  It’s the same speed of agency coding, only you know you’ll have to live with the code (aka potentially eating your own mess) so you end up producing better code than you would in an agency setting.

I also like either drawing on experience, or just making challenging inferences, on what to architect well, and on other parts to just get something working without too much thought.  It’s nice to have the variety.

Finally, I’m not sure what to think of the refactoring.  I like that it’s “ok” and an expected part of the process, but I feel that my project is unique in the amount I’m personally doing.  My coworker for example isn’t doing as much as I’m doing at all; he’s chugging along on other user stories and is set to beat me, again, in point values for user stories completed at the end of this sprint.  We’re really pushing the limits of Flash Player here, and only one section in this large app is really this challenging; the rest are your run of the mill Flex screens.  So, it sounds to me like the “on average 30% of your time is spent refactoring per sprint” still applies.  There is no way I’ll be refactoring this much on some of the easier sections in future sprints.

Stay tuned for #3 in the Agile Chronicles series where I talk about every developer using their own Branch in Subversion.

1. Part 1 - Stressful
2. Part 2 - Code Refactoring
3. Part 3 - Branch Workflow

This entry is about what processes I came from, my definition of the Agile/Scrum process, and how stress has been spread out throughout the project vs. at the end.

Skip Intro

Preface

Five weeks ago, I started a project with Enablus, a firm that works with mainly startups to build products. I loathe service work, and love product work, so am really glad to be working with them. Even better, they are only 30 minutes from my house. I don’t really need to go more than 2 to 3 times a week, but I like how close they are when I do. One thing that struck me in the initial project discussions was that Enablus was really big on process and lingo. Darrell Ross, the project manager and partner I’m working with, although hard to read initially, still showed signs of uneasiness when I didn’t give him the answers he was wanting to hear in the initial discussions. For example:

“Do you utilize Continuous Integration?”

“Uh… what the hell is that?”

“You know, everyone on the team checking in code into a source control system every day, utilizing Test Driven Development practices, automating your builds, etc.”

“Er, I use Tortoise SVN and BeyondCompare all the time! Although, most people I work with don’t check in every day, don’t use TDD, and do not automate their builds.”

“I see…”

We’d constantly go through this. He’d ask a serious question like, “Do you utilize OOP and an software framework(s)?” and I’d respond with some cynical response questioning the merits of when OOP and frameworks are applied, or what I did and did not like about a particular framework, and how I don’t always officially follow their implementations… never really answering his question and thus not giving him confidence. I was constantly amazed at how structured Darrell made things sound, and he probably wondering how the hell a positive impression of “Jesse Warden” was formed in his head in the first place based on the answers I was giving him.

In all instances, we’d discuss the details of my responses, and he seemed to get the details he needed, feel better, and move on. Too ease his stress, I opened up and said that I’ve never really worked in places that were above a Level 3, and even those I felt never followed the processes he was mentioning, specifically Waterfall or Agile development, to the letter. Later in my consulting and contracting career, I had moved to using some concepts of Agile such as iterative development, and having builds of the software regularly on a schedule (usually weekly) even if the client didn’t need one for weeks or months. It had nothing but positive ramifications in the long run, so I stuck with what worked and saw other successful people doing similar things. It’s really a simple process (my version): Have a build working by Friday, every Friday.

I’m not sure Darrell believed me that everywhere I’ve worked, whether full-time or consulting/contracting, did not use a standardize process such as Agile. Maybe it did and I just wasn’t privy to the details?  Again, I never cared till this year.  Either way, nothing sounded as strict and defined as Darrell made it sound as he described the Agile process to me. Hence the point of this series of posts.

Introduction

I’ve never been interested software development processes. To me, it’s always been more important to be really good at the 3 main things that count: knowing your platform, knowing your tools, and knowing the language you code in. The better you know those 3 things, the more capable you’ll be at developing software, helping those on your team develop software, and thus ensure your team will be successful. As Dave Wolfe has said, it takes a village; a great team can ensure success. Whether the project actually succeeds isn’t really up to the software team at that point; hence the second rule to the “8 of 10 software projects fail” is “9 out of 10 are perceived as failures”. Even if you create an awesome piece of software, management, stakeholders, and/or clients can still perceive it as failing.

As I’ve found throughout my career, there have been more pressing issues than “process”, such as:

• getting the dang design comps
• making a workflow where fonts will compile on both machines (Mac and PC)
• coming to a conesnsus with team members on how the framework you are using should be implemented
• finding out what the heck we are building really is
• finding out how the heck what we are building really works
• resolving source control issues

There are tons of other things, but each has the capacity to reach fire drill status, and thus become a major time sink and productivity killer. As you know, losing time is the LAST thing you want to have happen in software development.

It also depends on the type of work. Working with Design Agencies, there was no process. Not because Agencies are dumb, but rather because the project timelines Agencies have are typically significantly shorter than traditional software or product development. On average, 2 weeks vs. 4 months. While a deadline can stretch to 4 months, you only work 10 man days on it, and of those 10, 5 are done initially, and the other 5 are done over the course of 2 or 3 months on client changes. In short, if you have 5 days to complete a complicated coding project, you’re more focused on getting things done than you are worrying about encapsulation, continuous integration, and frameworks. Writing code on day 1, and wondering who in the heck has time for UML and test cases. Agencies are deadline driven, whereas in software development, nothing is ever on time.

In consulting, you’re typically working within the constraints of your client’s company. It can go down two different ways. Either you get treated like a service shop, and requirements are thrown over the wall, and you complete how you see fit. Otherwise, you integrate with an existing team, and work within their processes, trying to improve them where you can. Contracting is usually the same way, although, you usually have little to no say in the process.

Even including regular work (W2 at a software shop), all instances can significantly have their chances of success improved through skill. If you’re skillful in the aforementioned 3 areas (platform, tools, language), it doesn’t matter how screwed up things are; you can always depend on skill to make or break a project.

…or so I thought. Going back to the 2nd rule of software development, “9 out of 10 software projects are perceived as failures”, I started to have more of the second rule happening vs. the first.  In those projects, more of my time would be spent doing non-software things, like pitching a tent in the project manager’s office, discussing details with stakeholders, drilling sales on what they were really trying to accomplish, etc. In the end, trying to define success to ensure my team and I weren’t setup to fail from the beginning. Being setup to fail, yet having a team with mad skill, results in you months later outside the office smiling on your umpteenth beer regaling all in the pimp architecture you created that never did, nor will, see the light of day. Creating awesomeness with no result is extremely more frustrating than flat out failing. The positive to failing is you can learn from it. Failing, even though technically you succeeded, is just straight ridiculous, and it was at those points I started to become more interested in the software development process. I realized I needed to find a team who knew all these processes I’d read about on the internet blogs.

Enablus is one of those teams. They clearly know Agile, as far as I know it 5 weeks in.

Agile As I Know It

I got Darrell to explain how Agile, specifically the Scrum part, works. This is my paraphrased, and re-interpreted version of our discussions, and my working with the process for a few weeks.  If you have a good idea, do market research to ensure it’ll sell, then you just need a good team to execute it. The execution on the software side for product development utilizes an Agile approach.

User Stories

The Agile approach, for the engineer, starts by defining “User Stories”. User stories are a set of sentences that describe what the user experiences while using the software. These can be derived from the wireframes; design comps aren’t a requirement. A user story can be expressed like so:

Login: User inputs Username and Password and clicks “Start Application”. Login is validated. For all other login instances, the Dashboard is displayed.

Notice there is no implied technology or design construction details. The user story merely describes what the user see’s, what interactions the do, and what the results of those interactions are. That same user story could apply to Flash, Silverlight, AJAX, PHP, etc. It’s technology agnostic; the point here is to document a user experience to ensure we’ve captured it well enough to be understood, and thus executed upon. The same goes for design. It doesn’t say “2 text input fields for username and password, with bold headings to the left, aligned center”. It’s left up to the interpretation of the designer to execute that user story, and hopefully provide direction for the GUI programmer through design comps assuming the user stories were derived from the wireframes, and not the design comps.

Notice also, it’s not a “feature”. It doesn’t say, “The user can login”. That leaves things massively open to interpretation, and solves no business value even if the feature is “completed”. As we all know, not all logins are the same. Documenting features, and executing them is one of the number one ways to be setup to fail, and is also one the main reasons Waterfall doesn’t work. If a software spec says, “The user must be able to log into the system”, but doesn’t describe registration, single sign-on, error scenarios, and how it’s supposed to look, you’ll end up with software that the client doesn’t like.

Some user stories are extremely high level. These are sometimes called meta-stories because they actually encompass a wide array of smaller user stories. Describing a login scenario can have a multitude of smaller user stories within it such as “user is presented with an error dialogue stating that they must first activate their account via the confirmation email before gaining access to the entire application’s feature set”. The level of detail only matters in so much as to make sense to the designer and engineer executing it. If a user story encompasses weeks of coding, it’s probably a meta-story and should be broken down into more manageable user stories that are easily defined, and more easily tackled in a reasonable time frame. What’s reasonable and doable is different for each team.

You create user stories for your entire application. What does, rather what SHOULD, the user be able to see, do, and experience?

Backlog

These user stories go into a “Backlog”. This backlog is a list of all the user stories, say 50… or a hundred. How many user stories you have are irrelevant. What’s important is that they are all documented in one place called the Backlog. You need to ensure all of the user stories are valid with the stake holders. It also helps to go over them with your entire team to ensure they make sense to everyone involved.

As you move through your project, you may find you’ll need more user stories to account for things you didn’t think about, or for additions/modifications to existing user stories. You then just add them to the back log. It’s normal for a backlog to grow during a project life cycle. However, you do not have to complete the entire backlog to complete the project. A lot of times, the stakeholders will make a business decision that 40 of the 60 user stories is enough to have a great product, and say “ship it”. That’s one of the key benefits to Agile is that you have working software throughout the project, and at anytime can make the determination of when it’s “done”… or is just a version 1.

Point System

Once your done with your backlog, you then have your team go through and assign points to each user story. To do that, you need a Point System. A point system is defining a metric for “how challenging something is”. In simple terms, a 1 is easy and a 5 is hard. It doesn’t have to be 1 through 5; it could be 1 through 10 or whatever. It’s best if they are numeric values because you use the points to measure a variety of statistics about your project. Additionally, each team may have their own definitions of what is challenging. While it’s best to use the same 1-whatever metric for the client and server team, the server team will most likely think creating a new server-side method a “1-easy” whereas a client developer a “5-hard”.

Once you’ve defined your point system and gained consensus amongst the team, you then go and assign a point value to each user story. This in essense gives each user story a “value”; how many points a user story worth. If you have multiple team members working on different parts of the system, say server-side and client side, you then have a point value added to each, such as “2 - mostly easy” for the server-side portion and “3 - doable” for the client side portion. The combined value gives the value of the user story, in this case 5.

From these point values, the project manager can then go back to the client, and ask, “With 20 points, what features do you wish to have completed in the first Sprint?”

The client can “purchase” user stories using those 20 points. A Sprint, which I elaborate on below, is an uninteruppted time period in which your team works on completing their assigned user stories. You make a guess in Sprint #1 on how many points your team can complete per Sprint. As time goes on, you start to see a pattern emerge of how many points per Sprint is the team completing. The client and managers can use this metric for planning and resource purposes. You can forecast, somewhat, how many Sprints you have to do to complete 60 points worth of features, and when you’ll have them completed. The chosen user stories that the client purchased are what your team is working on in Sprint #1.

Assigning points is a very important step for the engineering team. You typically don’t change point values mid-project, only assinging points to modified user stories or new user stories.

Sprints

As I mentioned, Sprints are a period of time that your team works on their assigned user stories. A sprint is however long your team decides it should be to get a working build with the user stories assigned. This could be one week, two, or a month. My current team is using 2 week cycles. It’s important to note the “uniteruppted” part. The client and project manager won’t interject user stories mid-sprint, nor modify your work load. Basically, they don’t bother you. This allows your team to focus on the task at hand, prevent fire drills, and stay productive.

In the examples provided, your team has 2 weeks to complete 20 points worth of user stories. Now, a sprint isn’t just, say 10 days of straight working. You usually have 3 special days. The first day is the kick off. You determine the user stories you and your team members will tackle. A couple days before the last is your “merge day”. It’s when everyone merges the code together from their different branches (or you just make sure trunk works if not using branches, more on that later) to get an idea of where the build is at, and where your team is at with their user stories. This is a final checkpoint before…. the UAT. UAT stands for user acceptance testing and in this case, it’s going over the final working build. Your team collectively goes over each user story, and identify if the build satisfies the user story or not.

As I said, our sprints are 2 weeks in length. The first Monday is spent confirming what user stories are in the current sprint and who’s working on them. We try to work in our own personal branches so the 2nd Wednesday is “Merge Day”, where I take any branches I and my teammate have, merge into trunk, and work out the kinks. We make a mad dash the rest of Wednesday and all of Thursday to finish our remaining user stories, or fix issues with existing ones, or just the build in general. Again, over the course of a sprint, you can start to get a group average of how many points your team is capable of doing in a sprint.

We’ve been using a shared Google Spreadsheet with each Sprint’s user stories in its own tab.  We collaboratively use this all the time for reference.

Daily Standup

We have a call everyday at 1 pm EST / 10 am PST. Our server-side time + client is out west in Cali, and our Flex team + UX + designer + project manager + rest of the team for other areas is east in Atlanta. We each go around talking about what we completed yesterday, this morning, and what we plan on going the rest of the day. We also cite any roadblocks or issues, and if that involves another team member, we just schedule a separate call, or time to talk over IM, with that specific person. This results in our calls usually lasting 5 minutes each day. I’ve heard of other projects at Enablus having their daily standup lasting longer than 5 minutes, but our team is pretty focused; we know what we need to do.

The majority of my road blocks involve a web service not working like expected suddenly, or questions for the designer on how a part of the design comp is supposed to work. Most of these I just solve on my own by calling the team member outside of the meeting time.

Pro’s & Con’s

There you have it, what Agile is based on what I’ve been told and experienced so far. So how’s it working out so far? Here are the pro’s and con’s for this first entry in the series.  I’ll elaborate in future articles, but here’s the quick rundown.

Pro’s

• I’ve never been this stressed in the first two weeks of a project before.
• coding with a “git-r-done” mentality; fast and furious.  Not everything has to be uber-architected.
• each developer has their own branches; this makes checkins & merges a lot easier and less stressful
• It’s nice to have something real after just 2 weeks.  Gives a great feeling of validation very quickly

Cons

• a lot of re-factoring
• creating new user stories later can break older ones
• merge day is stressful
• “need to see it working”; the desire to see working functionality before important functionality decisions can be made isn’t solved

Conclusions

In conclusion, I really like Agile methodology that we’re using so far as it allows me to code some things extremely fast and not have to worry about uber-architecting it. I just have to get it working which I’m good at doing quickly. For the things that matter, I can spend an allocated time which I feel good about doing because I can more easily see over time which areas deserve architecture and which ones do not.  The merge day is extremely stressful, but overall I like having an allocated day for it and using separate branches which prevent daily SVN drama.

I’ve never been this stressed in the first two weeks of a project before. The typical scenario is you get excited, and can’t wait to dive in. It’s a happy feeling filled with anticipation. Then, as the deadline approaches, you steadily get stressed out and things become less fun, albeit extremely frustrating. This isn’t always the case, but I’ve continually expected fun in the beginning, stress at the end.

It’s been really nice to be stressed at the beginning; this has implied to me the project won’t be so traditionally bipolar. The same thing happened to my mood once I capped myself at 2 cups of coffee a day. Think of it, you have 2 weeks to create working software; ready, GO! That’s insane, and really cool at the same time. What could you do in 2 weeks? It’s really nice to know that even after just 2 weeks of work on a 4 month (ish) long project, even the first 2 weeks will produce something valid and working.

Stay tuned for #2 in the Agile Chronicles series where I elaborate on the re-factoring challenges.

Error #2176: Certain actions, such as those that display a pop-up window, may only be invoked upon user interaction, for example by a mouse click or button press.

Doh!

The converted image received from the server would trigger a FileReference.download.  Adobe did make announcements with commentary, but the unique nature of the change, and the fact that Flash Player 10 didn’t have wide adoption when these announcements came out (still doesn’t) made them pass through one ear and out the other.  They weren’t relevant at the time because Flash Player 9 works, and you move on with life.  Not to mention the fact this is an event driven security change, which makes it not so black and white.

Fixing this in our Flex app isn’t a big deal, it’s just that some of our team is on FP9, including their development boxes.  The con is, we weren’t planning on developing for Flash Player 10, but now we have to.  The pro is, we can now leverage FP10 features such as saving images locally vs. using a server to do it.

Naturally I’m wracking my brain this morning trying to remember all the applications I’ve written that utilized FileReference.upload and download.  I’m pretty sure all were initiated by a mouse click.  I just feel bad for all the poor bastards who utilized ExternalInterface to do it on past client websites and are now screwed.