Part 2 post on the practises we used to get the site out in under 4 weeks. Read Part 1 here.
Reuse as much as you can
We’ve developed our application using Rails and tools from the Ruby community. When we needed to process our feeds, we chose to use Superfeedr so that we can quickly to concentrate our time on what’s going to make our product better for users to read information on the web.
Instead of writing my own CSS, I reviewed a couple of CSS kits that came with simple styles and a good grid. Eventually settling on using Foundation CSS, so that the site looked presentable enough to use and so that I could concentrate on what mattered, the reader content page.
We didn’t practise a full agile process, but we made sure we wrote stories, reviewed and prioritized them. I made sure we spent time asking the “why” on what was being implemented, giving us a pause to review the scope of a story.
We made sure stories were small enough to deliver in under a day, otherwise to break them up so we could better manage and prioritize.
There was no concept of an iteration because of our short time frame and our juggled time involvement but we made sure to do a weekly review and theme the week ahead.
Zero Bug Policy
Something I have practised with my colleagues at GoFreeRange and was first told to us from Ben Griffiths. If there was a bug, we put it at the top of the backlog and fixed it quickly. So we made sure to not backfill the backlog with bugs.
I’ve found this encourages you to not bother with bugs that are small, you accept them as limitations with the current product, you’ll improve it as you go, only when a bug is important (a showstopper) you’ll add it and fix it. Keeping the focus on delivering features and improvements that matter and not bogging yourself down on things you just haven’t had the time to sort out.
A big debate with developers in startup mode is how much testing to do on your application. What I did with RSS Hero was:
- Use outside in testing with Cucumber for all areas of the app, made sure the user experience is tested.
- Added testing for complex areas of the site, so the queue, importing/parsing of articles, teleport test cases, testing of the feed checking, etc.
- Left areas untested that were common, like “an error should be displayed when I send no parameters to the login page” but when these relaxed areas caused an error I’ve added tests.
Some people say “Why bother adding tests? Everything is changing all the time, why waste time”, this itself is a damn good reason to write tests, “everything is changing”, make sure some feature you implemented on day 1 still work when it changes further on, don’t let your users see that error and have it publicly tweeted out.
I’m not saying that our app has no bugs because we’re writing tests, but that we are working hard to keep the quality and experience consistent, it will only get better not worse.
For most developers this is a no brainer, but spending time on continuos deployment was important. I made sure that I could run one command and it would update everything on the server and restart any background processors.
This allowed us to quickly try new things, fix issues and quickly get feedback.