Our Blog

How We Track Projects

13 February 2010 10:10, Posted by Colin

Depending on time of year, current workload, phase of moon, and other factors, the Go Tripod team may not always work from the same location. And even if we do, we’re often in Do Not Disturb mode with headphones on. We’ve found that the best way to keep track is by using the Campfire chat system, which allows not only standard back-and-forth yapping, but sharing of source code and images. A killer feature for us is the ability to see what’s been talked about if we’ve not been in the chatroom for a few hours; Campfire offers transcripts of everything that’s been said in your absence.

So we’re always in Campfire, and it’s an integrated part of our working day. As Go Tripod is going from strength to strength, we’ve started to need a way of doing a similar thing with projects – a very simple way for anyone to see and overview of projects that are on the go right now. We’ve kind of tried this before, but the stuff that we’ve tried either hasn’t been simple enough or we’ve only used it rarely because it’s separated out from every other part of our work. In the latter case, it just gets left by the wayside and forgotten.

The idea sprang to mind to somehow involve Campfire in the proceedings. Maybe we change the room title to reflect the current open projects? The problem with the room title is that it’s a bit out of the way up the top of the screen and could be affected by the same issue as I described above – out of sight, out of mind. So the solution needed to be integrated. In fact we basically needed another team member in Campfire, our communication method of choice, talking to us and updating us. Some kind of automated team member… Some kind of robot?

The Technical Bit

I did a quick search – Tim Riley’s Campfire Bot looked absolutely perfect, with its plugin system, so I tried to use that. Unfortunately I couldn’t get the latest source code to work, and I had other issues when I tried to use the Tinder library which underlies the Campfire Bot.

A quick scout around for some more libraries led me to Broach, a simple wrapper for the Campfire API, and the 37 Signals example code for the Campfire Streaming API, which uses the twitter-stream library. I quickly put together a proof of concept using these tools and some sneaky code which allowed us to issue commands to the bot from the Campfire window itself.

The Results

A picture tells a thousand words:

A list of current projects! And Simon decides to add another:

GoTripodBot is a helpful fellow:

And a brief insight into the world of development (I wrote some unit tests after this):

Conclusion

Of course there’s a lot more to our project management process than this (and a lot more projects to manage than I’ve shown!) but having such easy transparency into this top layer of our work is really going to improve our awareness of what’s happening right now in the world of Go Tripod.

---

Problem Solving in Software

30 October 2009 14:03, Posted by Colin

Very occasionally, people will start asking me in detail what I do for a living. When “I write software” or “I make websites” doesn’t satisfy them, I go into a bit more detail about the different aspects of my job. One thing that happens quite regularly if I don’t go into enough detail, is that I’ll tell someone how long it took to write something, or how much it cost, and they’ll raise their eyebrows.

“How can it cost so much?! It’s just a website!”

I can see their point. Most websites contain common elements – login, lists, articles, shopping carts, and so on – so you’d think that once you’ve written one, you’ll have the bits and pieces you need to make more. And taken individually, each of these parts are fairly straightforward – a list of products contains some pretty basic HTML, surely? And HTML is just a text file?

And again, that’s a fair point. The real time isn’t taken in writing these bits and pieces, it’s taken in understanding how the customer wants them to be written and how they need to fit together in a certain situation. For example, a shopping cart quickly becomes more complex when the customer adds on a few more features:

• Integrates with Google Checkout
• Customers can save carts for later ordering
• Customers can reload past orders into a few cart

But it’s not just the cart, it’s viewing products too – what if certain customers see custom trade prices? Or products can be assigned to multiple categories and the customer wants to see how many products are in each category next to the category name? All of these things are minor when taking in isolation, but together they are a thousand tiny cuts which bleed development time.

As well as a collection of features, a specification for a website will also discuss requirements in language which is specific to the company you’re quoting for. Rather than “cart” you might have “basket”. Or you could have “assessors”, “reviewers”, “investigators”, or any other number of terms which a company uses internally and when referencing all of the features they want on their site. Eric Evans talks about the “domain” of a problem when discussing software – not only do you have to appreciate what kind of features are necessary but you have to understand the domain in which they’re going to be used, in order to create a solution which fits together correctly.

So software is a whole big bag of questions and clarifications and solutions. From a developer’s point of view, it’s not just a case of taking some standard components and piecing them together – though that does happen occasionally. Instead every step of the development process is about solving problems, by understanding what the customer wants and by understanding the problem domain. Every day of development sees a developer tackle a new bit of work that needs resolving in a novel way, and that’s why making software isn’t just a case of shoving some parts together and hoping that it works, but a process, an evolution of the initial ideas.

When clients come to us and ask for software, they’ll pitch it by saying “make us a website”. But we know that what they really mean is “look, understand, and solve our problem”. And that’s what we do.

---