Software may eat the world, but it won't digest it unless we change

by | May 13, 2016

Spicy Crabs - Sichuan House AUD39.80
Good luck writing software to consume this! Source: flickr/avlxyz (CC BY-SA 2.0)
In a now-famous article published in 2011, Marc Andreessen argued that software is eating the world, because Amazon destroyed Borders, etc. He warned that the market was undervaluing tech companies, and we should all get ready for disruption! Good to see the other side of the business cycle five years later, after the bubble he said wasn’t forming has started to deflate. Launching the 14th-best haircut-booking app will no longer get you millions in VC funding and a pleasant, early retirement after acquisition by your similarly over-valued 13th-best competitor.
The core of Andreessen’s argument, however, was both seductive and probably right. The next great tech companies won’t simply move an existing business model to the internet (online bookstore!) but use software to build new business models that deliver a service in a way that is easier to sell (renting anonymous computers!)
Today I was reminded of the incredible (over-)optimisim of Andreessen’s slogan by an unlikely source: an article by Charles Fishman from 20 years ago, called “They Write the Right Stuff”. If you’ve read this far, the best use of your next 15 minutes is to read it. My take follows.

Quality is a choice

The article is a case study of the “on-board shuttle group” at Lockheed Martin, 260 people who wrote the software for NASA’s Space Shuttle. Reading through, it feels like Fishman has discovered the greatest software team in human history. The shocking thing is, I think he is still right. Who can say today they deliver quality to this level? And no, “shipping to learn” doesn’t count: updating your website costs a little less than launching a shuttle.
Sure, that team started off with some advantages: plenty of budget, a specific and demanding client, clear success criteria. These are necessary conditions for writing good software, but not sufficient. We all know a project that had those advantages but turned out an abject failure. What distinguished this team was their process, which shunned the tech perks of the time, avoided overtime, planned meticulously and tested rigorously.
That doesn’t sound very sexy, and that was the exact point! When you write software to do a job, you have to know it does the job before you run it. If you write software mostly to get that next round of VC funding, is it surprising that garbage is the result?
What struck me the most is that the team’s process refused to let the customer force them to write bad software. The customer had to know what it wanted to achieve before any code was written (I agree!). Fishman writes the following like he’s making a prophecy, but I don’t think it has come true:

That’s the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego-trip — but it is the future of software. When you’re ready to take the next step — when you have to write perfect software instead of software that’s just good enough — then it’s time to grow up.

Posts with lists do better #amirite?

Apart from the delight of discovering that such a team once existed, I have a few less-developed thoughts:

  1. For all the benefits that agile, continuous integration/deployment and product-/design-/customer-led thinking have brought, they don’t say enough about quality. And this team predates them all, so perhaps the choice over quality is somewhat independent of whatever is the latest buzzword for “managing the doing of the work”.
  2. As I tweeted upon reading the article, an implication of this 1996 article is that tech’s diversity problem stems from privileging bravado over quality. Remember that women used to outnumber men in programming, until men fought back and made it a “geeky” discipline that required “qualities” in which men specialise. Recently, a study committed anonymous code written by women and men to Github and guess whose code was rated better, on average? That is, until the gender of the coder was revealed…
  3. All this is just about software engineering, don’t even get me started on how far behind we are in the world of data! Yes, data work can be tougher for valid reasons, but if we care about quality (and we should if we want to inform better decisions) it is time for all of us to grow up. Software eats the world but data people must digest it, and we are nowhere near good enough.

That’s all for now, make sure to read Fishman’s article and tell me your reaction.
Side note: at OptimalBI we are tackling the thorny question of quality, and how to build quality-centric data teams. We don’t have all the answers, but we can train you to build a better process.
Until next time, keep asking better questions
Shaun – @shaunmcgirr
Shaun blogs about analytics, machine learning and how data solves problems in the real world. 
You can read all of Shaun’s blogs here.
Don’t forget, we can train your team in the art of agile business intelligence at any time! 

0 Comments
Submit a Comment

Your email address will not be published. Required fields are marked *