Thinking Inside a Bigger Box

I hate giving promises for things I can’t control. I can promise that I will attend a party or that I will set aside time to help you with your problem. I cannot promise that the party will be fun or that your problem will be solved. Giving promises on effort is honest, giving promises on outcomes is dishonest.

A team that commits to an estimate is promising something they cannot control. A team that is blamed for giving an estimate that is too low can easily avoid that particular mistake next time around. And given the law that work expands to fill available time, the estimate will never be too high. The result is cost spiraling up.

What if we assumed that estimates would never be particularly reliable. And if we assumed that forcing a team to commit to an estimate is unreasonable behavior? How would we act in a world where that’s true?

Let’s imagine we live in a world where the product owner cannot ask for an estimate. What can the product owner do instead?

The product owner can say “stop working on this story if you’ve spend more than 40 hours. Or if you think you will end up spending more than 40 hours.”

Such a limit can be viewed as a budget.

The product owner can make a bet on how many user stories the team will complete by looking at what they have done before. If the consequence of the betting wrong are severe, the product owner can be cautious about the number of user stories. (Bonus question: Is the team is a better or worse position to know the consequences of betting wrong?)

Such a bet can be viewed as a forecast.

The team, on the other hand can commit to working according to the agreed-upon rules. They can commit to do things in the order set by the product owner. They can commit to doing the best job they can within the time budget the product owner has allocated.

We commit to effort, not to outcomes.

As a user, I can add social security number, so patient logs have social security numbers

As a developer, how would you react if you were given this user story? Would you throw it back in the face of the product owner, or would you try and understand it?

How about the following dialogue?

• Developer: “What are we hoping to achieve with this story?”
• Customer: “We hope that the patient logs will have social security numbers. Duh.”
• Developer: “Sorry, I was unclear: What problem do you experience now that we don’t have the social security number?”
• Customer: “Oh! We need the social security number when we bill the customer.”
• Developer: “I see. So what happens now?”
• Customer: “Well, since the patient has left the hospital, the billing department has to phone or send postal mail to get the information. That’s a lot of work.”
• Developer: “What places in the application can we add this information?”
• Customer: “We’ll add it to the patient journal.”
• Developer: “Who updates the patient journal, and when?”
• Customer: “Whops. The doctor updated the journal after the patient has left. We better add it when secretary checks the patient out. So that would be in the appointment system”
• Developer: “What other places could we enter this information?”
• Customer: “Well, we could have a field for the social security number when the patient first requests the appointment”
• Developer: “So, we have considered two options: The appointment system at checkout or the appointment system when the appointment is booked. What other ways could we get the same information?”
• Customer: “We could collect it from the governmental web service, I suppose.”
• Developer: “What would you like us to try first?”
• Customer: “Since the patient normally fills in the appointment request themselves, let’s try that out first.”
• Developer: “Let’s see if I get you correctly….”

In order to have the required information to send an invoice, as the billing department, I want the patient to enter their social security number when they request an appointment

What you’ve just witnessed is a series of questions that can be organized like this:

• Goal: What are we hoping to achieve? How will the user story change the world?
• Reality: How are things working now?
• Options: What else could we do instead? In addition?
• Will: What will we do? What is our plan of action

The GROW mnemonic is a tool from professional coaching. That is: Talking to people about the problems and ambitions in their professional and private lives. It helps guide a novice coach through a coaching conversation and focus on the problems of the person being coached. Or, in this case: On the business value we want to achieve.

At the end of the day, as a developer you will be judged not on whether you followed the orders you were given, but whether you understood and delivered what was really needed. By asking your users, your product owner or your domain expert what they really, really want (Goal), it will be easier for you achieve. And if you don’t have access to the relevant people, these questions can still help you guide your thinking about the requirements.

You can read more about the GROW model at What-is-coaching.com and many other websites devoted to helping people get to the best of their ability.

A big thank you goes to Antti Kirjavainen for suggesting the patient journal example and for coaching me in the process of writing this article.

Do you know how to apply coding practices the technology stack that you use on a daily basis? Do you know how the technology stack works? For many programmers, it’s easy enough to use test-driven development with a trivial example, but it can be very hard to know how to apply it to the problems you face every day in your job.

