We build great software, and this is how we do it.
<1> communicate and collaborate
It’s a sad truth that our industry is littered with hackers who are great at coding, but who can’t talk like humans. Most software companies hire them anyway, then hire a layer of middle management to act as a liaison between client and developer. We think it’s a lot more efficient just to hire good communicators. Everyone on our team can elucidate ideas quickly, cheerfully and effectively, whether through spoken or written words. This means that whenever you’re talking with one of us—any of us—it’s going to be a pleasant, collaborative experience.
Before we start building a new feature for your project, we will make sure we fully understand the business value you are trying to achieve, and then we’ll make sure that the proposed course of action is going to deliver the best solution. If we think of a better way to do it, we’ll suggest it.
<2> Write tests, then write the code
It sounds backwards, but the right way to build software is not to build the actual software first. It’s to write tests for the software. A test is something simple, like this: “If a user isn’t logged in to her email account, then she shouldn’t be able to see her inbox.” It sounds boneheaded, but it’s an amazing safety net that ensures your application is going to behave the way you expect it to, indefinitely.
It’s the industry best practice to write tests first, ensure that they’re failing, then write code to make the tests pass. Most Rails developers know they should be doing it. But most of them don’t take the time, and it shows in their bug trackers post-launch.
<3> Peer review
Lots of software development shops espouse the idea of pair programming, where two developers sit at the same computer and work on the same problem together. While we certainly see the benefits of this approach and occasionally use it, we feel like it’s not an effective tool for most situations. Two developers come at twice the price, after all. On the other hand, a lone developer toiling singly in a corner is prone to making mistakes, taking shortcuts, and letting things slide. While that might be more cost-effective in the short run, in the long term it leads to inefficiencies that are just going to need correcting at a later time. Still costly.
Our solution to this problem is what we call peer review. For every development project that comes through our doors, we assign at least two developers and one designer. The lead developer writes the majority of the tests and the code; every morning, the support developer reviews the previous day’s work, making sure it matches the client’s expectations and that the quality remains high. When needed, the designer also swoops in to make sure everything receives the perfect 12 Spokes polish. It’s a collaborative process that ensures you get the best product without the biggest investment.
We like to release early and often. When we have finished a feature that adds business value to your application, that’s when we recommend releasing. The sooner you can get your new functionality in front of real users, the better you’ll know what you need to do next—and we’ll be happy to help you determine what that is!