Here is an example of how ARC changes your life for the better…

In the old days you would declare out your ivars, declare your properties, then synthesize and map them together, and release them in a dealloc method. This little design pattern required 4 repetitive lines of code for every ivar (instance variable) and engendered flamewars about  coding style and where underscore should go (if you thought it was necessary to distinguish an ivar name from a property name).

Pre-ARC Entity.h

#import "cocos2d.h"
@interface Entity : CCSprite {
BOOL isActive_;
NSString * name_;
}
@property (nonatomic) BOOL isActive;
@property (nonatomic, copy) NSString * name;
@end

Pre-ARC Entity.m

#import "Entity.h"
@implementation Entity
@synthesize isActive = isActive_;
@synthesize name = name_;
- (id) init {
  self = [super init];
  if (self) {
    isActive_ = YES;
    name_ = @"Fang";
  }
  return self;
}
- (void) dealloc {
  [name_ release];
  name_ = nil;
  [super dealloc];
}

In this new modern era of automated reference counting I just declare properties, I don’t worry about accessing the ivars directly, and I don’t write my own dealloc. It’s a lot less code in a complex game where characters and objects have dozens of properties.

Post-ARC Entity.h

#import "cocos2d.h"
@interface Entity : CCSprite
@property (nonatomic) BOOL isActive;
@property (nonatomic, strong) NSString * name;
@end

Post-ARC Entity.m

#import "Entity.h"
@implementation Entity
@synthesize isActive;
@synthesize name;
- (id) init {
  self = [super init];
  if (self) {
    isActive = YES;
    name = @"Fang";
  }
  return self;
}

To get Cocos2d-iPhone to work with ARC was really easy: I just replace the NSAutoreleasePool object in main.m with the new ARC friendly @autoreleasepool annotation. (I might not have had to do this but it’s supposedly more efficient.)

int main(int argc, char *argv[]) {
//    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
//    int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
//    [pool release];
//    return retVal;
  int retVal;
  @autoreleasepool {
    retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
  }
  return retVal;
}

The downside, as I stated above, is that your app will only run on iPhones, iPads, and iPods running iOS 5 and you need to use Cocos2d-iPhone 2.0. But I think that’s a fair tradeoff. Backward compatibility is a killer of the artistic soul and should be avoided where possible. To Err is human, but to upgrade is divine

Check out Ray Wenderlich’s excellent ARC tutorial for all the gritty details!

So I’d like to frame an argument against dogfooding and in favor of something else: Plagiarism.

My argument goes like this:

1. Dogfooding doesn’t work, or at least it’s not sufficient, because it’s not a good predictor of software success. Some software that is dogfooded is very successful. Most software that is dogfooded fails. (Most software fails and most software is dogfooded therefore dogfooding fails.)
2. Dogfooding is really bad because it give you a false sense of doing something to improve your product: “It’s OK, I know our software is terrible but we’re forcing our employees to dogfood it and out of shear frustration they will make things better! Everyone go back to sleep…”
3. Dogfooding reinforces bad product design. Human beings are highly adaptable (and last time I looked software devs are still considered human). We get used to things, especially in a culture where company pride and team spirit are valued (e.g. groupthink). Over time poor performance becomes typical performance. It starts to feel natural. Thus slow loading Windows operating systems become the gold standard for thousands of loyal Microsoft employees and customers. Instead of fixing the software we are fixed by it.

I believe that the urge to Dogfood is an emergent strategy of mature tech companies that want to rejuvenate their software development process. Management starts talking about Dogfooding when they realize the spark of creativity has gone out and they want to reignite it.

One of the reasons Dogfooding fails is that you never eat your own dog food in the beginning: The dog food didn’t exist yet. You had to get your inspiration from outside the company. Microsoft Windows was not the first OS with a graphical mouse-driven shell. At some point the Windows devs must have looked at the Apple Lisa and Macintosh computers for inspiration. And the Apple devs looked at the Xerox Star. And the Xerox devs drew their inspiration from the physical world: The first GUI desktop was modeled on an actual physical desktop. No dog food there.