Java web+database applications are usually filled to the brim with technologies. Many of these are hard to test and many of these may not add value. In order to explore TDD and Java applications, I practiced the Java EE Spike Kata in 2010. Here’s a video of me and Anders Karlsen doing this kata at JavaZone 2010.

A similar approach is likely useful for programmers using any technology. Therefore, I give you: The rules of the Architecture Spike Kata.

The problem

Create a web application that lets users register a Person with names and search for people. The Person objects should be saved in a data store that is similar to the technology you use daily (probably a relational database). The goal is to get a spike working as quickly as possible, so in the first iteration, the Person entity should probably only contain one field. You can add more fields and refactor the application later.

The rules

The most important rules are Robert Martin‘s three rules of Test-driven development:

• No code without test (that is, the code should never do something that isn’t required in order to get a test to pass)
• Only enough test to get to red (that is, the tests should run, give an error message and that error message should correct)
• Only enough code to get to green (that is, the tests should run and not give an error)
• (My addition: Refactor on green without adding functionality)

Secondly, application should be driven from the outside in. That is, your first test should be a top-level acceptance test that tests through http and html. It’s okay to comment out or @Ignore this test after it has run red for the first time.

Lastly, you should not introduce any technology before the pain of not doing so is blinding. The first time you do the kata in a language, don’t use a web framework beyond the language minimum (in Java, this means Servlets, in node.js it’s require('http'), in Ruby it means Rack). Don’t use a Object-Relational Mapping framework. Don’t use a dependency injection framework. Most definitely don’t use an application generator like Rails scaffold, Spring Roo or Lift. These frameworks can be real time savers, but this kata is about understanding how the underlying technology works.

As a second iteration, use the technologies you use on a daily basis, but this time set up from scratch. For example, if your project uses Hibernate, try configuring the session factory by hand. By using frameworks in simplest way possible, you’ll both learn more about what they bring to the table and how to use them properly. For complex technology like Hibernate, there’s no substitute for deeper understanding.

What to expect

So far, I’ve only done the Architecture Spike Kata in Java. But on the other hand, I’ve done it around 50 times together with more than ten other developers. I’ve written about how to get started with the Java EE Spike Kata (in Norwegian) on my blog before.

This is what I’ve learned about working with web applications in Java:

• Most Java web frameworks seem to harm more than they help
• Hibernate is a bitch to set up, but once it’s working, it saves a lot of hassle
• Using TDD with Hibernate helped me understand how to use Hibernate more effectively
• I’ve stopped using dependency injection frameworks (but kept on using dependency injection as a pattern)
• I have learned several ways to test web applications and database access independently and integrated
• I no longer have to expend mental energy to write tests for full stack application

The first time I write this kata with another developer, it takes around 3 to 5 hours, depending on the experience level of my pair. After running through it a few times, most developers can complete the task in less than an hour.

We get better through practice, and the Architecture Spike Kata is a way to practice TDD with the technologies that you use daily and get a better understanding of what’s going on.

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo.

This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!) or anywhere else in the world.

A Coding Dojo is a place to learn and have fun while programming

Quite simply, a Dojo is a gathering of programmers who come together to have fun and learn while programming. It’s always hands-on and it’s always social. In Oslo there are about 300 people who have signed up their interest. We meet on average once per month, usually in a bar. There is anywhere from 5 to 25 people who attend any given meeting.

Alternatively, a Coding Dojo can be used to describe a single event for a company or team that wants to train their developers in a hands-on and engaging way.

Coding Dojo Style #1: Many programmers, one problem

In the martial art Aikido, “Randori” means that multiple people are attacking the same person. In the Coding Dojo, “Randori” means that multiple programmers are attacking the same problem.

In order to organize a randori-style dojo, you need a computer with a development environment, a projector, a place to meet, a facilitator and 4-10 programmers who attend. Here is one way to carry out a Randori Style Coding Dojo:

