Mission: Extreme startup

At the London SkillsMatter office, London Software Craftmenship Community organized an Extreme startup exercise.

It was a great opportunity to participate in a training mission.

The exercise aims at re-creating high pressure development environment. Something just right for a real man! This involves no procrastination or only pen and paper exercise, just real programming. During the exercise, each team tries to build a web server that responds correctly to queries issued by the master server.

I thought it would be easy. What could go wrong during such a short exercise? How naive of me. This mission was tough, but it helped me a lot to better realize who I am as a programmer and what I am capable of.

The Extreme Startup was conducted in four parts:

1. Load
The team I was in was pretty decent. Unfortunately, our computers had one of those bad days. During whole first game phase we were setting up Internet connection.
  
2. Aim

The server can work in a testing mode, allowing players to verify their set up and provided scaffold implementations. (btw. It bears huge resemblance to walking skeleton approach.)
We spend this phase... setting Internet connection. How disappointing!

3. Shoot!
This part was fun! We spent it downloading code, setting up environment and then trying to catch up with the rest of a group. We had a strong feeling that we are trying to build product for a market that is fast changing and all competition is far ahead. At some point we even had a killer idea - but we failed to execute it...

4. Look
Extremely short due to time limitations.

Take Aways

1. Mind Your Squad Size
   Three programmers at one computer is too much. It is hard to achieve something when there are constantly at least two ideas in the air.
2. Steady, Steady...
   Every plan must have it's time to be executed. There is no point at trying a new idea, before you learnt from previous one. We had a great idea (at least three to be precise). However, we did not hold on to any of them long enough to learn about our biggest problem - which was that server did not understand any of our responses.
   
3. "And thirdly, the code is more what you'd call "guidelines" than actual rules."
   So called "good practises" are actual guidelines what should be achieved, and they need to be applied for a given situation. E.g. no team during exercise did TDD, as there was no point to do it for throw away code that changed in minutes rather then days. However, acceptance tests proved to be useful as they shortened loop back time and thus gave those teams advantage.