The Quantum vs Newtonian Belief System

1 Comment

In 2004 Doug Decarlo wrote an article I really liked contrasting the different mindsets between the traditional and extreme (Agile) project manager. I think this hits it pretty bang on.

Newtonian – Stability is the norm Quantum – Chaos is the norm
The world is linear and predictable Uncertainty reigns
It is controllable Expect surprises
We can minimize change We should welcome change
Add rigor to the process to increase the feeling of security Relax controls to increase the feeling of security
Deliver on the planned result Deliver to the desired result
Use the plan to drive results Use results to drive the plan
Aim, air, fire Fire, then redirect the bullet
Keep tight control on the process Keep the process loose
Manage to the baseline Manage to what’s possible
Get it right the first time Get it right the last time

Estimation War Story – The Double Whammy


Everyone loves a project that comes in ahead of schedule and under budget. But if you consistently too under budget, people will accuse you of sandbagging your estimates and accuse you of being a little too cautious.

This caught me once. We sized a project using the estimates as a range technique, and convinced management to use the upper numbers.


We then estimated our team velocity and again, used a conservative number around how fast we thought we could go.


Turns out we the project was simpler than we thought, and we ended up going faster than we thought we could go, and came in way ahead of where we thought we were going to be. Great news!

Now, I would way rather be on this side of a project (ahead of schedule and under budget) than the other. But when I look back and wondered why our numbers were so big I realized were conservative in our estimates twice:

  • Once for the estimates.
  • Once for the team velocity.

It’s not the end of the world. This was a really scary project, and our inception deck highlighted a lot of unknowns and first times for the company. There was also some fear and pressure to get things right. But I didn’t quite appreciate at the time that we were sizing conservatively twice here.

I don’t regret sizing it this way. Hindsight is always 20/20.

The more interesting question is now that we are aware of it, what will we do next time.

Happy planning!

Mobile apps are more work than you think


Expectation management is a big part of software delivery. Unless you write software for a living, it’s hard to appreciate how much work goes into the little white box you see on the Google search screen, or the math and physics behind a game like Angry Birds.

Having just finished my first iPhone app, even I was surprise at the amount of work it took to take a few pictures and generate an email to send to a couple of friends.

Building on this post from Kent Nguyen, I thought it would be fun to share some of the behind the scenes magic that makes these simple apps work.


The app itself is pretty simple. It’s called takemystuff (sorry not available in iStore yet) and it basically helps people give stuff away to friends.

Basically, you take pictures of stuff you’d like to give away.

Select the friends you’d like to tell.

And then it builds you an email combining the images and tagged with the friends you selected.

That’s it! Pretty simple eh? Here’s some of the stuff that’s going behind the scenes.

1. Taking pictures

To build a screen that takes pictures and then displays thumbnails in a table

you need to:

  1. Tag images as they are taken (to separate yours from those taken with the regular camera).
  2. Track which ones are selected/unselected, and
  3. Save that information something to be accessed later.

That’s the minium amount of work required to just make it work. Here are some of the wrinkles.

Image capturing is asynchronous

iOS saves images you take with the camera asynchronously. That means when you take a picture, it’s not instantly there for you to display. You have to wait.

Then when the worker thread is done, you are free to refresh the table on the screen.

Not a big deal, but it complicates things because you need to put refreshes in the appropriate places and it’s not always obvious where. It also requires a lot more manual testing (more on than later) and a fair bit of trial and error.

Table cells are pooled and reallocated dynamically

The engineers to Apple have gone through great lengths to make the iPhone fast. One way they do that is to dynamically allocate and reuse cells used for rows in tables.

For example you might have x100 photos ready for display. But when you bind them to a table, a much smaller number gets shown.

That means you need to create data structures outside of the table itself to track which photos are displayed and whether they are selected.

It’s not super hard but it’s non-trivial work.

And if you collect a lot of metadata for each picture you’ll either have to make use of something complex (like CoreData) or track and synchronize these data structures yourself (through things like Arrays and Dictionaries).

Locations services

Location services are what the iPhone uses to tell apps where they are. Foursquare, Weather, and Maps are obvious services that could use this kind information.

But cameras can use this information too. And while I didn’t require location services but your app might.

That means you need to check at runtime whether the service is turned on, and inform your users of what they should do if it isn’t.

Now let’s take a look at some of the things you need to deal with when compiling a list of friends.

2. Selecting friends

Selecting and adding friends on a simple table like this is a bit of work. You need to:

  • Pop open the address book and detect which friend was selected
  • Extract the friend data and handle all the edge cases of there not being a first or last name, or even an email address
  • Add logic to make sure choosing a friend on screen is synchronized with friends chosen in your data structure
  • Add logic to delete (right swipe) or remove a friend from your list (and again synchronize that with your data source)
  • Handle all the refreshes from your data structure changing to that on the screen

Then you need to popup and hide the appropriate alerts and error messages if your users have data you either didn’t expect or can’t handle.

Again, a fair bit of work for what looks like a dead simple screen.

Now let’s take a look at what it takes to bring it all together in an email.

3. Building the email

