From understanding expenses to starting a limited company, our downloadable business guides can help you.
A lot of different groups come together to produce Crunch. Our service is a collaboration between talented accountants, programmers, product owners and many others. Our clients know how our Account Managers and Accountants work – they speak to them every day. But what about the other half of the equation, the people who develop the Crunch software? We wanted to shed a bit of light on how we build, maintain and improve Crunch every day.
The development team is currently 18-strong, and most have been with the company for a long time. We’re growing fast, and have four new recruits joining us in the next few weeks. We’re all Java programmers, split into several groups, with one group focused on maintenance and the others on upcoming features.
As we work in collaboration with various different people it is important to have a dedicated, consistent team building the software – in my experience software takes on qualities of the people involved in writing and designing it. With an integrated service such as ours, where the Account Managers, Accountants and software blur together into one cohesive whole, this is especially important. Outsourcing might be cheaper on paper, it often turns out to be a false economy. Being able to work closely with people who will use the software on a day-to-day basis is a huge advantage. Our team has seen very little churn, and the system produced reflects years of hard work.
For our day-to-day development we use a process called Scrum, an agile methodology. In the old days programmers would work on a huge new feature and excitedly unveil it after months of development. Scrum means breaking a project down into two-week stages, called sprints, each of which produces a small piece of finished software. It allows everyone involved to see how the project is progressing. By constantly reviewing the work in progress, small changes to the design can be introduced at an early stage.
I’ve seen agile become gradually more popular through my career. The early projects I worked on involved massive documents describing exactly how the system would work. Detailed plans would be produced so that you could see exactly what each developer would be doing on specific days three or four months in the future. These plans would quickly unravel as assumptions turned out to be wrong. Agile reduces the amount of upfront work, allowing the project to be defined as people learn more about the problems involved. You can see a nice overview of Scrum methodology in this video –
Broadly speaking, this means we can deliver new features faster. We actively encourage clients to give us suggestions in our Feedback Forum – there are hundreds of great ideas in there and, as you can see, plenty of them are already marked as “Done.” This is because we can quickly respond to our clients’ needs and schedule work in the very near future, rather than months down the line.
The development team also does a lot of work behind the scenes that may not even be seen by Crunch clients. Things to improve internal efficiency are a big part of our work. GoLimited, for example, was initially built to streamline how we formed limited companies – it worked well so we slapped a web interface on it. There’s also a whole backend of the Crunch software that clients never even see – the interface our Account Managers and Accountants use when looking after your accounts.
We use a variety of different tools to make sure our development and maintenance is as efficient as possible. Here are a few of our favourites.
Whenever a bug is identified, or a new feature we want to build is decided upon, it is recorded in Jira. This system has a ton of useful tools, such as prioritising tasks and planning individual sprints.
It’s used by the development, design and marketing teams, and has worked so well our editorial team has even used it as the basis for their workflow.
We use git to manage the various versions of the Crunch software – the live version which all our clients use, the early version on our testing server (used to assess and finalise new features, and demo them to the rest of the team), and even newer versions being built by various developers.
We use a few different services to monitor how the various component parts of Crunch are behaving – Geckoboard monitors overall business performance, New Relic keeps an eye on the Crunch app’s responsiveness, and MONyog watches our database performance.
Jenkins looks after new additions to the Crunch code. Every time a developer adds new code, Jenkins automatically tests the new additions to ensure everything works as expected. Once Jenkins is happy the new features work, we can easily deploy them to our testing server.
We like to make sure we’re always using the best tools for the job, and we’re always looking for shiny new bits of kit.
If there are any tools you think we should check out,or if you have any questions about how we work, let us know in the comments.
We’re playing host a ProductTank Brighton meetup, in which three experienced speakers will be sharing experiences & wisdom about what can be missed.
Having a common language the whole team uses is essential. SGDD makes it easy to explain the way we work to each other & those outside of Crunch.
At Crunch, we're creating a computing platform for our services. Find out how we're using AWS Auto Scaling groups to ensure they’re always available.