David van Leeuwen

New Basecamp announcement

Basecamp Next. Will this improve our workflow instead of sprint.ly?

Hippy development

The last few weeks, our team is having trouble working in sprints. It just doesn’t really work for us. There are probably a bunch of reasons why we’re doing it wrong. I guess we like to work in our own tempo, with our own priorities. Sure, you can plan this into a sprint, but it’s just to darn focussed on getting all your tasks into that sprint, instead of making a good product. I’ve noticed that other people are having the same problem and are making a statement: Programming, motherfucker. Still, we like the retrospective and daily standups from the SCRUM methodology, so we’re going to keep that and think of something else…

We came up with the following basic guidelines, that are important to us:



Let’s say you want to add a feature to your product. Most of the time, you start by thinking what you want to build for your customer and draw some sketches. Then the team starts designing stuff and building it. We wanted to create an environment, were everyone (designer or developer) is able to create and deploy. It’s better to ask for forgiveness than permission, right? Let people create and make teams, so they can come up with stuff you never have thought about. To keep stuff manageable, we like to use Github. People create branches when they want something different. They discuss about your product and it capabilities.

A developer starts a cool new feature, then a designer posts some mockups, a copywriter does the copy, you do a pull request, there is some testing involved, and Hubot deploy’s it to production (or other groups of servers). There are no rules. It’s one team, with a vision. There is nobody bothering you if you’re doing your job and telling you what you should create.



We really like to discuss about our product. We talk about it a lot and always find a good solution to solve hard problems. We have about 8 people working on our product, but also doing some client work, because we’re a bootstrapped company. There is so much going on at the office, it’s sometimes hard to keep things focussed. We need to find a solution, where we can have some sort of distraction, but still get things done. That’s why we like people to have freedom to choose whatever they want to do for the product, to make it better. Having the daily standups and retrospective, will improve us to keep things focussed in general. And by having the ability to tackle the problem you want to solve, you’re more determined. Building something to convince others you solved the problem, is most likely the best way.



We make sure that our product (the real code) is accessible and understandable for everyone. Using Github and pull request’s enable you to share screenshots, comments and of course code commits. When you want to merge a feature, you can. When you want to deploy a feature, you can. It’s all about having control and knowing you can create everything you want.

What’s next?
Yes, we like Github. But it’s not the holy grail. We still need a place to write our ideas down, that we don’t want to work on right away. We still need a place where we can place to-do’s. But having a tool for everything, doesn’t make any sense.

We are currently trying out Sprint.ly and figuring out if this is the right tool for the job.

Hubot gets things done

I love bots. They make me laugh, work more efficient or just point me in the right direction. I remember Fishbot on Quakenet (IRC), an awesome bot that just joined a conversation. And Siri on iOS 5 is a good example. She’s not perfect, but it will eventually make me work in another way then just typing things down.

Github recently released a Campfire bot: Hubot.

It’s not just another bot, Hubot is an open-source project with a lot of scripts, built on top of NodeJS and written in CoffeeScript. Github uses it for a lot of things apparently, it looks cool right?

We are using it for fun, but also improving our work environment. We like to use Spotify at the office and are all adding songs to one playlist, that is playing on a Mac mini, hooked up to a stereo. But the annoying thing is that you have to walk over to the Mac mini or do some remote things (e.g. share screen). So I’ve built a simple Hubot script that allows you to control Spotify. Check out Hubot-Spotify.

Just follow the instructions on Github and you’re done. We are running it on that Mac mini with Forever. Like so:

forever start -l forever.log -o out.log -e err.log -c coffee bin/hubot -a campfire -n Hubot

It’s not rocket science, but it does the job. Even better: deploying via Hubot is really a good thing. We all use Campfire to communicate, but deploying is done by one developer (using Capistrano and Github). We are currently working on a deployment script, that is similar to the what Github does. We like the idea that you can deploy often, and it doesn’t matter of you’re a developer that improved a feature or a designer that changed some text or a few lines of CSS. We want everyone to deploy whenever they want. This will be our Hubot’s next step.