Lots of people are commenting on the Gun.io blog post The Government’s $200,000 Useless Android Application. Android developer Rich Jones stumbled across an application provided by the Occupational Safety and Health Administration (an agency of the US government). In the end, he discovers that the government paid $96,000 to have a contractor build this buggy application that would take him around 6 hours to write. You really should read the whole thing — the steps he went through to get the details of the contract are interesting.
The obvious response to this is to point out the pervasiveness of government waste, but everybody already knows that the government wastes a lot of money. In fact, pretty much any institution that has lots of money and lots of bureaucracy wastes a lot of money. For example, here’s a recent Tweet from Horace Dediu:
HP spent $1.2 billion to buy Palm, earned $600 million in losses and $1.5 billion to shut it down.
When I look at the OSHA app, what I wonder about is what kind of process led to something so bad being built and released. Who thought it was a good idea to spend $96,000 to build something so simple? What did the actual project entail?
I’ve seen seemingly simple tasks mushroom into huge projects in large organizations. Last year at work we were talking to a customer about integrating with our Web service. I can write the code to integrate with every feature we provide in a day or two — their internal estimate for the entire project was 1,000 to 2,000 hours, mainly because the customer bundled a lot of needed internal changes into the project. They did take on the project, and I have no idea how long it took them in the end.
I figured that this was a case where honest people made their best effort to produce something good, and wound up with a subpar result. In the end, though, I wasn’t so sure. The original blog post mentioned that the application was buggy, and I wanted to figure out how you could pay $96,000 for a simple, buggy application.
You can download the source to the application on the OSHA Web site. The Android version of the application contains 2134 lines of Java code, plus various layout elements. Unsurprisingly, there are no tests at all in the packaged source. There’s no documentation, either.
Just for fun, I decided to try to track down the bug mentioned in the Gun.io post — the application showed the current temperature in Boston as 140 degrees.
The application retrieves weather data from a NOAA Web service and then parses it using a SAX content handler that they wrote. Unfortunately, the code that constructs the URL for the Web service has been removed, probably because there’s no authentication. Lacking any example data, I looked at the code that processes the data instead.
The first thing that stood out to me was that the variable name of the SAX content handler is myExampleHandler. A quick Google search revealed that they just copied that part of the code from this blog post and didn’t bother to change the variable names or the comments. That’s a pretty clear indicator that the code was not written by a professional who cares about their work.
The content handler itself is really badly written. For example, the developer sets a bunch of boolean variables to keep track of which elements they’re processing, but then never actually uses them. Instead they use a completely other group of integer variables that they use as booleans. Why did they create two sets of variables for roughly the same purpose? I have no idea, but it could be because multiple people worked on it and didn’t even bother to try to figure out what was going on before they started adding code.
In the end, I wasn’t able to find the bug. My original guess was that the service returned the temperature in Fahrenheit and the developer converted it from Celsius to Fahrenheit mistakenly, but that’s not the case. Now I think it’s presenting the Heat Index and labeling it as the temperature, but I don’t understand how Android layouts work so I’m not sure that’s it either.
In any case, the application was probably not built by an experienced Java developer. They didn’t follow any normal conventions with regard to naming methods or variables. When you do not camel-case the names of your accessor methods, you’re clearly not used to reading other people’s Java code. Furthermore, there are plenty of other signs that the application was written without a lot of care. The code isn’t even properly indented, and it looks as though the developer is not very comfortable with data structures.
For example, temperature and humidity values are extracted from the XML returned by the Web service and stored as Vectors of strings in a data transfer object. When the developer goes to use them, they construct new arrays and copy all of the values in the Vectors into plain old arrays, converting them to numeric values at that time. Why not parse the numbers at extraction time? I have no idea. Why not store the corresponding humidity and temperature values in a data structure rather than just keeping them in two separate indexed data structures? I have no idea. But these sorts of rookie mistakes are a good indication that the developer who wrote this was in far over their head.
My guess is that OSHA hired Eastern Research Group to build this application because they were already on an approved contractor list and the business development person from ERG told them that they were capable of doing it. The application was then built in-house at ERG by a developer who had no clue what they were doing, probably under a tight deadline, or it was outsourced to some other firm that was fleecing ERG the same way they were fleecing OSHA. Clearly there was nobody on the OSHA side who was capable of doing even the rudimentary inspection of what was delivered that it took me 30 minutes or so to perform.
I have worked as a consultant before and I see this a lot. People who outsource software development simply lack the expertise to assess the applications that are built for them. They don’t know how much they should cost, what to look for in a vendor, or how to evaluate what’s delivered to them to make sure they got their money’s worth.
I went into this thinking that maybe everybody involved was honest and the bad result was due to flaws in the process, but now I think it’s pretty clear that ERG sold the OSHA a false bill of goods and wound up fleecing them pretty badly. I hope it’s not too late to get their money back.
The image embedded in this blog post is from the source for the application — it represents heat stroke. Maybe some of the money was spent on illustrations.
November 28, 2011 at 3:33 am
My digital logic app was written before I added the built-in scrolling feature to my graphics library. With this feature, you never need to make your own scrolling because when you draw lines circles, ect, those rountines have grab scrolling by holding CTRL and moving mouse. You never need zoom, either because there is CTRL-ALT-Z. There’s even a system level draw-grid feature.
I started from behind doing my graphics library without GPU acceleration, so I thought, “My only hope is to do awesome features today’s GPU libraries don’t have.” I built-in a symmetry-draw feature which will cause low level routines to show symmetric drawing. I built-in system level scrolling into the graphics library — my only hope is to provide features today’s GPU libraries don’t have. I have graphics in source code, supported by my compiler and editor!
November 28, 2011 at 6:32 am
This is exactly the information asymmetry that The Market For Lemons famously pointed out. When the buyer knows much less about the product (or service, in this case) than the seller, the inevitable result is a cycle in which the bad crowds out the good.
November 28, 2011 at 10:41 am
I had a similar take in the comments (http://gun.io/blog/the-governments-200000-useless-android-application/#comment-370763574) as well: there’s a bunch of sadly familiar observations to be made about out sourcing, large organization dynamics, etc. but the underlying problem is that most large organizations don’t review cost-effectiveness and it’s frequently the case that the “safe” option is more expensive.
The meta issue which needs more awareness is how often measures designed to address excessive cost and abuse often cost more than they save – for purchasing I’ve long believed that it would be better to set a high threshold (500+K?) before you require the heavy-weight procurement process and then randomly audit some percentage of purchases.
November 28, 2011 at 2:27 pm
This reminds me of the article about the space shuttle program: http://www.idlewords.com/2005/08/a_rocket_to_nowhere.htm