• If the group is new to test-driven development, the facilitator demonstrates the red-green-refactor cycle with a simple example (no more than 10 minutes)
• The facilitator introduces the programming problem (kata) to solve. The Prime Factors kata is a good first kata for a group
• The faciliator invites a partner to join him at the keyboard. The facilitator writes a first test, makes sure it runs red and invites someone else from the group to take his place.
• Each pair works on the problem for 5-10 minutes, the facilitator then makes sure that one person in the pair is switched out with someone in the audience.
• After about 45-60 minutes of working on the problem, call a break and review what’s happened. Personally, I’ve had success with asking everyone to name one thing that they learned, one thing that surprised them, and one thing they want to change about the way they work.
• After the review, the group can work on another kata (problem), try the same problem again or use another exercise form

The biggest barrier for most people to participate in a Coding Dojo is that most programmers have never programmed live in front of anyone else. This feels extremely awkward and vulnerable at first. As a facilitator, your most important job is to help everyone feel at ease at whatever level they are.

Coding Dojo Style #2: Pairs working in parallel

Some people report that a Randori-style dojo can feel slow and constrained. As an alternative, I sometimes use the CyberDojo software, created by Jon Jagger. For a CyberDojo style dojo, you need a place to meet, a computer with a projector and internet access, a facilitator and 6-30 programmers with their own laptops with a web-browser and internet access. Here is how I usually carry out a CyberDojo style Coding Dojo:

• The group forms pairs of programmers
• The facilitator sets up a CyberDojo on http://cyber-dojo.com. (It may be smart to send a quick tweet to Jon to make sure he’s not planning to restart the server at this time)
• All the pairs work in the fashion the group has agreed to work for 30-60 minutes
• After the coding session, the facilitator uses the CyberDojo dashboard as a focus for discussions of programming habits

If you’re thinking about facilitating a Cyber Dojo, just go to http://cyber-dojo.com, try creating a dojo and solve a kata. You can do this on your own now!

Coding Dojo Style #3: Working under stress

Extreme startup is a workshop based around a server that will ask questions of the software running on the computer of each participating pair. As the pairs answer questions correctly, they are awarded points. I usually run an Extreme Startup session after having run a strict TDD Coding Dojo. In the Extreme Startup, teams can work any way they want.

The Extreme Startup software is developed by Matt Wynne and Richard Chatley. There are several forks, including mine, which tries to maximize the stress.

In order to run an Extreme Startup workshop, you need a place to meet, a computer with a projector and the Extreme Startup software, a facilitator and 6-30 programmers with their own laptops with a development environment of their choice. All the computers need to be on a shared network so they can communicate using TCP/IP.

• The group form pairs. If someone wants to work solo, or in bigger groups, that is okay, too
• The facilitator starts the Extreme Startup software in warmup mode
• The facilitator demonstrates how to get started (I use this collection of starting points in a number of languages)
• The teams work for around 30 minutes until (almost) everybody have been able to get a web server running and registered on their computer
• The facilitator starts the Extreme Startup software in real mode
• All the teams reregister their servers. All hell breaks lose as they try to implement the questions as fast as they can
• After the teams have worked for another 60 minutes, the facilitator breaks off the competition. Ask the teams on the top to describe how they worked

If you’re thinking about facilitating an Extreme startup, download my or Richard Chatley’s version of the software to your computer. The README file explains how to get it running. Then download Bodil Stokke’s collection of starting point to your computer. Use the ruby/sinatra_for_dummies starting point to create a solution. Let me know of your experiences when trying out the software, so I can improve the README.

You can do this by yourself now!

Start a coding dojo

A coding dojo is a great way to build your professional network, become a better programmer, and to have fun! I hope this article can help you get started.

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

If you are a local developer in Kiev, Gothenburg or Riga this could be a chance for you to improve yourself. I’ve got more than ten years of experience with extreme programming practices and chances are you will learn a few tricks that will put a smile on your face. I will practice with you before the conference, and my goal is to make you shine during the presentation. Chances are that your peers will recognize your skills after the conference, so this may help you get some local fame and build your personal brand. Finally, programming as an exercise is great fun and the experience is likely to leave you with a smile on your face.

Here’s what Jussi, who I paired with for #TampereGoesAgile has to say about the experience:

agilepoodle

(Jussi Mononen)

Still totally overwhelmed by the skills of @jhannes @ #tamperegoesagile. Highlight of the conf: 1 hour if pairprogramming with him! On 18-9-2011 11:22:52 from HTC Peep

