This is a “from the development trenches” post from Kashoo software engineer, Christopher Luft. If you enjoy posts like these, let us know by Liking it and we’ll do them more often! The tricky thing about developing software is that most of the time you’re trying to make something that has never been made before. Software is not like traditional engineering where we more often than not know what the end product will look like. Sure, there are parallel examples to draw on (other software builds), but for the most part, building software is evolutionary: keeping things up to date with the latest operating system, dealing with scalability issues as your user base grows, taking advantage of new platform capabilities as they emerge, etc. And this complexity is compounded by the fact that the tools we use are also in a constant state of flux. All of these unknowns, combined with the solitary nature of working at a computer, can sometimes make software development a cold and lonely place—spending so much time alone on the frontier has proven too much for many an explorer. In order to surmount these problems, the developers here at Kashoo have started looking at new ways to foster collaboration. Our ability to communicate with a limitless number of experts and people that share our interests is one of the many great wonders of our time. But even with this capability, software builds from scratch like the one we’re about to discuss require something more than Googling when a problem is encountered. When tackling the Attachments feature we took a different approach towards collaboration and used a technique called swarming. The basic idea behind swarming is that the whole development team focuses their eyes (and brains) on a single feature and works in parallel as a single unit towards the goal. We started the swarming process for Attachments with a week-long planning session. During these sessions we used a series of techniques to narrow down the scope of what we intended to build with the goal of understanding what our Minimal Viable Product (MVP) looked like. For the initiated, you will know that feature creep is one of the most common causes of software delays and the core of this design process was to figure out the most important aspects of what it is we wanted to build and deliver exactly that—without getting distracted by all of the bells and whistles. And because we are a small team designed to move fast, spending a whole week focused on planning alone initially seemed excessive (at least to me); however, as General Patton once said, “An ounce of sweat will save a litre of blood.” With planning completed we divided the work amongst the team in a way that matched requirements with individual areas of specialty and expertise. We then started the process of building the feature from the same physical location. That part about same location is important. At Kashoo, we embrace a workstyle that blends remote and in-office. Working remote is great for a number of reasons, but for focused builds like Attachments, having the team in a singular location is worth its weight in gold. When you get stuck or have a question, it’s simply a matter of turning to the person next to you and asking them for help. (This may seem elementary, but ask any developer and they’ll tell you the same.) Even if that person doesn’t have an answer for you, they do have an extra set of eyes. And as you both look at the problem the answer often reveals itself. In fact, there’s a software engineering technique called rubber-ducking* that I am very fond of. The idea is that by simply vocalizing the problem, the answer will reveal itself. This is often seen in action by accident when you go to ask somebody a question and, in the process, the answer strikes you. The theory behind this is that we use different neural pathways to speak (compared to internal thought). Thus vocalizing your problem stimulates new connections in the brain which can lead to a solution. (Science for the win!) But back to how we built Attachments… With all of the planning complete using a sound and collaborative approach, the initial work went very quickly. Everybody had a good sense of what their job was and happily built it out. And as we got closer to each of our goals, we began the process of integrating a cohesive system. Things got a little tougher at this point (as all integrations go), but because we maintained such a collaborative unit, everybody had a good idea of what the other was building and it was often just a matter of having a conversation or walking over to the whiteboard to work through whatever problems we encountered. In the end we delivered a very valuable feature for our customers in a very short period of time. (Because that’s what it’s all about!) And the best part is that this exercise brought the whole team closer together and nobody had to spend any time alone on an ice float. That in turn fosters trust and reliability—two characteristics that are critical to software engineering. If you would like to learn more about swarming you can do some reading here, here or here. *The concept of “rubber ducking” comes from a book called the Pragmatic Programmer which describes a software developer who keeps a rubber ducky on his desk that he can talk to when stuck on a problem.
