Guidelines for Building Software (In no perticular order)
At Our company, We try to follow the 12 principles of the Agile Manifesto. In addition to them:
- Do not lose customer data: Anything input/sent by the customer should be treated with utmost care. Reconsider any operation that might violate this for any period of time. Consider data security.
- “How is it going to be used?” Ask this in as many places as possible.
- Own things, be proactive: Work with people who do the same. If something can be better, do it yourself, and push others to do the same.
- Avoid knowledge silos Achieve consensus on every decision in the team.
- Build publicly: Let everyone know publicly what you’re doing, how you’re doing it, and why. Praise publicly, criticize privately.
- Think through a solution: Planning is 80%, translating into code is 20%. Get solutions reviewed first.
- Build for your future self: Leave the codebase in a better place than how you found it. Make things uniform. If it can’t be debugged easily, don’t build it.
- Build for the right customer: Speak to & understand end-users as well as you would the code.
- Build small things: Break down larger tasks. Track progress. Question slowdowns and blockers.
- Release weekly: Continuous and incremental. Use feature toggles.
- Build for failure: Every happy path is just one of dozens of failure scenarios.
- Write tests: Not too many. Mostly integration.
- Automate manual tasks: Document if you can’t automate. Comment if you can’t document.
- Prevent people from making mistakes: Both end-users and engineers.
- Don’t be blocked: Ask someone when stuck for > 20 minutes. No judgment.
- Everything is your product: Code, services, UI, colleagues, customers.
Happy learning!