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.
For more on Kent’s talk, read beyond agile development.
Good perspective from Steve Freeman: Not a Charter for Hackers
Gosh, I don’t know about this Sarah. This attitude is similar to the hardcore TDD stance, which I also struggle with. I guess I agree that sometimes rapid, hacky iteration is the best thing, but I think there are certain problems that are worth solving correctly, even if it takes more time.
I think TDD often produces verbose, paradoxically bug laden software, precisely because the process encourages myopia. Similarly, I think that there a lot of questions that can’t really be answered until you’ve developed a proper solution for them. People say they don’t like the new feature, but is that because it’s buggy and slow?
The point is to have a hypothesis that you are trying to prove with your code. Anyone who does TDD without a vision of what the software should do is missing the point. There was a lot of talk at the conference about having a big idea and how to find the right expression of it. If a feature needs to be fast, you need to do the engineering to make it so, but I’ve often seen (or been) an engineer who adds detailed options because someone might need them when something else (like performance or a different feature entirely) is actually what is needed.
The key thing is to keep asking the high level question — *sometimes* the answer is a hack or a paper mockup or simply a phone call to a customer to understand what is really needed before creating a complete, robust, performant implementation.
I’m thinking about this post not in the context of creating code, but in the context of the overhaul of my website (a redesign & port to a new blogging platform; recruiting new writers), nearly complete– a process which took months.
I write & sell novels that generally appeal to hardcore geeks & hackers. I’m trying to sell more of them. My website is my main vehicle for making these books known to the world. But right now, the book-promotion parts of the site are not even implemented yet. There was too much other work to do first.
But let’s assume that I’ll have some kind landing pages and shopping cart done soon, within the next few days.
What then? What itch am I trying to scratch? What problem am I trying to solve for Wetmachine’s readers? And what connection is there, if any, between the value readers get from interacting with my site and the value they would get from buying one of my books?
And now that I have a nifty site with 8 quality writers and a big backlog of articles, many of them still relevant, and more new ones coming virtually every day, what other opportunities lie before me, beyond just selling books?
I’m thinking. . . where’s the itchy spot? I dunno. I’m going to keep looking for it. . .
Pingback: SKMurphy » Startup Lessons Learned Conference Coverage Roundup
Pingback: April 27, 2010, Now Writing About Cucumbers « Rails Test Prescriptions Blog