Startup Development Healthcheck

This healthcheck has to your first step toward building a better software for startups. It helped me to build a couple of successful MVPs and this guidelines is guiding me on every tech decision.

How to execute the health check:

1. Grab your dev team and book a 2-hour meeting. Don’t include business partners or other stakeholders, it has to be an internal meeting just for devs. Get an outside facilitator if you have no senior leader who can lead the meeting.
2. As a team, go through every point and evaluate it on a scale from 1 to 10. Note your answers. If you are not sure what some rule means – google that, and make sure you understand every word from the doc.
3. During the discussion collect action points, especially when something is having a score of less than 4.
4. Calculate the average score, combine your action points into a single action plan, and send it to your stakeholders.

Development

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility, and maintainability.

General rules

1. Follow standard conventions. Have conventions for naming, function length, quotes, etc. Utilize Linker to control the quality.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy Scout rule. Leave the campground cleaner than you found it.
4. Always find the root cause. Always look for the root cause of a problem. Don’t do quick fixes, avoid IFs.

Design rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Prevent over-configurability.
4. Use dependency injection.
5. Follow Law of Demeter. A class should know only its direct dependencies.
6. Utilize types, don’t use any

Understandability tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Prefer dedicated value objects to primitive type.
4. Avoid logical dependency. Don’t write methods which works correctly depending on something else in the same class.
5. Avoid negative conditionals.

Names rules

1. Choose descriptive and unambiguous names.
2. Make meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don’t append prefixes or type information.

Functions rules

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects. (or have as less as possible)
6. Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Comments rules

1. Don’t add obvious noise.
2. Don’t comment out code. Just remove. You can find it in Git.
3. Use as clarification of code.
4. Use as warning of consequences or as a clarification of a decision.

Source code structure

1. Separate concepts vertically.
2. Dependent functions should be close.
3. Similar functions should be close.
4. Place functions in the downward direction.
5. Declare variables close to their usage.
6. Keep lines short.
7. Use white space to associate related things and disassociate weakly related.
8. Don’t break indentation.

Objects and data structures

1. Base class should know nothing about their derivatives.
2. Prefer non-static methods to static methods.
3. Better to have many functions than to pass some code into a function to select a behavior.
4. Do one thing.
5. Should be small.

Code smells

1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
2. Fragility. The software breaks in many places due to a single change.
3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
4. Needless Complexity.
5. Needless Repetition.
6. Opacity. The code is hard to understand.

Architecture

Architecture has to be supported by a developer, not a burden. Well, design architecture makes you more efficient. You never have to be scared to deploy your code, add a new environment variable or create a new microservice.

1. Document your backend endpoint, you will say thank you in the future (SwaggerUI, tags, examples, descriptions)
2. Make your backend stateless so that you can easily scale it horizontally
3. Automate everything which requires you to spend a small amount of time every day. Definitely have CI/CD and automated linter.
4. Make sure your secrets are separated from the code.
5. Your infrastructure has to be easy to develop locally. Utilize the power of Docker and Docker compose if you have a lot of components that require setup like DBs.
6. Make your infrastructure observable on the front end and backend. Tools like Fullstory, Smartlook, and Google Analytics make your frontend observable. Tools like Prometheus and Grafana make your backend and infrastructure observable.
7. Do smart logging. Separate your log in separate threads. If something happens you have to be able to find the root cause just from logs.
8. Local and staging testing before deployment to the backend. Never deploy directly to production. Build expectations with a business that code needs to go through the testing circle before being delivered.

Project management

Even small your startup is a project and it needs management. bad project management will make your co-founder and employees hate work. Good project management will make work feel like a vacation and will get the most out of everyone.

• The team trust each other and there is a feeling of team responsibility.
• Execute daily meetings with daily standups. If you feel the standup is too long – separate dev standup from business standup.
• Don’t merge anything in the master without a code review
• Stick with 1-week sprints and do sprint planning every Monday.
• Utilize specialized project management software like Jira, Asana, Notion, or clickup.
• Organize weekly planning. The planning can be done by CTO or founders, but don’t forget to present it to the team and do estimating together.
• Organize retrospectives from time to time, at least once per month.
• Strategically utilize tech debt. Let your engineers add more points to it if they think some features or optimizations can be postponed.
• Execute roadmap planning once in 1/2 month together with all stakeholders and optionally the dev team. Prepare a visual board for this meeting and discuss every feature before putting it on the roadmap.

If you need any clarification or you are seeking help over executing or reacting to the health check drop me a message at yev.rachkovan@gmail.com.