Move fast and break things or slow as you go?

Should a new team focus on moving as fast as possible to get features out to their customers or start with the best practices and processes they know they’ll eventually need? Is it better to move fast and learn from users through a short feedback loop? If so, is a team doomed to suffer poor architectural decisions and accumulate massive tech debt until eventually someone decides to stop features and blow up the system?

While there can’t be a single answer that fits everyone, I feel that most teams are actually better suited by moving slightly slower and establishing the right processes from the get go. OF course teams that are on tight strings and need to launch to get funding or collect users should focus on iterating quickly, but even in the short to midterm, I’d argue that building with the right process and quality can actually allow these teams to move faster anyway. Starting out with high quality around development, build, test, and release processes can help teams reduce feedback cycles anyway, so all teams should focus on this early on.

The cost of not starting out with best practices around continuous integration, delivery, and deployments surfaces through slower releases as well as with costly rewrites and changes that need to come later. While it can be easy to focus on getting things done quickly and ignoring these processes because they can come later, in practice, these teams end up having to spend far more time cleaning up poor architecture and implementing these best practices later on, after systems are already in place, in order to succeed long term. The sunk cost of delaying these processes continues to build up over time making it even more costly to implement later.

The initial reaction to what can be perceived as red tape is that it will slow teams down as they have to clear hurdles like implementing test automation and deployment pipelines. However, managed systems like AWS Code Pipeline and Code Deploy make the infrastructure for this trivial, and actually much easier to build from the outset rather than shoehorning in existing code later on. Even if building from scratch for an incredibly custom application, taking a test driven approach has a multitude of benefits including better understanding and clarity around requirements and design. Developing tests first helps ensure the team actually understands what they are building and why, and can also help parallelize development so that teams can be more efficient.

Continuous deployments also help new teams as it can help get them in the mode of ensuring all developed software is ready to launch. It also ensures code is integrated early and often, reducing the number of errors and finding them earlier when it is least costly to fix them. A lot of new teams build bad habits of committing broken code or code known to be incomplete when they know they can fix it before releasing. With an established CD process, teams are forced to deliver small, iterative, and complete discrete changes. These changes tend to be less buggy due to the reduced complexity, and also allow launching to customers more frequently, meaning teams can get feedback more often and faster.

Even concepts that are more modern or seem advanced like infrastructure as code have value to new teams. While writing a template to automate the topology of an application may take considerably longer than just setting it up manually the first time, the repeatability and automation that can come with this will save teams tremendous time and issues very quickly and return the investment. Teams that can automatically create mirrored development environments from production are able to develop and test much faster and can get features out to users quicker as a result. IF things go wrong and they accidentally blow up the production environment, as I’ve seen firsthand with new teams, the environment can be easily recreated, mitigating a potentially devastating loss of infrastructure and potentially data.

Not every team will magically benefit from these processes. The processes will help overall quality and speed, but without the culture of insisting on high standards and prioritization of quality paired with speed, rather than just raw speed alone, teams will still suffer. Adding processes on top of these teams will just slow them down, add layers, and still not actually improve their quality or speed, effectively putting them at a huge disadvantage. Teams need to actually embrace these processes and realize the benefit each provides in order to ensure they are actually realizing that benefit.

It can be very hard for new teams to decide on an approach as they form. External pressure to deliver quickly and go as fast as possible is strong and compelling. In some cases, the need to quickly capture the market or secure funding is strong enough that teams need to focus entirely on speed of delivery, and may need to make sacrifices in order to meet these demands. However, even in these cases, teams should very carefully weigh each of these decisions because each little choice to go for speed over setting a best practice is likely to sacrifice long term speed for short term gains. If teams can buy some time, they may be much better off taking some time early on to invest in automation and processes because they will quickly recover that investment through productivity gains.

Managers of new teams should also consider the educational benefit to the team when considering how quickly to move and how much to automate. Team members who start off early with process practices tend to cultivate and grow these further in the team, both with new ideas and by spreading the knowledge to other team members. In this way, high standards become self-propagating and the team will continue to get stronger, more reliable, and faster. Senior engineers will teach junior ones how to automate tests and pipelines, and both will bring additional ideas such as running automated canary deployments, automating rollbacks, or other techniques that will allow even stronger development.

For new teams, the pressure to move quickly is all too real. It’s so easy early on to allow flexibility in the development process and bias toward moving fast over putting processes and practices in place. However, done properly, these processes can be less limiting and more empowering for the team to learn, develop faster, and find new opportunities for improvement. Teams may slow initially as they invest in these tools, but the multitude of prepackaged systems for many of these will require less effort and will quickly turn around speed and iteration improvements. While new teams may feel they can afford to wait and establish best practices later, the most effective new teams actually start with these and build quickly on top of them.