Five Sure-Fire Ways to Sabotage a Release

In March of 2012, I gave a talk at NSConference 4 and lifted my kilt and invited attendees to learn how not to go about shipping a software product. Luckily for them I was wearing pants and what I lifted was a virtual kilt, but it was still a disturbing presentation.

I may or may not have made them stare at “Baby Hoctor”1 for an extreme amount of time.

BabyHoctorFramed

My goal in airing my dirty laundry was to prevent other developers and entrepreneurs from making the same mistakes that I made. In case you missed NSConference and haven’t seen the videos2, here is a synopsis of that talk.

#1 Announce Features Early

Back in 2008, our customers were comparing MoneyWell to Quicken and asking for investment support. Not wanting to disappoint anyone, I innocently said, “Sorry, investments won’t be supported until 2.0.”

Boom. I talked about a product release that I hadn’t even started planning and I didn’t stop there. I talked about dozens of future features and didn’t even say they’d have to wait for a major release. At the time, it seemed innocent enough. Customers were asking questions and I was answering them to the best of my ability. I truly believed that I was shipping a 2.0 release in the next six to eight months, so why not tell them that they’d have to wait?

The problem with talking about functionality not in the current release sets expectations and distracts from marketing what’s already wonderful about what you’re selling. All you’re doing is diminishing the product you’re selling. You are also making a promise to your customers that you may need to break down the road if priorities change (or Apple implements new OS features that force your hand).

#2 Cannibalize Features for Free Releases

Being a people pleaser, I fell victim to the trap of feeling guilty for not giving my customers more features. No one was yelling that MoneyWell was horrible, but in my head I had a vision for the functionality that I wanted in the 1.0 release. This vision caused me to steal features that should have been in a paid upgrade and release them in dot releases, which were free.

MoneyWell 1.4 could have easily been a 2.0 release. 1.5 could have been a 3.0 release. Let’s not even talk about 1.6 and 1.7—all free releases. I should have stopped at 1.1 (what 1.0 should have been), rolled my 1.2 through 1.4 features into a 2.0 release, and charged for it. That income could have been used to hire a designer and improve the quality of new releases. It would have been a win-win for my customers; instead I hijacked my marketing budget and stretched cash flow thinner than necessary.

By allowing my misplaced perception of value to get in the way of the business side of development, I cheated my customers out of better software. What I thought was generosity was instead a tradeoff of short-term features for long-term benefits.

#3 Rewrite All the Code

After four years of shipping free updates, work finally began on MoneyWell 2.0. The year before, I had hired Michael Fey to help me develop MoneyWell for iPhone and I added Danny Greg to our team to accelerate the work on our new release. Both these guys are sharp developers who were knowledgeable in the latest Objective-C and Cocoa techniques and ready to fix all the “old guy” code. I was embarrassed by some of my ancient code—written in my early days of Cocoa development—and quickly gave the nod to replace some of that code.

My lack of focus on code reviews and my desire to create the best MoneyWell possible made me vulnerable to rewrite suggestions, and some of the “old guy code” was actually pretty good. There were also external forces at play. At WWDC, Apple announced OS X Lion and I decided that we could remove a ton of custom code by ditching support for 10.6. This wasn’t a bad decision, but it was painful to discard nearly six months of work. If I had planned a more focused 2.0 release, we could have shipped 2.0 before WWDC11 and avoided much of that pain.

#4 Do Documentation Last

Because my project plan for MoneyWell 2.0 lacked focus and included so many features, this release was running months late. By February 2012, I felt pressured to ship it quickly even though there were bugs and incomplete features. But the most embarrassing mistake was the total lack of documentation. I had no 2.0 manual, no videos, no online help—nothing. I relied on a short in-app guide to train new customers and assumed our simplified interface would be easy for existing customers to adapt to the changes.

It was a huge mistake. New customers were confused, existing customers were pissed, and I was depressed. Because I had spent months of development time using 2.0, my understanding of how much had changed was skewed—MoneyWell 2.0 was old hat for me. There was so much to be proud of in our new release, but no one knew about those features. All people knew was that lots of things had changed and some features were missing.

A bigger issue with waiting until the end to write documentation was the loss of customer perspective. If I had to explain features with documentation as I was writing them, I would have seen several flaws in my design logic. There were components of the new spending plan that I would have scrapped if I had tried to explain them to a non-technical audience. I was seeing my app completely from a developer viewpoint. What a disaster—I had let everyone down.

#5 Extend “Crunch Time” for Months

This project was full of blind spots for me. I wanted my old code cleaned up, which caused me to give thumbs up to unnecessary rewrites. Features that seemed “almost done” were weeks away from completion. The project changed directions a couple of times with changing the OS target and feature creep. I started the development crunch time before WWDC and we didn’t ship for eight months. It’s okay to push a team for eight days or even eight weeks, but eight months is insane. Completely. Insane.

The Right Way

So what’s the right way to run a software company?

  1. Keep your mouth shut. Don’t talk about features until you are ready to ship. Save them for a teaser video and use “leaks” for marketing.
  2. Don’t give away software. You deserve to get paid. Customers deserve to have you around to support them for years. Hang on to features for major paid releases and give you and your customers a great future.
  3. Never rewrite functional code. If it works, don’t touch it. If it works, don’t touch it. FOR THE LOVE OF PETE, DON’T TOUCH IT!
  4. Build software and documentation together. If you don’t have time to write documentation, you have too many features. Writing how software should be used while writing the code will make your code better. Make time for it.
  5. Minimize crunch time. You and your team have limited energy. Long days are fine at the end of the development cycle, but not for months. Cut features if you need to ship faster. Don’t kill yourself or your team.

I made way too many mistakes for a guy that has been doing this for over three decades. Learn from my errors and ship awesome software. I’m trying to do the same.

Peace.

  1. Blame Phil Letourneau
  2. I highly recommend buying the videos