Doings Things Right vs Doing Things Fast in Software Development
In software development, there is a natural struggle between doing things carefully and right and doing things efficiently and fast. There are advantages and disadvantages to both ends of the spectrum.
Healthy software development teams contain a mix of talent on both ends of that spectrum. Healthy teams acknowledge the need for both types of approaches and have mutual respect for each other.
In practice, most new features should begin with fast developers. Prove features swiftly and fail fast if the features do not pan out. Once a feature is developed, roll it out in nightly or beta releases. Then as it takes hold, transition it to other more careful developers for re-factoring and further improvement.
Initially, this approach seems inefficient. Why do you need two separate teams working on the same piece of code? Wouldn’t it be better to have a single developer be the end-to-end steward for each feature? The answer to this question includes the following:
- Different developers are wired differently. Some are slow and careful. Others are fast and cut corners. You need both types and cannot find them repeatably in a single individual. Individuals that attempt to be both often struggle to find their zen.
- Forcing handoff of code from one individual to another ensures more maintainability of your codebase. It mitigates the risks of developers leaving the startup and taking institutional knowledge with them.
- Including the slow and careful maintainers in each feature’s architecture plans can ensure that the fast developers lay a solid code foundation to minimize subsequent re-factoring work. Internal APIs can be laid to ensure code harmony among moving parts.
As in most things, there is an important spectrum of software development speeds. I recommend paying attention to your startup’s spectrum and seeking to be well-rounded.
What are your thoughts on doing things right versus doing things fast in software development?