Code Benders

Avoiding Startup Death

Posted by Taus April 18, 2012

For about 15 years, I have had the pleasure of working with startup entrepreneurs in a number of technology sectors and in various capacities. I’m amazed at how much the startup landscape has changed and, more importantly, how the processes that are used by tech founders to manage risk and hone their ideas have shifted. In particular, the combination of Agile Development and Customer Development has helped transform the nature of a startup from a mini-enterprise (emulating large corporations) into a very different beast – one that is designed to embrace iterative learning at an extremely rapid rate and with far less risk than the startups of 10 years ago.

Today it is possible, if not likely, that a smart startup can do vastly more with a fraction of the capital and time than it’s predecessors could just a decade ago. For those deep in the tech community, much of this is well-known. But I’ve found that many entrepreneurs, go into the process missing some critical information. If you’ve worked in the trenches of a startup that embraced agile and customer development, then this article will offer you little insight. But, if you don’t have any scars to show from previous startups (in particular a few failures) or your role within those startups was not on the product development side, then you might find what follows useful.

To be clear, I’m not writing about the idea oriented mistakes that Ben Parr wrote about last year or the business decision mistakes that Paul Graham wrote about several years ago. I’m interested in the processes that founders adopt and how those processes influence success. Why? My fundamental assumption is that time and capital have been shrinking in relative importance and, therefore, the likelihood of pursuing a good idea at the same time as another startup or a large multi-product business, like Google or Facebook, is higher than ever.

The processes that I’m describing below can kill your startup, and avoiding them will help your startup gain an unfair advantage against your peers. So, here’s my list of process mistakes that can kill your startup (not necessarily in order of priority):

• Ignoring Customers – It’s been said before, but I’m surprised at how many experienced and credible founders ignore their (prospective) customers. I’ve yet to meet a founder whose first vision of their product was correct. Yet, so many pursue their vision, often to “protect the idea” from competitors. Taken to its logical (yet, too common) extreme, many founders are unwilling to talk about their idea with customers at the earliest stages. Maintaining the confidentiality of your idea is worthwhile to some degree and overwhelmingly in cases where there is real intellectual property in play. But for most startups, confidentiality is the enemy of progress. Progress comes from discovering the nexus between your vision and real customers, i.e., finding and interviewing users of your product. To be clear, I’m not talking about discussing the idea with a few friends and peers. I’m talking about discussing the idea with total strangers who have no vested stake in the outcome, but who can strongly identify with the need your idea intends to solve. To avoid ignoring customers, founders must thoroughly embrace customer interaction as a core process and also learn to say ‘no’ to non-customers like that investor that is funding your company. To learn more about why and how to do this well, read Steve Blank’s Startup Owner’s Manual and the Ten Principles for Lean UX.
• Feature Bloat – Ok, feature bloat sounds like a decision, not a process. But there is a subtlety worth pointing out here and in some ways it’s connected to Ignoring Customers. The first company that I co-founded had an evolutionary idea: inverting the search and matchmaking process of multifamily housing. Stealing a page out of eBay’s playbook, we set off to enable renters to list their need (e.g., a 2 bedroom, 2 bath in Portland) and encouraged apartment managers to provide them a “bid”. The idea, was simple, elegant and focused. But in our early days, the management team, which came out of the multifamily sector and knew it well, was convinced that we needed “more”. They were certain that we would need something extra to attract renters (a rental reward program) and the apartment managers (rent insurance). The three “features” together seemed very powerful, so much so that it was dubbed the “3 legs of the stool”. Without one, it was thought, the primary product idea would fail. We were wrong.  Although we spent a lot of time chasing down the second legs of the stools, it turned out that we were wasting our time and money. The lesson learned is that had we listened to closely to our customers, instead of telling them how awesome the combined idea was, we might have saved a significant amount of time and money and been able to dedicate those resources to the real challenge of changing behavior.
• Long Term Planning – Yes, I’m willing to say it. Long term planning can kill your startup. No, I’m not suggesting that you shouldn’t have a long term plan. But I am suggesting that it is a mistake to assume that you can stick to the plan or that anything similar to the plan will actually manifest. As Eisenhower said “Plans are nothing; planning is everything.” So plan, but just enough so that you can measure your direction and then track to the plan – expect your plan to change regularly. Keep in mind that your #1 priority as a startup is to discover and then validate the fit between your product idea and your customers real need. This is a highly iterative process, which will dramatically affect the underlying assumptions in your business planning. To ensure that your not slowing the discovery process, your business plan should not become a high priority until after you’ve found a strong nexus between your idea and your customer’s need. More importantly, encourage a culture that invites change, is skilled at adapting and understands that it is a key advantage. The originators of the Agile Manifesto said it best: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” And while I’m on the topic, read all the principles of the Agile Manifesto.
• Early Architecting (aka Premature Optimization) – software engineering in startups is different from every other form of engineering. When you build a bridge, you know where it starts, where it ends and what the requirements arebut in between. With software startups, you start with an idea and almost nothing else. The primary purpose of your startup (as most eloquently described by Eric Reis) is to learn everything else that you need to succeed. So, don’t spend any time thinking about how to master plan your “platform”, just start building your highest priority features (to meet the needs your customer has articulated) and then put those features in front of your customers. If you’re lucky and your idea was perfectly conceived from the beginning, then you’ll have the opportunity to optimize your service to relieve bottlenecks or further improve usability and features.
• Go Fast, Go Big – I sometimes encounter founders who believe that in order to “win” they need to go fast and big. Usually, that means hiring a sizable team and working them to the bone for the foreseeable future. In my experience, this delusional thinking leads to burnout – fast and big! Arguably, going fast has some merit – but only relative to the certainty that you have in your product-customer fit and your ability measure and prove how your changes affect your customer. That is, if you don’t have real metrics to identify the results of your development effort, than you will likely be moving fast in the wrong direction. As to going big, there are drawbacks all around ranging from losing your company’s culture to excessive capital burn. For more on the topic, read Rework from the guys at 37signals.
• Segmenting Your Team – Traditional businesses thrive because they are able to segment the various processes that make up the business, including design, development, marketing, operations, etc. Big company CEOs are so rarely engaged in real customer development that the exceptions become legend as in the case of Toyota CEO Yuji Yokoya.  Startups die for the same reason. When your #1 priority is to learn from your customer and discover the product that meets their needs, the only way to achieve this goal is to have everyone on your team actively participating in the discovery and development process. That includes designers, developers, product managers, marketing… everyone! As Jonathan Rasmusson wrote in the Agile Samurai, “On a typical agile project there are no predefined roles…. Quality is a team responsibility on an agile project. There is no QA department – you’re it….” The same holds true for every function in a startup whether it be design or customer development. Any team member that is not engaged in your #1 priority will deliver less than their capable of contributing and, by the way, they’ll probably get bored with their function sooner rather than later.

