Kent Beck had a great anecdote in his Startup Lessons Learned talk yesterday which proved to be an apt metaphor for the role of a startup company. Kent keeps goats where he lives in Oregon and he talked about how he would go out to his backyard and approach one of the goats. He would scratch it behind its ear and it would happily munch grass, then he would scratch its neck and along its back, and then he would get to a particular spot on the rump of the goat and the goat would suddenly respond in ecstasy.
When you start a company, you have an idea, but you haven’t found exactly who needs it or exactly how they want it delivered. You are scratching the goat. It is your job to find the itchy spot.
You keep doing stuff, no response..Keep doing stuff, no response..then the eighth idea you try, it has a big effect. There is some little activity which has an out-sized effect in a particular location.
How do you know what people need? How do you find the itchy spot?
You need to be focused on answering questions. Engineers have an almost irresistible urge to build stuff to answer questions, but that isn’t very efficient. Sometimes you can answer your question without building any real software at all. He talked about wondering if people would buy at the next level of the game. “I put an empty button in my app just to see if anyone would click it. When they did, THEN I built what goes behind it… I love not having customers. If I don’t implement the payment gateway, there is no issue”
“I’m no longer focused on how I can do the best software development, but instead: how can I get the most value? Sometimes it will look like mock-ups, not software. Sometimes it will look like hackery. It feels good to do good engineering, but that is not good startup engineering. The key thing is figuring out when to switch from hackery to scalability.”
Change how you keep score over time as your business changes.
Like most engineers, Kent revealed that he has tendency to keep building after he has learned. We need to identify the question that we are trying to answer with a particular piece of software development. And then, remember to ask the question again.
Q: how do you balance long term and short term goals? How do you manage technical debt?
A: The Principle of Pull and Flow
Pull: I’m going to refactor my code when I understand the benefits of restructing
Flow: How can I divide that big restructure into small pieces that deliver value?
The challenge is to learn to enjoy the hack.
Ask your engineers: “How quickly can we answer this question?” not “How quickly can we build this feature?”
He told a story about an engineer nicknamed “Mr. Flat File,” who would always ask whether something could be implemented as a simple file. No engineer likes that as a technical solution, but it does force people to identify the benefits of the particular storage mechanism and data structure that they are recommending. Flat files don’t optimize engineer satisfaction but they do increase flow.
Kent honestly declared “I want to do good engineering,” where good is defined as self-serving.