Nifty R&D is a service launched by PwC that helps small businesses access research and development tax refunds using a web-based review process.
In the final part of our series on Nifty R&D, back-end developer Tom Broomfield looks at the technology and the build principles behind this online offering.
Working in the Nifty R&D development team, our major balancing act is the battle between quality of code, speed of delivery and the number of features requested by the business and our users.
The adage goes:
- Good and cheap won’t be fast,
- fast and good won’t be cheap,
- cheap and fast won’t be good.
To achieve a balance of all three, we have four key principles that guide how we build Nifty R&D:
Use open source
The more people that have been exposed to the source code, the less bugs that code will probably have.
As a foundation for the application, our team chose Ruby on Rails – an open source web framework that is actively maintained, meaning any security issues are addressed quickly.
Rails is also used widely, meaning that almost any issue encountered throughout the development process has already been solved elsewhere.
Its community of developers maintain open source plugins that can be included in order to implement complex functionality. This is pivotal in releasing features quickly – no need to waste time reinventing the wheel. It also frees the Nifty R&D team up to develop a unique application that is comprised of stable, mature and thoroughly tested code.
We leverage this system to produce our own plugins that can be shared among internal projects. This allows us to be more productive when launching a new project, as much of the groundwork has already been done.
Make frequent, small code changes
In a previous article on the operational processes behind Nifty R&D, we talked about regularly releasing new code for the application.
In development language, a ‘pull request’ is when a developer wishes to merge new code into the application. This could be for a new feature, a bug fix or code cleanup. It is absolutely essential that these are as small as possible.
There are a few reasons for this. Firstly, small pull requests allow code review by other developers to be simple and painless. It is easy to see what has changed and why. This gives the team more eyes on every line of code before it goes live, reducing the chance of introducing a bug.
Secondly, if a bug is introduced it allows us to narrow down, to a very small fragment of code, the point at which that happened, allowing the debug process to be fast and efficient.
Team morale also benefits from small pull requests, as they allow us to maintain consistent momentum. As developers we love to see the fruits of our labour in output on the site itself.
Between the two developers on Nifty R&D, we generally have around 50 unique pull requests a week.
Automate the testing
The frequency in which we update code in the project could introduce bugs or break existing features. We prevent this with a rigorous feature testing suite that safeguards the functionality of the application.
Feature tests are small snippets of code that mimic the actions of a user and measure the result. For instance, we may write a feature test to check that when a user inputs their email and password, they would sign in successfully. The test would then fail if we wrote code that impaired that process.
Nifty R&D has over 650 individual feature tests that ensure every element of our application functions as intended. We write an accompanying test for every new feature to ensure that future changes do not cause anything to break unexpectedly.
We run the entire test suite regularly, ensuring that bugs are caught early in the process. This allows us to deploy a new version of the app multiple times a day with confidence.
Enjoy the process
While building Nifty R&D, we place a priority on making it an enjoyable experience for all the team.
This can be as simple as keeping the code clean and maintainable, keeping tasks small and manageable and ensuring that nobody gets stuck in a particular part of the system for too long.
We have some light gamification around our development cycle and compete on various productivity metrics.
For example, we’ve built our own software that works with various gadgets around the office. When we send code live, we push a ‘big red button’. We’ve also developed an application that remotely controls a toy missile launcher, which we use whenever there is information to share with the whole team. Both of these gadgets allow for a fairly unique internal notification system!
Striking the right balance between good, fast and cheap is always a challenge, but by following best practice, writing good code and being innovative along the way – you can also make it less difficult and more fun.