How TCR was born
A decade of code camps
August 2018, a spaceship powered by an Infinite Improbability Drive did a fly-by right over the Iterate office. It happened a short time after three of our technologists, Oddmund Strømme, Lars Barlindhaug and Ole Tjensvold Johannessen, had teamed up with our good friend and mentor Kent Beck. They had been given a simple, but powerful, week-long mission: To geek out, together, with whatever they wanted to do. Then, in a discussion about developer incentives, small diffs and symmetry, time and space bent. Incidentally, this was also the moment TCR was invented.
Today, pioneer coders all over the globe are exploring TCR to understand its applications, implications and possibilities. This the story about how the idea came into being, and how you and your company can come up with ideas and movements of your own.
To understand why we think it was a hardcore business decision to ask three of our top engineers to spend a week together with Kent Beck, with no other plan than to have as much geeky fun as possible, we have to go some 12 years back in time. It was the second year of business for Iterate, and we had launched the motto “to become the best, we have to learn from the best.” We had started with a team of software engineers with the rebellious mission to learn as you go — in software projects. (As the world around us caught up on iterative development, we moved on to a new rebellious mission — to let employees build crazy ideas into companies they own — but that’s for another post).
We believed in the power of teams, iterations and agility, and one name was at the top of the list of people we wanted to learn from. Little did we know then the impact Kent Beck would have on our company (and the impact we would have on him).
A cold day in February that year, we got on the bus from Oslo to Gothenburg, where Kent was attending a local conference. Nervous like hell, we drank freeze-dried coffee while looking over our company presentation. Paranoid thoughts flashed by: Were we in fact about to meet the Kent Beck — inventor of extreme programming, JUnit, test-driven development and a whole lot more? What if it was just some Kent Beck, totally into goat cheese making or guitar playing or whatever? (More on that later.)
In retrospect, Kent has admitted that he had been skeptical at first: Not only had these two young coders taken the bus all the way down there to see him — they were even stupid enough to admit it. What saved us, was the last slide of our presentation, that summarised our vision for the company: It said we wanted to be the world’s best employer for creative technologists. And we needed his help to get there.
In the coming weeks and months we designed Code Camp together: A week filled programming and discussions, where teams of three work together with Kent to grow, learn new skills, and have fun. It became a huge success, and today we’ve been doing code camps for a decade. Some teams have used it to solve problems in live projects, some have explored new, innovative business ideas — and yet some, at least one — have gone about inventing new programming methods.
Code camp has just that simple mission: To clear out your calendar for a week, and have some good, geeky fun. Curiosity and exploration, in a safe and human setting. There’s no upfront plan, no expectations and no promises made, except for those they give each other as they go (so bring a towel). After deciding on a goal for the week on the first day, Kent simply starts every day by asking what we hope to accomplish that day. He ends every day by asking what was the best thing that happened that day. In the meantime we code, experiment, break things, clean it up, laugh and talk. (That’s right: You’d be amazed how much geeks are able to talk, if the setting is right). Sometimes we iterate on live users, sometimes we close the doors and dig into an intricate algorithm, sometimes we go wild trying to crack _____________ (fill in a geeky problem to solve).
Last year, Kent told the team about how he was exploring programming workflows that made it more natural to implement and commit tiny changes to the source code. They decided to jump on it, and started out by using a simple script Kent had made that automated the commit to the code base — provided that automated unit tests had passed. Not long after, however, Oddmund Strømme felt a disturbance: If you automate the commit of working code, for the sake of symmetry, you should also automate the deletion of non-working code - shouldn’t you? It made sense from a logical point of view, but why on earth would anyone want to delete code they just wrote, just because something in it was broken? Wouldn’t it be much faster to fix whatever was broken, instead of starting from scratch again? Just imagine if you had written a lot of code — who would want to delete a lot of code, right? Hell, with this idea, we'd better make sure to write really small chunks of code, and get them committed as soon as possible. Wait a moment .. WAIT A MOMENT!
Most ideas that sound crazy, but turn out to be viable, just flash by our minds, unarticulated and unchallenged, only to evaporate in the heat of insecurity and interpersonal tensions. It doesn’t help that someone already have thought about something similar. To get off the ground, someone has to have the confidence to start spreading it, and the rest must have the confidence to listen. That’s what’s so fundamental about this story: How TCR was treated at its most fragile stage, right after the final piece of the puzzle (the revert part) had been articulated to the team. At this point, it would’ve been super easy for anyone to utter “Auto-delete code? Meh. Let’s get back to work.” In that case, TCR would have vanished in a puff of logic (much resembling the way TCR deletes malfunctioning code today - in a puff of a bash script).
Just imagine how many ideas are finished off this way every day, every hour around the globe.
A decade ago in Gothenburg, Iterate and Kent Beck made a commitment to start harvesting such thoughts and ideas. It seems like we are getting better and better at it, for each camp we run. And to clear out the confusion: Kent does make goat cheese, and he does play the guitar (no wonder he's good at improvising, also in coding..)
Here's a way to test your organisation’s ability to innovate: Ask yourself, what will I risk, and what will I gain, from exposing myself with something that has more than 90% chance of failure? If the risk surpasses the gain, chances are high that the best ideas (who initially sound like stupid ideas) will never surface. This is how innovation fails from the very beginning: Great execution will never help you escape the walls and ceilings of a mediocre idea.
This is why Iterate's Code camps are about committing to the unknown. Now, the team has no choice but to navigate on the learning and insight they get as they go. This offers any kind of technologist, from coder to designer to business developer a great opportunity for discovery. You cannot force great ideas to be born, but when we remove the walls and ceilings of how we are supposed to think, you can start hoping for them to emerge. Especially when you make a habit of it.
How do you cross interstellar distances? Easy. It happens the moment you turn a crazy idea into something viable.
Thx to Oddmund Strømme, Lars Barlindhaug, Ole Tjensvold Johannessen and Kent Beck.
