What the Global Development Industry Needs to Learn from Software Development

As a tech startup, we’ve embraced our ability to fail. But as a startup in the global development industry, we’ve learned that many of our partners are scared of it.

After more research which showed us that startups fail faster and more than any other industry, we found that there is an interesting correlation between the rate that individual tech startups fail and the amazing speed of innovation in the entire industry. This is almost opposite to the global development industry which sees a much lower rate of admitted failure, but also a much slower pace of innovation.

So what fuels innovation amongst technology startups?

Learning.

In fact, according to Eric Reiss, author of the Lean Startup, it’s “Validated Learning”. And it’s learning that typically happens through failure.

Here are 4 lessons that the global development industry can learn from tech startups and software developers

1. Plan for Failure

The most powerful force of innovation amongst technology startups is that they know they’re going to fail, and they’re OK with it.

Launching a new enterprise—whether it’s a tech start-up, a small business, or an initiative within a large corporation—has always been a hit-or-miss proposition. According to the decades-old formula, you write a business plan, pitch it to investors, assemble a team, introduce a product, and start selling as hard as you can. And somewhere in this sequence of events, you’ll probably suffer a fatal setback. The odds are not with you: As new research by Harvard Business School’s Shikhar Ghosh shows, 75% of all start-ups fail.

– Steve Blank in his article Why The Lean Startup Changes Everything

Since startups know that their technology and core business model is going to change, they must plan for it to change. This change, called a “pivot”, is now common language amongst startups.

And pivots don’t just affect the business, they affect technology, too.

Even the best software engineer knows that his or her code will change. The trick for software engineers is not to write flawless code, but to plan for flaws. Planning for failure lets entrepreneurs and developers catch their mistakes early on, and as importantly, enables them to capture feedback to optimize their business and growth.

Granted, it’s much easier for a small startup to pivot than a globally-dispersed development organization, largely because their investors are familiar and accepting of it. But this is in large part because failure is shared openly and discussed, even before it happens.

LESSON 1:
Let donors and partners know that because failure is likely, your organization is going to be prepared to discover it before it happens, and be better off for it.

2. Test (and design) for Failure

At a cutting-edge technology event in Seattle, Ryan Roemer, Director of Engineering at Curiosity Media started his keynote presentation by sharing that:

The key to developing with Node.js (an emerging technology framework) is knowing that things will break. With this in mind, the trick is to design a technology infrastructure that can detect, react to, and isolate failures in a manner that keeps the overall system or service up and running.

Software developers are unique in that they are so accustomed to failure that they create tests to catch failure early. Any self-respecting developer will always deliver their application complete with tests running non-stop in the background to ensure that it works. A common best practice is to write tests before the ultimate application is finished so that an engineer can identify and confirm that the desired behavior of the finished product is achieved once developed.

The first thing you ask is not “What code will I write?” The first thing you ask is “How will I know that I’ve solved the problem?”

– Jeff Atwood in his article I Pity the Fool Who Doesn’t Write Unit Tests

LESSON 2:
Define success factors and failure points, and create tests to ensure that you identify when success happens, and catch failure before it gets out of hand.

3. Fail Fast (and rebuild… again… and again… and again…)

Find me a software developer that has never started over, and I’ll show you a liar.

At a recent interview with Derek Slager, the VP of Engineering at Appature (one of Seattle’s leading startups), Derek shared that

We’ve thrown away a lot of the code we wrote years ago… and we know we’ll throw away a lot of the code we’re writing now.

This is because tech startups must produce a minimum viable product – containing only critical features – as quickly as possible, and then get it in front of customers for feedback. They must then start over, rebuild, or further augment the product depending on feedback. Ultimately, if the customer does not find value in the product, it must be made more valuable. According to Steve Blank in the HBR article Why the Lean Startup Changes Everything:

[Startups] that succeed go quickly from failure to failure, all the while adapting, iterating on, and improving their initial ideas as they continually learn from customers.

LESSON 3:
Ship your program early and obsess over constituent feedback to ensure you are adding value. If you’re not, keep going.

4. Share your Failure (and success)

But mostly your failure.

In his book, Four Steps to the Epiphany, Steve Blank shares stories of startup failures in order to help other tech entrepreneurs not make the same mistakes. His teachings have started the Lean Startup Movement. And, according to Steve:

In 2011 the U.S. National Science Foundation began using lean [startup] methods to commercialize basic science research in a program called the Innovation Corps. Eleven universities now teach the methods to hundreds of teams of senior research scientists across the United States. Beyond prominent authors, developers are consistently sharing information on a daily basis.

Take a look at the open source projects in the software development industry and you’ll see a myriad of sites providing their code (essentially their intellectual property) open to others to use freely, albeit with some legalese around “permissive and business-friendly licenses”. Sites like GitHub and Google’s Open Source Project make some of the most valuable code in the world available to the public, for free. And developers don’t just share code, they also share their successes and failures. Tech forums, like StackOverflow, are a great sample of this where contributors can share challenges and successes and receive free support from each other to overcome any challenge.

If no other lesson from software developers is embraced by the global development industry, I hope that this point about sharing failure is. According to Sam Loewenberg in his New York Times Article Learning From Failure

Americans love success stories… But “success stories” are rarely the whole story. Global health and development projects frequently go off course, and it’s not unusual for them to fail outright. What is unusual is for researchers to openly discuss their failures. That’s a shame, because it’s a basic principle of science that you get things right by analyzing what went wrong.

LESSON 4:
Share your failures. Use sites like Admitting Failure and Fail Forward to help your organization understand how to deal with favor, and how to share it with partners and donors so that we can all get better, together.

The value of failure isn’t only recognized in the software development communities. It turns out that failure is also an integral part of sports – Michael Jordan attributes it to his unparalleled success.

Schools, corporations, and healthcare institutions are becoming more transparent about their failures, too, as described in Charlene’s HBR article, The Art of Admitting Failure

Dealing with failure is part of being a leader. Rather than expend enormous energy to avoid it, you should build an organization that is resilient in the face of inevitable failures.

Maybe this article can get boiled into one simple statement from my mentor:

A stupid man learns from his own mistakes… a wise man learns from the mistakes of others.

So let’s be wiser, together. Start by making a commitment to plan, test, do, and share failures. And if you need more rationale and/or creative ideas to share failure beyond AdmittingFailure.com, then check out this HBR article titled Go Ahead and Take a Failure Bow:

People won’t try out new ideas or approaches if failure is seen as a career-killer [unless] it’s treated like what it is — an opportunity to learn.