Over the past few weeks, the team have been settling into our shiny new Go Tripod offices in Truro, Cornwall in the UK, and we wanted to take the opportunity to tell you why we’re so excited about our move, what we’re doing in Cornwall, and where we go from here.

The State of the Art

We’ve combined working remotely at opposite ends of the UK, and we’ll continue to do so. But a working environment where we can really put our heads together and crack the important nuts became crucial, and so we’ve taken out some office space in Truro (if you ever visit, come see us. And the Cathedral, it’s beautiful). We’re using the office as a base, but not as a place we’re tied to – forcing a 9-5 isn’t going to get more work done.

Our clients remain our most important asset, and we’re continuing to work very closely with existing customers as well as opening relationships with some exciting new partners (watch this space!). That said, we’re expanding development and promotion of our products like Stubmatic, as well as beginning to push new ideas like InStock – a simple stock control system. This seemingly two-pronged approach made us realise something fundamental about our business.

Products for Everyone

We make Stubmatic and InStock for ourselves. And for our clients, we make software and websites. But actually what we make for most people is products of their own – a system that they sell on to their clients to increase revenue. It’s not Go Tripod products plus client work – it’s Products for Everyone! Our potential clients come to us for a piece of software, and we help them understand how that software can be used and reused in way that’ll make their life easier, and make them money in the process.

Cornwall’s an exciting place to be at the moment, lots of activity in our sector and a growing university in Falmouth means that groups such as The Hub and Cornwall Social Media Cafe are attracting loads of interesting folks.

Myself, Jon, Simon and the rest of the Go Tripod family are really excited to be a part of it!

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.

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.