There are, of course, many other key processes that startups should consider, including agile planning, TDD, continuos integration, consistent refactoring, etc. These concepts are well covered in the books listed above. But the six mistakes above are the ones that I believe are too often overlooked in the early phase.

Go to blog post

Preventing Recursion in Ruby

Posted by avdi January 24, 2012

Sometimes you need to prevent code from executing recursively. I had to do this recently in order to prevent an infinite recursion in ActiveRecord callbacks. A before-save hook needed to save a parent model attribute, which because of an :autosave option would then try to save the child model, which would then try to save the parent… and so on until the stack overflowed.

Unless the method is directly calling itself, the only way to short-circuit a method when it recurses is to have it set some global flag which it can then check in recursive calls. If the flag is already set, the recursively called method bails out early. Once the original invocation is finished it unsets the flag.

It’s not safe to use a true global variable for this flag, since this would not be threadsafe. The safe way to do it (albeit not a terribly pretty one) is to use thread-local variables.

I decided to go ahead and write a macro which can turn any method into a non-recursive one. Here’s the code:

Let’s take a closer look at that.

The method takes an argument, method_name, which is the name of the method to make non-recursive.

Then it creates a name for the recursion flag. Since thread-local variables are global for the whole thread, we need a variable name which is reasonably unique. We get one by combining the current class and the method name.

We’re going to replace the method with a modified version, so we need to stash the original implementation somewhere. We grab an UnboundMethod object by calling #instance_method() on the current class:

Then we proceed to redefine the method:

The first thing the modified method does is check to see if the recursion flag is set. If it is, it bails out.

Otherwise, it sets the flag:

And then it binds the UnboundMethod stored in original to the current instance. This generates a Method instance, which it proceeds to call, passing any arguments along.

(Note that I wrote this code for a Ruby 1.8 codebase. If it were for 1.9 I would pass the &block down to the original as well. Since blocks in 1.8 can’t accept &block arguments, I can’t do that here so long as I’m using the block form of define_method. So this macro will only work for methods which do not take blocks.)

Finally, the code ensures that the recursion flag will be unset when the method is finished, even if an exception is raised.

Note that setting a thread-local variable to nil removes it:

I have no idea what :__inspect_key__ is, but as you can see the :foo key goes away after setting it to nil.

Let’s take a look at this in practice. Here’s are two methods #foo and #bar (original, no?). #foo is recursive, with #bar as an intermediary, preventing it from passing a recursion flag directly to itself.

Calling the #foo method results in a stack overflow:

But if we update the method with prevent_recursion, it successfully exits:

Go to blog post