Noel Rappin Writes Here

There’s been some discussion this week about the TSA’s airport security randomizer app, which you probably remember as being that thing being held by a bored TSA agent that would point an arrow left or right to tell you which security line to go to.

A freedom of information request determined that the app, written by IBM, cost the government about $47,000. This Article suggests the randomizer was part of a $1.4 million dollar contract, and cost $336,000. The Mashable article suggests that $336,000 was for all mobile development, and a TSA rep provided the $47k figure.

This being the internet, there’s been some joking about how an app that could “easily be created by any beginning-level coder” could possibly cost $47,000. Which, if you estimate that it’s only one line of code, comes to roughly $47,000 an hour or more, which certainly seems like a lot. (Weirdly, that same Mashable article says, “In fact, creating a random number generator is a commonly used beginning programming lesson”, which… not in my experience, but the world is wide and I am small.)

All this is fun, but it’s missing a key point: the code is not the only thing of value that a project produces, and it’s not the only thing that costs money on a project. The code is the easy thing to see, the process to get there is less visible. Just because something is simple or small doesn’t mean that process by which it was achieved was simple or small.

While this is a pretty silly project to stand on a hill and defend for its elegance, there’s still going to be a full software development process behind it.

Let’s assume for the moment that the application was actually valuable and filled a need for the TSA. That’s, of course, debatable, but if we don’t start from the idea that the TSA at least thought there was a need here, we’re not going to get anywhere.

There are a lot of potential steps between “hey this is one line of code”, and “hey, we’ve deployed this to airports all around the country”. Some of them may seem like overkill, but it’s overkill at the level of “this is a small part of big project and a large client with odd requirements” — not even a government client, really, just two large organizations working for each other.

I don’t know anything in particular about how this app was built, and for all I know the TSA really did get hosed, but I can easily imagine the following things had to happen:

Requirements: Somebody at TSA had to tell IBM what they wanted, and IBM had to listen. The eventual simplicity of the app may not have been where they started — the TSA could have come in with a more complicated idea that was refined to a simple, cheaper app, but that still would take time. There are all kinds of potential requirements not visible by us — it could be configurable, rather than 50/50, or it could be logging. None of this makes the app super complicated, but they are all decisions that have to be made.

Design: Just because the finished project is simple doesn’t mean it wasn’t designed. Somebody had to design (or at least choose) what arrows were used, presumably for readability. There’s a simple UI, where the agent appears to tap the iPad to trigger a new arrow. It looks from the video like the arrow fades out after a few seconds, they’d want to choose that interval as well.

Security: It’s entirely possible that there are additional TSA security requirements for the randomness, or for the app in general. It’s possible there aren’t as well, but I could imagine the TSA having strict and idiosyncratic requirements here.

Deploy: The TSA presumably isn’t using the App store for security reasons, so deploying this on hundreds or thousands of iPads could actually be non-trivial. The cost might include the hardware, in which case the $47K starts to look like a better deal.

Again, yes, it’s a small, probably even silly, app. But it could easily have legitimately run up $47K in fees, just because that’s how it works when two large organizations work together.

As developers, we often limit our time and cost estimates to just the coding part, and forget that analysis, management, testing, and deployment exist. This is often to our detriment when projects come in over our expectations because we just didn’t take into account critical parts of how projects work.

See also Dennis Forbes making similar points, called to my attention by Avdi Grimm. Dennis adds training and auditing to my list of things that probably needed to happen.