Development: Move Fast and Break Things, But At What Cost?
The Situation At Hand
Almost all developers have worked under the “move fast and break things” mentality at some point. This mentality pushes the idea that new features in the application might not be perfect, but creation speed is key, even if there are some missteps along the way. But this mindset can be dangerous to a project. A team is hastily thrown together, and the race to build a minimal viable product begins. Engineers immediately start building a solution without concrete designs, and product owners begin setting deliverable expectations for the non-existent application. But at what cost?
The Problems Ahead
Hurrying to get a prototype out the door can lead to incomprehensible mistakes later down the line when the product aims to become more mature. I worked on a project that felt growing pains after running like a start-up. When the product reached a point in time that it was ready to grow its audience and feature set to an enterprise-level there were three blockers in the way: the architecture was not built to scale, the code was tightly coupled and there was little to no testing. This led to a division between product owners and the engineering team. The product owners wanted more features, that had visible results for the end users, as fast as possible. However, the engineering team wanted to address problems the end user would never see but would support the app’s stability and overall health.
Blue Pill or Red Pill?
For fans of The Matrix, what choice would you make?
Option 1 — The Blue Pill: Your team moves fast, breaking things and fixing the issues as they go, and the beginning of a product is shipped out with unmatched speed. The team started off with inefficient technical design, non-optimized code, and insufficient testing, but still delivered a version of the product owner’s dream at a speed that leaves little room for complaints. But the victories of the team may be short-lived as they deal with stability issues as further changes are required and re-work becomes a lot harder (if not impossible).
Option 2 — The Red Pill: Your team takes the time to iron out a solid technical design and delivers high code quality based on standards agreed upon by the team themselves (e.g. no ToDo’s left in the code, descriptive naming, single-purpose methods, etc.). The diligence of the team is rewarded with increased app stability and decreased level-of-effort when implementing new features due to de-coupled nature of the code. However, there is more upfront effort in prioritizing the feature work/tech debt each sprint, and accounting for the testing effort of each item.
Each choice comes with pros and cons depending on short-term and long-term goals of the product. The choices presented align with Martin Fowler’s Design Stamina Hypothesis. The Design Stamina Hypothesis, shown in the graph below, boils down to this: good software design quickly pays for itself through faster, better, and cheaper software development in the long run.
In the end, the choice is yours. Do you go for long-term success and prosperity, or shoot for quick short-term success in hopes to gain the interest of the market?
