In startups, words like agility and rapid development are thrown around a lot. It’s an expectation. It’s the reason startups are meant to succeed over sluggish big corporates. By the time some large company has had their 20th committee meeting to decide on whether the idea has merit, there is a startup somewhere that has already built the idea.

What’s not talked about as much is the cost of rapid development – speed now, accuracy later. At some point, later is going to sneak up on you and often those problems are exacerbated because shortcuts have been taken, there has been less iteration on your existing codebase and you keep tacking on to get the features out, fast. Left alone, this leads to an entangled codebase that becomes increasingly hard to work with and stability becomes a battle of it’s own (even with well written tests).

At Local Measure, we use scrum to manage our development cycles. We work in two week product development sprints. However, between each product sprint, we do a one week technical maintenance sprint – only work that directly improves the codebase can go in the sprint. It’s up to all the engineers to nominate what needs improvement or refactoring, and… strictly no product features! This isn’t a silver bullet to a healthy codebase by any means, you still need talented engineers, solid architecture and robust tests but this does help to balance the pitfalls that can come with rapid development.