Iterating quickly is a strength when your engineers are experimenting with ideas. However, as soon as a project is taking off, it becomes vital to put best practices in place so that the code can stay maintainable. Why? Because the code that your engineers are writing in a rush today might very well be your tech debt tomorrow. In other words, the time that you are saving by neglecting the start phase of your project will become a hindrance in a few months. When you will decide to invest more resources to build on this successful application, the developers who are not familiar with the project might be slowed down by the lack of documentation and tests. If you haven’t adopted a style guide for your code, each engineer will add to the chaos by writing code in a different way, thus slowing down even more the discovery process for the teammates who will work on the application in the future.
From a business perspective, it might be hard to see the weight of this cognitive load at first. The cost of not adopting best practices right away will eventually come and possibly create tensions in your company, as the expectations of what was just a little experiment might become high very quickly. In order to avoid a situation that might come to a financial and human cost that could kill the project, encourage your developers to follow these guidelines as soon as a project is greenlit instead:
- Write documentation. The entry point to the code base should answer the following questions: How is this project structured? How do you start the application? How can you work on it locally? How does the project get deployed to production? Where are the secret keys necessary to run third-party services? If the answer to these questions is not straightforward, what can your team do to improve the process? A good README is key to avoid the bus factor. If something happens to the creator of the project, good documentation will help you to continue development.
- Use a linter to format your code. The more uniform the code looks, the easier it is for developers who are new to the project to be productive. By setting some ground rules, you also avoid unhelpful debated about trailing commas, semi-colons, tabs vs spaces, and so forth.
- Write automated tests. If you wait too long, it’s most likely that tests will never be implemented for the project. Tests can feel like a waste of time at first but they will save you a lot of trouble down the road by catching bugs early.
- The structure, documentation, and setup of your application should serve as a template for other projects. Set an example for other teams who might follow suit afterwards. Provide an easy boilerplate they can copy quickly. That way, yout engineer will be less tempted to reinvent the wheel every time they start something new.
- Encourage engineers to communicate frequently with product owners. If a developer wonders how to implement a feature, it’s easier to squash that ambiguity as early as possible with a quick conversation.
As you can see, these rules are fairly simple. However, by thinking ahead, you will save your team a lot of trouble. Your engineers will be able to focus on what they do best: solving problems.