The Deeplocal Development Process

November 13th, 2009 by matthew

DSC_0133First off, a little background.  This may have been mentioned before, but each week here at Deeplocal, a different person is responsible for washing the dishes.  The same person is also responsible for writing a blog post. While I consider myself to be a pretty accomplished dishwasher, this is my first foray into the exciting world of blogging so we’ll see how it goes.
 
This week I added some functionality to our RouteShout product so I thought I’d use that to talk a bit about how our development process works at Deeplocal.  The new functionality had been requested by a customer several weeks ago and we had been discussing the idea. A few days ago, we decided to go ahead and implement the new feature.  The team got together for abut 30 minutes and talked about the core functionality of the new feature, how it should work, and potential problems; then, I was off.  No functional spec document, no formal kickoff, just 30 minutes in front of a whiteboard.
 
As an aside, the functionality that the customer originally requested was very complicated.  We spent some of our whiteboard time distilling the feature to its core requirements and stripping away what we thought was extraneous.  This is a big part of our process, identifying the true end goal and focusing on it.
 
With that, I started working on the code. After about three days, with some help from Dimitry, we had the feature working on our development server.  So functionally, it was working-  but it wasn’t pretty.  That’s where Nathan and Eamae stepped in.  The new feature involves users subscribing to various transit alerts and the sign-up process was confusing.  All of the requirements were there, but something just wasn’t right.  Again, after about 30 minutes at the whiteboard, Nathan and Eamae had quickly gone through two iterations of the UI and they came up with a much better solution.  Eamae summed everything up for me with a couple of sketches and the ball was back in my court to make it happen.
 
Now, less than five days after we decided to move forward with the new feature, it’s being pushed out to our production servers. Is it perfect? Will it never need to be changed at all?  No, in all likelihood we will get suggestions from our customers or we’ll want to make tweaks on our own.  But, the important part is that the feature is out there, it works, and customers can use it. If necessary, we can make iterative improvements as we go along, but we’d rather get something usable out there instead of spending weeks making theoretical changes to it.
 
I’m not saying that lots of planning and spec documents are a waste of time or unnecessary. For some projects with large teams and scopes they’re essential to keep everyone working together. But with our small, smart team, spec changes are usually done by pushing your chair out from your desk and telling the rest of the team what you’re planning to do. If no major objections come back, you have approval. Changes to the design come when Nathan walks by and puts a printout on your desk. That’s how we do things and it works well for us. When you have a team that’s competent and confident in each other, you can be flexible, make quick changes, and “get things done” Most other companies would still be writing up specs.

  • nathanmartin
    From the bosses point of view:
    This process we use only works when you have a team of people like we have here that are passionate about doing great work. Because everyone is constantly thinking while doing, I don't need to manage tasks like the one Matthew describes. I get to focus on the larger company initiatives. Many small companies I have observed tend to look at a process such as our as chaotic and instead decide to mimic the structure, process, and hierarchies imposed by much larger companies that they hope to one day be. I say, as long as we have such an amazing team here, I should take advantage of the competitive advantage that creates for us little guys. I don't need to manage tasks, I trust that everyone here is working for greatness and not simply for a paycheck. Matthew touches on it here, but it deserves to be reiterated. Our self-driven process works because everyone here is awesome at what they do.
blog comments powered by Disqus