If you’re a programmer who’s willing to take a risk, learn a lot and get some attention from your peers, please get in touch via @jhannes, johannes@brodwall.com or comment on this blog post.

Instead of using Scrum, maybe we should use MyScrum. It’s like Scrum, with the stuff added that you think will super charge your MyScrum.

This is my MyScrum:

• I want to measure velocity every week
• I want to demostrate the product with a cadence that makes sure users show up to the demo
• I don’t want to have story point estimates, I want to have story point budgets
• I want the product owner, not the team, to own the budget/estimate (but they team may veto)
• I don’t want commitments or forecasts from the team, I want measured historical progress
• I want to plan per story, not per sprint
• I want the developers who will develop a story to follow it (or pass the baton to other developers) from detailing to deployment.

What does your MyScrum look like?

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now?

To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?

You will quickly notice that testing will be more effective if you test earlier. What is unreasonably early: Testing before we have something to test. Thus the idea of test-driven development is born.

You will quickly notice that code review is an effective form of improving quality and spreading knowledge in the team. What is an unreasonable amount of code review: All code should be written by two people. That is, pair programming.

Similarly, the idea of user stories comes from the observation that communication between users and developers is key to effective development of a user friendly system.

Some of the ideas of extreme programming don’t feel so extreme anymore. But the spirit should live on. What would it mean to do what we know works today to an unreasonable degree?

Take continuous integration for example. Most teams use continuous integration to run tests when they check in the code. What would happen if we ran the tests whenever something changes? Most languages support continuous testing or autotesting today and teams are starting to adopt this now.

Frequent releases may mean once every 1-3 months for many organizations today. What would happen if you increased the frequency from months to weeks, or from weeks to days. Or from days to hours? Some extreme organizations actually push changes into production automatically when their batteries of automated tests succeed.

Short iterations work and reducing parallel work helps many organizations today. What if we got away from the iteration altogether, and a developers pick the next story when ready. What if we delayed all discussions about the user story until a developer was ready to start programming it? Many organizations are working with variations of kanban to increased flow and reduce waste.

Extreme Programming means pushing the things that work further than we’ve done before. What good ideas would you like to do to an unreasonable amount?

On larger projects, I’ve always ended up resorting to writing down a lot of detailed specifications, many of which are wrong, irrelevant or we might not be ready to answer them yet. On small projects, the dialogue between the customer and the developers can flow easy, and good things happen.

The quick analysis

Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Customer: Sure. The next task on the backlog is to send the payment request to the accounting system

Developer: Yeah. Um… well, we’re not really ready for the integration tasks yet. I was thinking that we might perhaps pick another user interface task. Would that be okay?

Customer: No problem. Let’s see…. how about “road project submits funding request”?

Developer: Great. What’s that?

Customer: Well, today, the owner of the road project sends in a paper form. Let’s see, the form is available as a PDF on our web site. Let’s take a look.

Developer: Let’s see…. We know how to deal with social security number, names, addresses. This field “municipality,” that’s the usual stuff, right? (customer nods) What about “request id”? What’s that?

Customer: It’s just a sequence number per municipality. It would be really nice if you could suggest a request number and then let the user override.

Developer: That should be doable.

They work out a few more details and get on their way. Total time, 30 minutes

The low ambition implementation

Developer: So, we worked on the funding request UI for the last two days. I think we’ve got something that looks pretty good.

Customer: Great, let’s see it! Let’s see… There’s a new “apply for funding request” menu item. Nice. But it should be “Fund road project” (developer notes feedback). Let me try and press it… Hmm… “select municipality”? Why do I get that?

Developer: Well, we’re still a bit shaky on AJAX. So in order to find the next sequence number, we would like to have the user select municipality first.

Customer: Oh, AJAX. That’s interactive web pages, right? Yeah, I guess that’s fine, but we need to fix up the text a little. So, what happens when I select one…? Nice, it sort of looks like the paper form. That will help us get learn it. But let’s move the fields around a little (he sketches a few change on a piece of paper).

Developer: We were a bit uncertain about this “sum” field. Does the user have to fill in the sum himself? He’s already filled in all the numbers.

Customer: That doesn’t make too much sense. How about if the web pages updates the sum field dynamically? Oh, you’ve got that ‘don’t make me do dynamic webpages’ face again.

Developer: Yeah, sorry. The last time it was a big mess. Can we hold off on that for now? Do you really need it?

Customer: (laughs) No, that’s okay. I guess we can just remove the field. That should be fine.

Developer: Yay! What about validating the bank account number? We left that out, because the documentation is…. well, insane. That alone will take at least another day.

Customer: No, we really need that. People often type it wrong, and then it’s a nightmare to fix all the errors that follow. You just have to fight though it.

Developer: (sigh) I guess it can’t be helped. We’re on it.

Customer: All in all, it looks pretty good. I’ll go over it by myself after lunch and bring you back some issues tomorrow.

The quick completion

Customer: Here’s a list of corrections. Nothing major, just a few misplaced fields and a few extra validation rules.

Developer: Great. We spent all of yesterday doing the bank account number validation. Man, that’s some bad doc! But we should be done before lunch.

Customer: I have an opening in my calendar at the end of the day, let’s take a look then and call it done. Great work, guys!

The contrast

Have you ever been on a small project where everyone has a pretty good understand of what’s going on and the communication works well? Developers can make a pretty good guess at the details and develop a pretty good first version. There may be some more work that’s needed, but these can be negotiated when the developers have a better idea of what’s going to be easy and what’s going to be hard.

When I’ve been on larger projects, this communication seems to break down. Instead the developers require a detailed specification in writing. And if something is missing from the specification, they reject it and ask for further details. And they won’t show the product to the customer before all the kinks are worked out.

When we do it well it’s not so bad, getting a detailed specification and finishing the task before we get real feedback. But it requires the customer to decide on things that may not be important, but that may impact cost substantially. It requires back and forth to get the specification written, reviewed, amended etc.

On a small project, a developer can understand the purpose, build something quickly and adjust it based on feedback. Is the reality of larger projects that this will just remain a pipe dream? If so, why? If not, how do you get the quick and informal feedback?

Oracle released Java 7 on July 28, 2011. This is nearly 5 years after the release of Java 6 in December 2006. The release received a lot of bad press, both because it is very meager on features, and because it shipped with a severe bug. Nevertheless, once the most serious bugs have been fixed, you might think about starting to use Java 7. What will this mean?

New language features

Java 7 has a few new language features. Sadly, the most exciting ones have been postponed until Java 8. The following 3 features may show up in your pretty quickly, though:

try ( BufferedReader reader = new BufferedReader(new FileReader(...))) {
  String line = reader.readLine();
  process(line);
}

This is the try-with-resources or Automatic Resource Management block. If you declare a variable in the try() statement, Java automatically calls close on it, like you would in a finally block. This is a small improvement, but nice. You can use try-with-resources on your own object by implementing the new interface java.lang.AutoCloseable.

try {
    clazz.getConstructor(List.class).newInstance(list);
} catch (InstantiationException|IllegalAccessException|InvocationTargetException|NoSuchMethodException e) {
    throw new RuntimeException("I really don't care", e);
}

This is the multi-catch statement. It’s useful because of the load of checked exceptions on the sanity of your average Java-developer. It’s nice, but hardly revolutionary. It makes me really wish we got rid of checked exceptions, though.

Map<> ordersPerCustomer = new HashMap<customer ,List<Order>>();
</customer>

This is type inference for Generic Instance Creation. Saves a few keystrokes without removing any type safety. Again, a nice, but very small improvement.

There are a few more language features, but I expect they will see very little use.

JVM changes

The Java virtual machine gets a new instruction: invokedynamic. Using invokedynamic, the JVM can invoke a method on an object without having to know on which class or interface the method is declared. If it walks like a duck and talks like a duck…

Invokedynamic will be very helpful for implementors of dynamic languages in the JVM, so it’s great. But the average developer will never encounter it in the wild.

Library changes

Looking at the release notes for Java 7, you may first suspect that there are some interesting library changes here. However, when examining the list more thoroughly, I couldn’t find a single change that I expect I will actually use. The library changes are mostly low-level, behind the scenes fixes of small problems.

Conclusions

