Why not release earlier?

30. August 2012 — 3 Comments

A post about how to overcome the terror of feedback, and why it is an important step towards continuous delivery

I had a conversation yesterday with a team that was putting out version zero of a product. “Yes, yes. Release early, release often. We absolutely agree.” I thought the conversation was going well. “Of course, we need [insert completely useless feature here] before first release.” Dang. Again?

I have had this discussion, with others and myself, a hundred times. What is going on? Why do we repeatedly agree that feedback is good and then do really crazy things to avoid feedback?

Having watched myself elevate unimportant features to the status of must-haves many times, I have decided that I am at war with myself. On the one hand I want feedback. Of course I want feedback. Feedback makes me better and smarter. Feedback makes my projects more successful. Even if the feedback is “cancel the project”, that just means I have more time for other potentially-useful projects.

On the other hand I hate feedback. To work on a project I become emotionally attached to it (too much). I believe it will be successful. I care that it will be successful. I am afraid that if I lack passion, I won’t be able to work. From this perspective, feedback is a threat, not just to my project, but to me.

Psychologists talk about boundaries, having a good sense of what is me and what is not me. When I manufacture enthusiasm for a project, I blur my boundaries. I begin to think, even though it isn’t objectively true, that my project *is* me. Feedback at that point becomes a personal, existential threat, and my brain is really good a performing rhythmic gymnastic contortions when faced with a personal, existential threat. Like believing, really believing, that automated deployment infrastructure is absolutely vital for the first release.

When I catch myself thinking this way I use a few techniques to return towards sanity:

Ask for feedback. Friends don’t feel an existential threat, so they remain saner. “Here are all the things I have to do before first release. Anything on this list optional?”
Remind myself that my project is not a part of me. Over and over. I figure if I repeat it ~1e6 times I may begin believing it.
“What’s the worst that could happen?” There’s a sequence to my thinking. It’s quick, but if I am aware I can catch the steps: 1) think about getting feedback, 2) imagine failure, 3) terror, 4) invent new must-have feature. If I can intervene at 2), I ask myself, “What’s the worst that could happen?” The project is cancelled. My reputation is ruined. I never program again. My whole family starves to death. I go to hell forever. Okay, so the consequences won’t be that bad really. What’s likely to happen? Change the project direction. Oh, that’s not so bad.

I’m not sure everyone reacts this badly to the prospect of feedback, but from the conversations I have I suspect that many people do.

What’s your “terror of feedback” story?

En hektisk og morsom sisteuke!

27. July 2012 — Leave a comment

Siste uken her har vært litt hektisk, litt slapp, og veldig moro. Vi har blitt intervjuet av Computer World, hatt medarbeidersamtaler, fortsatt med brukerintervjuer og mye god feedback, i tillegg til et veldig hyggelig Skype-møte med Kent Beck. Computer World-artikkelen kom ut allerede på torsdagen, noe vi syntes var veldig stas.

Etter publiseringen av applikasjonen på Google Play Store begynte vi umiddelbart med bug-fiksing. Når vi lastet opp Strandfunn var vi klar over flere feil og mangler, men vi prøvde å være strenge mot oss selv, og få den publisert så fort som mulig. Vi fulgte de vise ordene “Man skal være litt flau når man gir ut app’en”. Idet applikasjonen var live, og man kunne kjøpe den, fikk vi ekstra motivasjon til å polere applikasjonen og gjøre den bedre. Det tok ikke lang tid før vi fikk tilbakemeldinger på feil og mangler, og da var det bare å hive seg rundt, fikse feilene, og laste opp en ny versjon så fort som råd var. Alt dette ville antakeligvis ikke blitt tatt hånd om så raskt som det ble, hvis den ikke hadde vært ute og tilgjengelig for salg på et tidlig stadie.

Programming Like Kent Beck

20. June 2012 — 11 Comments

Three of us, namely Stig, Krzysztof, and Jakub, have had the pleasure of spending a week with Kent Beck during Iterate Code Camp 2012, working together on a project and learning programming best practices. We would like to share the valuable lessons that we have learnt and that made us better programmers (or so we would like to think at least).

Kent Beck: Best Practices for Software Design with Low Feature Latency and High Throughput

12. March 2012 — Leave a comment

I was fortunate to attend a lecture by Kent Beck, Iterate’s Chief Scientist, for one of our customers, summarizing his experiences and thoughts regarding efficient software design. Traditionally there have been two schools of thought about design: Predictive design, trying to design everything upfront (and making lot of wrong decisions) and reactive design, where any design is only done if it is absolutely necessary for implementing a feature (thus developing often on top of an insufficient design). Kent tried hard to discover such a design method that really delivers on the promises of both while avoiding their failures. This method is based on evolving design frequently in small, safe steps and focusing on learning while following some key best practices. It doesn’t really matter what scope of design we are are speaking about, the method and principles are the same whether you’re redesigning a class or a complex system.