Here we grab the photos selected by the user from the first screen and combine them with the email addresses selected from the second. Here’s how that works:

  • First you need to walk the assets library and extract all the photos you tagged with your application (more asynchronous programming).
  • Then you need to grab and parse the email address of the friends.
  • Then you need to combine those and create the email.
  • If they choose not to send the email, you need to handle the ‘Cancel’ button being pressed and make sure you transition them back to their previous views (which you also need to track.

And then you need to handle the cases of where they didn’t select any photos or they didn’t select any friends.

Other stuff that needs to be done

Art work

This application doesn’t have a lot of of art but I still needed to create some icons for the tab bar and one for the application itself.

Deploying to the app store

This was (still is) probably the most painful part of the iOS development process. Trying to get your work on other peoples devices.

I won’t go into all the details but you need to jump through a lot of hoops just to test your app on another device.

  • You need to get their device ids.
  • You need to create certificates.
  • You need to create deployment profiles
  • You need to copy/email files around with complex instructions for how you testers are supposed to load you app.
  • And then after doing all that it still doesn’t work with little or no feedback as to why

It’s a tough, frustrating process it’s no wonder startups are forming just to help you deploy your iOS application.

If that’s not a wake up call to Apple that their deployment process is overly complicated I don’t know what is.

A lot more manual testing

With so much application code directed to the UI, mobile apps require a lot more manual labor intensive testing.

Yes there are frameworks and tools that can help but I have yet to see anyone favor these over repeatedly clicking through your app and making sure everything works.

And while you can unit test, it doesn’t deliver the payback we’ve grown accustomed to on server side frameworks like Rails and Java/.NET.

And we aren’t even doing anything complicated!

If the makers of Path and PlantsVsZombies were reading this they’d laugh. Complicated! You ain’t seen nothing yet! And they’d right.

This app doesn’t do any:

  • custom graphics
  • sound and audio
  • custom UI
  • push notification
  • in app purchases

All areas of hairiness and complexity and hairiness. Not to mention that there’s no backend to this app. It’s all local to the phone (which simplifies things greatly but limits what the app can do).

In summary

Writing great software isn’t cheap or easy. It takes a lot of hard work, dedication, and persistence.

And everything I’ve said here about mobile apps applies equally (though in different ways) to enterprise apps and backend systems (just imagine the complexity Google or the guys at DropBox regularly handle).

So the next time someone tells you that building that screen shouldn’t take more than a couple hours, smile, be patient, and understand where they are coming from. To our users much of what we do is magic. It looks easy and they expect it to work.

Explain to them some of the challenges. Be upfront and honest about the cost. And know that you are not alone. Managing expectations is a big part of being a software professional and setting expectations on software projects ain’t easy (though I know a book that can help).

Happy coding.

The way of the Spartan Warrior


There’s more to successful projects than time and money, but if you ask the people with the money, they’ll tell you that time matters a lot.

In this post I am going to show you one sure-fire way to quickly figure out how realistic your budget and schedule are and how to reset expectations like a pro when you need to.

How much can you afford

One of the great strengths of agile development is the leeway you get in building any given feature or story.

You can build it cheap. You can give your customer something with just a few bells and whistles. Or you can build them the Taj Mahal if they want that.

This looseness around high-level stories gives customers a lot of flexibility when making decisions about features. They can go light on user interface spit and polish if they are building a back-office invoicing system. Or they can invest heavily in look and feel for the tablet application insurance adjusters are going to be taking with them to into the field.

The challenge for you (and your customer) is to get a sense of how much they can afford right at the start. We’d all like the deluxe version of whatever it is we are building, but not at the expense of the budget or the schedule. As Steve Jobs likes to remind us, “Artists ship.”

To help our customers figure out this balance, we need a way of quickly confirming that we

  • have enough time and money to build the system they want, and
  • have a sense of how much they can afford in terms of bells and whistles that would improve the product and experience.

One way to get there is to start Spartan.

The Way of the Spartan Warrior

The Spartan Way is built around one really simple, common-sense premise: If we can’t build the Ford Focus version of the system with the time and money we’ve got, there’s no way we can afford the BMW.

So the way we figure out what we can afford is to build a few bare-bones core features, measure how long that takes, and then take a fresh look at the plan and see how realistic things are looking.

Once you can see clearly that the current plan doesn’t support the scope of what’s on your plate, having this conversation with your customer is much easier.

Yes, we’d like to build the world’s greatest automated invoicing system, too. It’s just that we can’t get the bare functionality in place (much less any of these other whizbang features you’re asking for) with this schedule and timeline—we’ve tried!

No wishful thinking. No guessing. The truth is self-evident.

This is really the crux of agile planning. We don’t know when we are going to be done until we build something of value, measure how long that takes, and then update our plans accordingly. I realize that some people (i.e., executives) don’t like hearing this, but this is the reality of software delivery. All we are doing here is eliminating as much schedule risk as we can up front, giving them a heads-up early on about how things are looking.

What to do if the plan is wrong

If the the plan is wrong, we have two options for bringing reality back into the fold:

  1. We can reduce scope (recommended).
  2. Or we can flex on the date.

Reducing scope is how agile developers prefer to keep their commitments and avoid the pain that comes from asking for more time and money.

There is always going to be more to do than the time and money allow (that’s just the reality of any interesting project). And if we keep adding features we’ll never ship anything.

So when given the choice we’d rather fix our dates and flex on scope.

If, however, there is a core set of bare-bone features that just have to be delivered as a whole, we can commit to delivering that core set of features. We just have to be a little flexible on the date.

Even in this scenario we will still need to flex on scope a bit (because new things are always going to come up). But we can go in with the understanding that these high-level core features need to be there and that we are going to ship as soon as these are done.

Pushing out the date a little is OK, but it’s not a good habit to get into. For one thing, it’s just too easy. Secondly, it puts your project in danger of delivering no value. Until you get it into production you haven’t an ounce of value, and agile hates that.


So if you suspect that your project has some scheduling challenges, try building a few spartan core features, see how long that takes, and update your plan to reflect that reality. If things are going well, swell. Keep on truckin’.

Otherwise, work with your customer to set them up for success by either reducing scope or suggesting they be prepared to wiggle a bit on dates.

Doing this early will enable you to have this conversation with conviction in an open and honest way. And your customer will appreciate knowing the facts at the start of the project instead of near the end.

%d bloggers like this: