Swarming

January 6th, 2019

When I used to be a freelance front-end developer, I remember working on a campaign site with a team of four developers. It was supposed to have an interactive 360 degree viewer up top that allowed the user to explore a set of rooms with hotspots and the like. One developer had quite a bit of experience with that sort of thing. That is why we split up: he would build the interactive thing and the three of us would build the rest of the site.

If you want to go fast, go alone. If you want to go far, go together.

African Proverb

After three weeks of development we approached the deadline and – of course – the ”interactive developer” got really sick and couldn’t finish the component that still had major issues.

Finally we came to the conclusion that we had to join forces as a team to meet the deadline. We locked us up in a room for three days rewrote the whole thing and finished it in time and in much better quality.

Why? Was the interactive developer a bad developer? Certainly not. But:

  • He had nobody to talk to. Whenever he got stuck, he didn’t really have anybody to help out and share ideas.
  • Nobody reviewed his code, so there was no quality check.
  • He had to do everything on his own. So there was no efficiency advantage.

From that day on we worked together (swarmed) on everything. It first seems to be much faster to work on multiple features in parallel when it really isn’t. What did we gain from swarming?

  • Less code ownership — more developers knew the code in and out. The team was able to compensate if a developer couldn’t make it to work.
  • Better quality — working together, sharing ideas and reviewing the code resulted in a much better output.
  • Efficiency — sharing the work load for a task makes things much faster. Whenever somebody gets stuck, there is someone else who already knows what the person is working on and can help out.
  • Happiness — being part of a real team is a lot of fun and increased efficiency prevents you from working on things endlessly without any feedback.

I’ve seen this pattern in a lot of places — it feels faster to parallelize, but it really isn’t.

Do you agree?

comments powered by Disqus