So rather than dogfooding we should talking about plagiarism. If you want to make a great software product eat another a great software product and make it taste better–don’t eat yucky dog food.

Microsoft should force their devs to use the fastest computers running the best operating systems with really cool applications. I think they must have bought some MacBook Airs, installed Ubuntu and Spotify because Windows 8 looks pretty awesome

If you want to understand how a great tutorial is written you can’t do much better than Kochan. Unfortunately a lot has changed in the Mac OS X world since 2003 and the code examples don’t compile. The code is fine. It’s the default compiler setting that have changed. A Google search on the compile error brought me to a a good discussion on the problem on Apple’s developer support forum. You have to dig but the fix is pretty trivial if you know gcc complier flags (which the target audience of a primer are unlikely to know).

My advice to students and armchair time travelers who want to follow the original book is to resist the urge to change the source code examples to inherit from NSObject. Instead use the -arch i386 flag as suggested by very helpful forum user Constantino. (Mysteriously Constantino’s forum name is spelled with a K.)

In other words instead of compiling with

gcc ClassName.m -o ProgramName -l objc

use

gcc -arch i386 -o ProgramName ClassName.m -lobjc

To compile and run the OOP first example of the book from the terminal you can copy and paste the following 2 lines:

gcc -arch i386 -o Fraction Fraction.m -lobjc

./Fraction

And for the full experience, don’t use Xcode or a fancy text editor. VI is fun, old school, and Apple’s Terminal a joy to work with.

Notes:

• There is a third edition that probably addressed this issue. But what fun is that if you only have the original edition? I would love to set up an old Mac with a vintage version of the Mac OS X to really immerse  myself in the experience!
• There is also also a Programming in Objective-C 2.0 3rd Edition which looks like a lot of fun to read and which might actually be more relevant if you have an urgent need to write a modern Mac application.

But in the meantime I’m working on an iPhone game and I have a free subversion repository from my ISP. I want to continue to use this fee repository even though Apple gently nudges you to GIT with Xcode 4.

I’m stubborn. I tried GIT and it’s not doing anything for me. My change control needs are small. The functionality that makes GIT great is way more than I need: I’m not working on a large team with a complex build system that has to commit changes with the finesse of a tightrope walker.

Today I went back to subversion and my free repository when I had to update my iPhone to the release candidate 3 of the Cocos2d framework (which is host on Github BTW). Back when Xcode 4 was release I just could get Subversion and Xcode to play nice. But being stubborn, I tried again and to my surprise succeeded.

I don’t think Apple changed much. I think I was just impatient and misinformed. There is a lot of silliness about how to set up Xcode 4 to work with a Subversion repository on the Internets. What worked for me is the functionality that Xcode gives you out-of-the-box (without using the terminal). It was point-and-click but just not automated.

If you’re interested here is how you get a hosted subversion repository to work with Xcode 4. Have fun and don’t sweat the snickers from your more version control evolved friends

1. Create a new Subversion repository that you can access via your protocol of choice (mine is the open Internet and HTTP because that’s what Dreamhost provides). Leave this repository empty–we’ll use Xcode 4 to set up all the directories. Just remember your URL and password.
2. Open Xcode 4 and go the Repository tab in the Organizer Window.  Click the tiny little plus sign in the lower left corner to add a connection to a Repository. Enter in the URL and password and wait for the little circle to turn green. Xcode 4 should automagically detect the type of repository. Be patient. This process takes a bit of time and there is absolutely no feedback: Apple forgot to spin the beach ball here.
3. When you get the green circle click on the root directory icon on the left under the name of the repository and create 3 directories using the New Directory button on the bottom: trunk, branches, tags. Be patient again and wait for the directories to show up in the center pane of the Organizer window.
4. Click on the name repository on the left and enter the names of our your 3 directories in the 3 fields provided. (See the genius of naming them trunk, branches, tags?) If your spelling is good you’ll get 3 more green circles.
5. Click on the Trunk directory on the left and then click on the Import button on the bottom. Select the folder that contains the project you want to put under source code control. Now go away. Get a drink and watch an episode of South Park. You have to be patient because not only is there no beach ball, spinner, or progress bar, there is no green circle!
6. When you come back you should see your imported directory listed on the main pane. If you click the arrow to the left of it you’ll find your Xcode 4 project file and a subdirectory of files. Remember to be patient. Your poor overworked laptop has to ask the Subversion server for all this info and it takes way longer than 200 milliseconds to get back to you.
7. Make sure your original Xcode project is closed and hidden away for safe keeping. Click on the imported project in the main pane of the Organizer window and click on the Checkout button on the bottom. Select a location on your hard disk to store your working copy of the project that won’t conflict with the original project. It should be OK to overwrite the original but I’m just paranoid. (Years of experience will do that to you.)
8. Get a cup of coffee and troll Reddit for some laughs. When you come back Xcode should ask you in a dialog box if you want to open the project that you just checked out. Say yes and run it just to be sure it’s all there. (Paranoia again, sorry.)
9. Now make a change to your and look for the little M to the right of the file name in the Project Navigator pane to show up. Be patient. If it’s not showing go back the the Organizer Window, back to your Project folder (by selecting its name on the left), and click the Commit button. The little M should now and forever show up next to your modified files in the Project Navigator.

