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):
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 postPosted 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:
Posted by Taus October 19, 2011
Last week at the Bend Venture Conference, Central Oregon’s newest (and only) business accelerator was unveiled. VentureBox is a business accelerator focused on supporting concept stage startups. The initiative is a program of the Tech Alliance and is committed to Central Oregon’s entrepreneurial community and helping turn innovative product and service ideas into great companies.
Although a much larger group of mentors will be announced, the current team is pretty impressive and represents management, finance, technology and other key skills for early stage companies. VentureBox will be offering mentorships, infrastructure and a milestone-based program to develop startups into investment-ready enterprises.
We think that VentureBox has great potential to help diversify the Central Oregon community and create sustainable, living wage jobs. That’s why we’re proud to be supporting and participating in the effort!
Go to blog post