So there it is: try-with-resources, multi-catch and a very limited type inference. Hopefully, Java 8 will be released as planned in late 2012 with all the stuff we’ve been waiting for. If so, I expect most shops will skip Java 7. But if Java 8 follows the pattern of delays from Java 7, these slim pickings may be all the crumbs the Java community gets for another five years.

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I have written a few words about the dojo part of the exercise in a previous blogpost. After “classical” TDD-training, I decided to try something different and gave the group a competition to play with: Extreme startup, a workshop with software created by @rchatley and @mattwynne. The workshop was a huge success and I’m hoping to repeat it soon.

In the exercise, each group creates a bare-bones web server in a programming language of their choice and register its URL with the workshop server on my computer. The workshop server then starts asking each registered web server questions over http.

In the beginning of the competition, the workshop participants don’t know anything: They don’t know what sort of questions will be asked. They don’t know how the workshop server will encode the questions. They don’t know how answers will be scored. They only know that they will get http requests to the URL they registered and they have to work out the rest.

Similarly, I don’t put any requirements on how the participants work. They can decide to work solo, in pairs or in larger groups. They can decide to use TDD or not. They can decide to use any programming language they want. They can even sabotage or spy on each other.

I decided to officially end the coding dojo before the competitive exerice. This way, people could decide how long they wanted to stay and how involved they wanted to be.

As teams start answering questions, the scoreboard on the projector starts showing some teams doing better than others. After a pretty short time, @ovegram and @idarborlaug gained an advantage that they held throughout the night. Some people used tests and some did not. Some people quit early and some kept going. @StClairJohn and @karianneberg both showed remarkable stamina and kept working after everyone else had called it a night. Eventually they gaining the lead.

Take-aways: The competitive aspects and the open format made this into an extremely successful exercise. Many of the participants were not very familiar with the web-APIs of their platform, so having @bodiltv‘s collection of starting points helped people focus on the exercise, instead of the technical details. Having a real-time problem to work on forced people to balance quality and speed. Many teams considered using TDD and some did. Some benefited a lot from their tests, some might have been hurt by them. Some teams spotted problems using their tests, while one team forgot to run all their tests and ended up having a bug in production for a long time, while they had a test that could’ve saved them if they’d only run it.

One especially enjoyable aspect of the exercise was that the participants helped out other teams quite a bit. I waited with adding more questions until everyone was ready, so the leading players were interested in helping those lagging behind. I hope that in future iterations, there will be even more cooperation between teams.

@ovegram and @idarborlaug set up their working environment to ensure that they knew what happened “in production” all the time. As they were in the lead, I convinced one of the other players to sabotage them by stopping their server while I distracted them. They detected the sabotage within one minute, due to the way they set up their IDE.

There was one question where we believed for a long time that there was no correct answer. This was actually a good opportunity to discuss the problem of choosing your battles. Some customers will never be satisfied, so trying to please them is a waste of time. Recognizing impossible questions is a good lesson from the exercise. Even if it turned out in the end that the question did have an answer.

Extreme startup experiences (mostly for Robert and Matt): The extreme startup server is very cool. The questions are good, and I’m looking to add some of my own as well. Teams who had weak skills with regular expressions were often penalized, while no other skill were as essential. To add a different aspect to the game I would very much like to see (or add) some questions that require the servers to maintain state for client sessions.

Another weakness of the exercise is the fact it’s very hard for people to catch up when someone has a big lead. One possible modification would be to add situations where a single screw-up would cost someone a huge number of points, especially if they were already in the lead. Alternatively, if each round gives 10x the points of the last round, an early advantage will not carry for long.

It was a bit difficult to set up the workshop server on a Windows machine, mainly due to Ruby gems with native extensions. The server depends on a version of the library eventmachine that doesn’t compile on Windows, so I had to upgrade this. I updated the README and Gemfile in my fork for extreme_startup to describe how also get it to work on Windows.

Extreme startup is a very fun workshop and it is quite easy to run. I will definitively run it again at future workshops. The exercise lets you put your practices to the test. Your score will not depend on whether you did do things by the book or not. If you get a good score and didn’t use TDD, that’s fine. If you got a good score and did use TDD, that’s fine, too. If you wrote beautiful code, but failed to answer the questions, you still lose.

I hope that this blogpost inspires you to seek out or organize your own extreme startup workshop!