I’m still having a little problem committing from the context menu in the Project Navigator but I can commit just fine from the Organizer Window. Maybe that’s just how Subversion works with Xcode or more maybe I have to be even more patient. I’ll let you know!

With the idea that other people beside me might actually play my game I’ve started to do a very dangerous and high risk activity: Optimization!

The all the famous Computer Scientists and Software Architects agree: Optimizing your program is a necessary evil, like the death penalty or bug tracking systems, and to be avoided at all costs.

Well, that’s not quite true. It’s premature optimization that is the bad guy here. Don’t start out programming with performance or scalability in mind, least you optimize code that doesn’t need it and miss optimizing code that really needs it. (It’s the same for bug tracking systems–don’t put all your junk in Jira or Bugzilla–just the verifiable, repeatable bugs that you might actually fix one day.)

When I started my game I knew my ideas were going to evolve and I didn’t want to hard code myself into a corner. I consciously wrote code that I knew would be slow but flexible.

For example I used expensive string comparisons instead of testing for cheap numeric constants. During the initial development phases of my game the strings were self-documenting (I could read them like little notes to myself) and easy to change. Later, when my game solidified and the string comparison were easy to find using Xcode’s Find in Project command (which is now Xcode 4′s Find in Workspace command)…

// before optimization
if ([goodGuy.role isEqualToString(@"tank") {
   // aggro something
} else if ([goodGuy.role isEqualToString(@"healer") {
   // fix something
}

// after optimization
switch (goodGuy.role) {
   case CharacterRole_tank:
      // aggro something
      break;
   case CharacterRole_healer:
      // fix something
      break;
   default:
      // oops! This should not happen
      CCLOG(@"unknown character role in %@",NSStringFromSelector(_cmd));
      break;
}

Changing the type of Character's role property from NSString* to CharacterRole (a typedef'ed int) sped up my game in update methods which were called with every frame change. It was a pain to add all the constants but at least I only had to do it once--even though my conception of a Character and a role changed quite a bit.

// Character.h
typedef enum {
    CharacterRole_tank = 0,
    CharacterRole_healer = 1,
    CharacterRole_melee = 2,
    CharacterRole_ranged = 3,
    CharacterRole_boss = 4,
    CharacterRole_add1 = 5,
    CharacterRole_add2 = 6,
} CharacterRole;

// Character.m
@interface Character : NSObject  {
   NSString* _name;
   CharacterRole _role;
   // ...
}
@property (readwrite, copy, nonatomic) NSString* name;
@property (readwrite, assign, nonatomic) CharacterRole role;

Another big optimization I did was to replace for-loops and with Cocos2d's fast enumeration macros...

// before optimization
Character* goodGuy = nil;
for (int i = 0; i < self.goodGuys.count; i++) {
   goodGuy = [self.goodGuys objectAtIndex:i];
   // do something with good guy
}

// after optimization
Character* goodGuy = nil;
CCARRAY_FOREACH(self.goodGuys, goodGuy) {
   // do something with good guy
}

My list of good guys changes during the game so I stored them in a CCArray–Cocos2d’s version of a NSMutuableArray. CCARRAY_FOREACH is a Cocos2d macro supercharged for fast array access. I could have used the Objective-C version of a fast numerator but I like to use as much of Cocos2d as I can. That way when I port my game to Cocos2d-x (C++ cross-platform version) it will be less work

One of the biggest optimizations I did was to upgrade from Cocos2d 0.99.5-rc1 to 1.0.0-rc. You have to be smart about when you upgrade to a new version of a framework. I don’t agree with the idea of living on the bleeding edge–stability of the platform allows me to focus on my own bugs!

Upgrading from Xcode 3 to Xcode 4 also seemed to help, or at least not hurt, performance. The new version of Cocos2d seems to work better with Xcode 4. I’m still getting used to the shiny new Xcode–it acts weird and slow on my Mac Mini.

To make framework and Xcode upgrades easy I put very little code into my app delegate class. All I have to do is to comment out…

//[[CCDirector sharedDirector] runWithScene: [HelloWorldLayer scene]];

and replace it with…

[[CCDirector sharedDirector] runWithScene: [HomeScreen scene]];

There are lots more optimization I can do if my performance isn’t where I want it to be: Unroll my loops and get rid of Character lists altogether. But I’ll lose a lot of abstraction and flexibility so I’m not going to optimize anything more unless my beta testers complain!

Cocos2d-iPhone provides several means for tracking time in your game and scheduling methods to be called at both regular heartbeats and at arbitrary points in the future. The easiest way to manage time in a Cocos2d-based game is to use a CCLayer’s scheduleUpdate or schedule methods. Both methods are explained nicely in the timers section of the Cococ2d Best Practices guide. The guide also explains why you should try to avoid using iOS’s NSTimer class. (Your game will miss out on automatic pause and resume if do use NSTimer.)

But what if you can’t use scheduleUpdate or schedule in your game because you’re putting your game logic into a custom class instead of a CCLayer or CCSprite?

For the sake of simplicity and portability I don’t subclass CCSprite in my games. Instead, I create custom classes to represent my game objects and call update:(ccTime)delta on them from CCLayer objects to make stuff happen. I needed a nice timer class and started to write my own. About halfway though this project I ran into Cocos2d’s CCTimer. Since I’m trying to write as little code as possible I abandoned my timer. CCTimer is a nicely written, lightweight timer class that uses NSInvoker to create callbacks and still integrates will with the rest of the Cocos2d-iPhone framework.

Here’s how it use it…

First, I store a reference to a timer in my non-Cocos2d class:

// Zombie.h
#import "cocos2d.h"
@interface Zombie : NSObject {
    BOOL _resurrectable;
    ccTime _resurrectionCountdown;
    CCTimer* _resurrectionTimer; // own
    float _rebirthPenalityPercent;
}
@property (readwrite, nonatomic, assign) BOOL resurrectable;
@property (readwrite, nonatomic, assign) ccTime resurrectionCountdown;
@property (readwrite, nonatomic, retain) CCTimer* resurrectionTimer; // own
@property (readwrite, nonatomic, assign) float rebirthPenalityPercent;
- (void) startResurrectionTimer;
- (void) stopResurrectionTimer;
@end

// Zombie.m
#import Zombie.h
@implementation Zombie
@synthesize resurrectable = _resurrectable;
@synthesize resurrectionCountdown = _resurrectionCountdown;
@synthesize resurrectionTimer = _resurrectionTimer;
@synthesize rebirthPenalityPercent = _rebirthPenalityPercent;
+ (id) getInstance {
    CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
    return [[[self alloc] init] autorelease];
}

- (id) init: {
    CCLOG(@"** %@: %@", NSStringFromSelector(_cmd), self);
    if ((self = [super init])) {
        self.resurrectable = YES;
        self.resurrectionCountdown = 30.0f; // half a second
        self.resurrectionTimer = nil;
        self.rebirthPenalityPercent = 0.10f; // 10% less health
    }
}
@end

Second, I define a call back method to stop the timer:

// later on in Zombie.m
- (void) stopResurrectionTimer {
    CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
    if (self.resurrectionTimer != nil) {
    // the only way stop a timer is to deallocate it
        [_resurrectionTimer release];
        _resurrectionTimer = nil;
    }
    // do stuff when the zombie dies...
}

Third, I define a method to start the timer:

- (void) startResurrectionTimer {
    CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
    if (self.resurrectionTimer != nil) {
         // if there is an old resurrectionTimer then deallocate it
         // (this is the only way to stop a timer)
        [_resurrectionTimer release];
        _resurrectionTimer = nil;
    }
    //  allocate a new timer with a built-in factory method
    // the stopResurrectionTimer method is called when
    // the time is up!
    self.resurrectionTimer = [CCTimer timerWithTarget:self
                                             selector:@selector(stopResurrectionTimer)
                                             interval:self.resurrectionCountdown];
}

Fourth, I add a call to update the timer in my CCLayer’s update method:

// ZombieGameLayer.m
- (void) update:(ccTime)delta {
    [self.zombie.ressurrectionTimer update:delta];
}

Finally, Somewhere deep in my game logic I start the timer at the right dramatic moment.

// somewhere else in Zombie.m
- (void) die {
    // call when killed
     CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);

    // if resurrectable start resurrectionTimer
    if (self.resurrectable) {
        [self startResurrectionTimer];
    }
}

It’s important to note that at the time of this blogging, the CCTimer documentation claims the interval value used to determine the length is in seconds, but really it’s in milliseconds (that is 1/60 of a second). If want your timer’s call back to run in 2 minutes set the CCTimer interval to 160.0f.

It’s also important to note that CCTimer is independent of frame rate: This might be obvious but sometime you want to execute an action every frame an sometime you want to execute it every few milliseconds.

If things aren’t working make sure you’ve told your layer to schedule updates in it’s init method and make sure you are updating your timers from your layer

Immediately I ran into compatibility problems with Google’s Android SDK and the current versions of Eclipse (Helios) and the Java Developer Kit (JDK Version 6). In a nutshell Google’s cool Android dev tools don’t work with Helios–you need to install Eclipse 3.5 (Galileo). Galileo require’s JDK Version 5. All this info is prominently featured on the Android system reqs page–but who reads any more?

Digging up old versions of Eclipse is easy. You can find Galileo here.

Digging up old versions of the JDK is a bureaucratic nightmare. You can find JDK Version 5 here but to install it you have to fill out a form, give away PII, and then wait for an email.

One way around Sun Oracle’s walled garden is to install Open Office 3.2.1 which installs Java 1.6 (JDK Version 6) in such away that everything compiles.

Now that Google is throwing away all their Windows PC’s I’m sure this compatibility nonsense will get even worse. Here is a note from Google about enabling debugging of Android Phones:

If you develop on Mac OS X or Linux, you do not need a special driver to debug your application on an Android-powered device.

Damn it! I might have to go back to coding on the Mac and only using my PC for trival tasks like gaming and web browsing. Ironic huh?

I have to disclose upfront that I am more of an Agile guy than a Scrum guy. Which is to say I feel more at home discussing Agile in general than Scrum in particular. (I’m not even sure how to capitalize it–SCRUM or scrum?)

Over the years I’ve made my peace with Scrum and as I dig into it’s theory and history I find I have few real arguments with the brainchild of Schwaber and Sutherland. My arguments are not with Scrum but with Professional Scrum Masters.

Over past 19 years that Agile/Scrum have reshaped the process of software development many of the traditional roles of software engineering have drastically changed or simply gone away. Technical Writers, Business Analysts, and non-coding Development Managers aren’t needed much by self-organizing teams that talk directly to Product Owners and write up their backlogs on sticky notes. But the one big role that Agile/Scrum has made obsolete is the hard nosed, battle tested, two fisted, lock jawed, steely eyed, organization shaking, cat herding Project Manager.

Back in the day it was the Project Manager who got things done. The good engineers were taught to be sheep and good senior managers were turned into putty by the power of the Project Manager. Microsoft’s variety of Project Manager, the TPM, is still a legend in the industry. It was Windows Vista epic failure and not Agile/Scrum that finally dethroned the TPM.

So when an organization finally buys in to Agile/Scrum where do the people who filled the roles of the waterfall process go? Product Managers became Product Owners. Development Managers who could code became team members or even team leads. Spec writers and Business Analysts moved on. Often Project Manager became Scrum Masters–If the non-coding Dev Managers didn’t beat them to it first.

It is where I got my first bad taste of Scrum: Project Managers turned Scrum Masters who were still doing Project Management. These pseudo-Scrum Masters were the ones with the Microsoft Project plans detailing every sprint from here to release. They demanded status explained in non-technical terms during the daily standup. They stuffed the sprint backlog too tightly (or sandbagged it) and argued with Product Owners over priority. What a mess! It was all Bagile and Fragile.

At least with the non-coding Dev Managers who become Scrum Masters the social graces were respected and they generally stayed out of the way (lest a technical question come their way).

To combat the pseudo-Scrum Master I like to use the role of the Volunteer Scrum Master (VSM). This is just one of the team members (either a coder or a tester) who plays the role of part time Scrum Master. It’s a volunteer and rotating position which can be filled by anybody but the Product Owner. Most of the time the VSM writes code or tests. When the need arises the VSM laces up his boots and does Scrum Master things: Calls for help to scare away any chickens, reminds everyone to follow the process, and let’s me or the full time Scrum Master know that those servers need to be updated by Ops. The VMS removes impediments to the success of the sprint by communication not coercion.

It’s not a glamourous job. There’s no extra pay. There is no authority. You don’t get to wear a uniform or the keys to the executive washroom.

While the job of a VSM is simple and straight forward it can be hard for a new recruit to know where the Scrum Master job starts and ends. So I ask each VSM to think of his part time job as a journalistic one. Observe what is going in the scrum. Take notes. Report findings to the full time Scrum Master or one of the Engineering Directors.

Note: Team members should be responsible for managing themselves. A Scrum Master is not Mom or Dad or a Police Officer. The best way to remove impediments is to communicate them to someone who can address them.

Let’s review how the VCM fits into the role of the Scrum Master…

As you can see the Pro Scrum Master has to be careful. As the Scrum canon defines her job there is some inherent contradiction with the job of Product Owner and even some chicken-like (i.e., management) responsibilities. The VMS has no such ambiguities. He’s just passing through–his sense of self-worth isn’t caught up with the role.

Using VSM enables an organization to limit the number of Pro Scrum Masters, minimize political struggle, and help the team members learn the game of Scrum (the best way to learn is to volunteer).

Here are some sources that help define a Scrum Master’s Role:

• http://en.wikipedia.org/wiki/Scrum_(development)#Roles
• http://www.scrumalliance.org/articles/82-scrum-turtles
• http://www.scrumalliance.org/articles/52-empowering-teams-the-scrummasters-role
• http://scrummethodology.com/the-scrummaster-role/
• http://stackoverflow.com/questions/127807/what-does-a-scrum-master-do-all-day
• http://www.scrum.org/scrumguides/

I love a good fable. The kind that Aesop used to write with animals acting out human morality tales. Of course, if you do the research, you quickly find out that Aesop didn’t write most (if any of the fables) we ascribe to him and like Shakespeare he probably never existed. I don’t let reality like that spoil my appreciation for Aesop’s work.

For Scrum Masters, Project Managers, and fans of Getting Things Done there is nothing like the fable of the Tortoise and the Hare. The slower, but diligent tortoise wins the race over the quicker, but arrogant hare. The only problem Agile process lovers have with this fable is that it’s not true! The tortoise (Waterfall) always loses to the Hare (Agile).

But we have a paradox: Most chickens (managers, stakeholders, investors) and even some pigs (engineers) agree with Aesop! The tortoise always beats the hare because the tortoise makes a plan and executes it well, even if he is a bit slow. (If the tortoise fails it’s because a chicken yells at her to hurry up and so she speeds up and screws up. Call it the “Fable of the Spineless Tortoise and Impatient Chicken.”)

To resolve this paradox I’d like to tell the “Fable of the Tortoise, Hare, and Monkey.”

A Hare one day ridiculed the Microsoft Project plans and change control documents of the Tortoise. The latter, laughing, said: “Though you be swift as Google Go, I will beat you in a race to deliver working software.” The Hare, deeming her assertion to be simply impossible, assented to the proposal; and they agreed that the Fox (VP of Product Management) should choose the requirements, and define the release. On the day appointed for the race they started together. The Tortoise never for a moment stopped, but went on with a slow but steady build cycle straight to the end of the course. The Hare, trusting to his native widgets, cared little about unit testing and user feedback, and lying down under his desk after long night of coding, fell fast asleep. At last waking up, and logging on as fast as he could, he saw the Tortoise had reached the goal, and was demoing to the Fox.

But the story doesn’t end yet…

By the time the Hare caught up with the Tortoise and the Fox he saw the Tortoise slam her laptop shut and slump away. The Hare asked for an explanation. “Why didn’t he Tortoise win?” The Fox explained that what the Tortoise delivered was very late to market and the requirements were were out of date. “But,” the Fox said, “Happily for all, the Monkey has delivered working working software that meets most of our customer’s high priority needs!”

“Monkey? Where the hell did the Monkey come from?” Exclaimed Hare.

“Ah yes,” sighed the Fox, “While you were crashed out under your desk, the Monkey came and delivered a working prototype. I told her that it wasn’t quite right so the Monkey went away and came back a little while later with a revised prototype. It took a few tries but eventually the Monkey got it right and won the race. In fact the Monkey’s working prototypes helped me understand what I was asking for. You see when I gave the requirements to you and the Tortoise, there were a few stories I missed and during the race a new competitor entered the market. Even if you hadn’t fallen asleep you would not have won as I had to keep moving the goal. Our customer, Mr. Zeno, is a hard man to please!

Just in case you’re not into reading between the lines here’s my analysis of this fable (since I wrote it my analysis should hopefully be accurate).

The Hare lost the race because he had to fight the Law of the Handicap of a Head Start. This principle states that pioneers and innovators lack a clear signal. They are out in front, they have no one to follow, and so their advantage becomes a handicap. Often the first movers are stuck building their software on immature technology that becomes obsolete before it is finished. The United States has this problem with its Internet and telecommunications infrastructure. We got there first but now we are lagging in connectivity. The Hare development process, starts out fast and light but never stops to get feedback–its one big long sprint. A lot of code is written. Little of it is ever used.

The Tortoise lost the race because we no longer live in the world of the 4th century BC. Slow and steady hasn’t been a winning strategy for a long time. The goal keeps moving. Actually the ancient Greek philosopher Zeno wrote his own fable where he counters Aesop. In Achilles and the Tortoise, the Hare-like Achilles can’t catch up to the Tortoise (who has been given a head start) because every time Achilles reaches the spot where the Tortoise was, the Tortoise has moved on. This is the problem of accomplishing an infinite number of tasks in a finite amount of time. Somehow we do it every day (but if you really think about it your brain hurts). The Tortoise development process, creates dichotomies every step of the way: Design, Development, Test, Release, Post Release, et etc. Dichotomies are full of infinite regressions and thus are never finished.

The Monkey won the race because he used an Agile development process. First the Monkey took a prioritized subset of from the list of infinite tasks (and every project has a never ending number of bugs and feature requests) and delivered them to the Fox (Product owner) as working software. It was was rough but the Fox had the results in plenty of time to give feedback and course corrections. Thus the Monkey was not subject to the Law of the Handicap of a Head Start. Second the Monkey kept repeating these short sprints of implementing the high priority tasks and getting feedback on a real working system so that as the goal moved she could quickly change course. The Monkey development process, done right, treats every sprint as a whole, where no dichotomies are created. The software is released to the user, it does what it does, feedback is gathered, and the process is repeated until a winner is declared.

It still amazes me how a process created by engineers for engineers can make so many engineers so unhappy.

I’ve seen all kinds of responses to Agile from engineers. Some are immediately enthusiastic. Others are cautiously optimistic. Many are amused and cynical. And some are down right hostile. Over time the responses polarize and the body of engineers undergoing an Agile process split into two camps: Those for whom Agile is working and those for whom it isn’t.

I’d like to point out that I’m not talking about Fragile (Waterfall Agile) or Badgile (just a plain bad Agile implementation). Fragile and Badgile don’t work for anyone, not the Agile fanboys nor the management types that mistakenly create these processes. (If your boss says, “Agile yes, but we must have controls!” then you’re headed down the road to sadness.)

Unfortunately in my experience there are really good engineers out there for whom Agile in all its manifestations, from Scrum to XP, just doesn’t work. I’ve done a fair amount of work to figure out why and what to do about it. I’m going to use Scrum in my examples but this isn’t a problem of flavor. However you enact the principles the problems are the same for this segment of the engineering population. Also note this isn’t a generational thing. Agile-challenged engineers come in all shapes, sizes, sexes, IQs, and ages.

The top four reasons why Agile doesn’t work for some engineers:

1. You have to like to talk to people. Engineering as a profession self-selects for people who find human-machine interactions more interesting then human-human or human-animal interactions. People who like to talk to people become salesmen or lawyers not programmers. But for some engineers human-human interaction is down right painful. If you are not into face-to-face communication Agile is not for you.
2. You have to need and accept help. I love to remind people that intelligence is a side effect of evolution not its goal. (The gold of evolution, if there is one, to enable a species to adapt to a changing environment. Intelligence is just one experiment in adaptation and probably not the most successful one since it’s only worked for one species.) I’ve found that some really intelligent engineers are so smart that it’s difficult for them to accept help (like a prioritized backlog or a bug report) from people they view as obviously less intelligent. You can call this arrogance but then would Mozart have accepted help on his symphonies?
3. You have to embrace change. Many people from all walks of life have difficulty handling change—rapid or slow. They just don’t like the idea that the world they have finally gotten used to and mastered no longer exists. Some of these change-adverse people happen to be engineers. You can spot them easily. They are programming in languages and paradigms that are no longer on the leading edge. I often have to say to them: Yes, you can still write desktop applications but nobody under 40 is going to care.
4. You have to like focusing and working on a schedule. Whether your sprint in two weeks or two months isn’t important. What is important is that you stick to it—even it means, and it usually does, modifying your work to fit the time window. For the Agile-challenged engineer this is a blasphemy akin to chopping eight inches off the left side of the Mona Lisa. They see their software as a whole that isn’t finished until it is finished. Scrum’s timing boxing technique is admittedly arbitrary. The creative process cannot be bounded by deadlines without losing its integrity. At least that’s their argument. I see it differently, and can give lots of contrary arguments, but rational argument has little impact on personal preferences. These engineers find sprinting to be stressful where the Agile-friendly engineer finds sprinting to be liberating.

At the end of the day it’s a waste of time to force people to do something they simply don’t want to do. Unenthusiastic people need to find something they are truly enthusiastic about. There is nothing wrong with the Agile-challenged. They are master craftsmen, they are very smart, they are mavens, and they are artists. So what is an Agile organization to do with them?

The first thing to do is get them out of Agile. These engineers are wasted on Scrum and will simply quit and make a lot of other miserable on their way out. Smart unhappy people can make a lot of mischief!

The second thing to do is to create a lab, give them a mission, and turn them lose. It’s interesting to note that many of famous labs in the history of computation have been notoriously bad at implementing and productizing their creations. Xerox Parc invented most of what we use when we use personal computers yet it is in decline. It’s too bad that Xerox Parc didn’t merge with Apple or Microsoft, organizations that are good at creating markets and feeding them incremental improvements. Instead Apple and Microsoft developed R&D labs of their own so that they have a never-ending fountain of new ideas and home for their dreamers.

You can’t and shouldn’t manage the lab with Agile techniques and you must not staff it with Agile-friendly engineers. The engineers who thrive under Agile get lost in lab, their ideas can’t compete with the Leonardos and Michelangelos.

In the end the secret to managing the de-motivated is finding a place for them in the organization where they are motivated to be. Agile is great but it cannot be applied to all problems.