As developers, when building new projects from the ground up, we have a tendency to shoot first and ask questions later. Facebook popularized this attitude with their old motto, "Move Fast and Break Things," and it's a notion that seems to have been firmly embedded into startup culture. Unfortunately what often happens is that once things get broken, we fix them with Band-Aids and duct tape in order to keep up the fast pace we've established. While we often put a premium on the end result, the foundation we build to achieve that result is just as important. For every line of hacky code we write, even if it does what it's supposed to, we are compounding the amount of work that future developers on a project will have to do when you feel your company is finally in a place to "do it right." In the face of legacy code, we will always be pushed to compromise quality for speed, but it is important to communicate the true impact code debt has on the future of a project. Eventually, Facebook learned this lesson, changing their motto last year to "Move Fast with Stable Infra(structure)." By putting an emphasis on stability, Facebook essentially enacted a speed limit on development to encourage bug-free code. So, how do we balance speed and quality? The answer, unsurprisingly, is by establishing a set of rules and processes for you and your team to follow. Before beginning any work on a new application, it is important to lay the proper groundwork. This is the time to set up your deployment processes, version control management workflow, and unit test frameworks. In addition, you should be using this time to build out your code style guide and plan your application architecture. Over time, a well thought-out development process can provide exponential benefits; the most important of which is reduction of the time it takes to onboard new developers. I am a big proponent of utilizing strongly supported third-party resources for this exact reason. A new developer is going to be productive far earlier when he or she is confronted with an established deployment workflow, a well-documented development architecture, and commonly utilized third-party resources. Don't believe me? Then ask yourself which new developer is going to be better set up for success: The one working with an architecture that is built 100% in-house, or the one working with a system built on top of established frameworks like CodeIgniter, Bootstrap, and AngularJS? This sparks a whole different conversation about when to use frameworks and when to start from scratch, but the same underlying principle of productivity and reliability applies. The more decisions you can make up front to normalize your development processes, the lower the chance you have of dealing with code debt in the future. While enacting a proper set of guidelines will limit your development speed a little bit, it will greatly reduce the amount of bad code that gets put into production, and limit the code debt you will have to deal with in the future. Additionally, the more forethought you put into planning the future of your workflows, the more confident and successful every member of your team will be, which will not only reduce the time it takes to onboard a new developer, but also provide more stability and balance to both the codebase, and your working hours.
Zachary Flower (@zachflower) is a freelance web developer, writer, and polymath. He has an eye for simplicity and usability, and strives to build products with both the end user, and business goals, in mind. Zach takes a strong stand against needlessly reinventing the wheel, often advocating for well established third-party services and solutions to improve the efficiency and reliability of a development project.
