Last update: February 7, 2021. I will work on this list for multiple weeks, maybe even the year. I want to summarize everything I've learned to create a successful software development project. I won't go into details. I'll write separate articles if there's more to write. I celebrate my 10th year in the business. Let's see if I learned something.

Planning and management

• How frequently will you deploy to production? You have three choices: every merges, every few weeks, every few months.
• The first few releases should not contain any business features and focus only on putting the infrastructure in place.
• Your multidisciplinary team should cover these roles: architect, analyst, designer, tech lead, integrator (pipeline owner), test lead, product owner.
• You should not be part of a project where you're the only developer.
• Do not separate your team by the business project. Separate your experts by the system, and only if the teams are getting too large.
• Do not separate development from operations teams. Keep your experts together.
• Use kanban to see everything on a single board. Time to production is a good indicator. Focus efforts on what is blocking the team from delivering quickly before adding more business features.
  • If you have a single board and a single team, your feedback loop should be short and allow you to see easily what is blocking and what needs to be done.
• Have a standard way to deal with external resources. Is it a recurring problem? Add that resource to the team or find out a solution to automate collaboration between teams.

Architecture

• Find the boundaries of the concepts of the business and make them separate components.
• These boundaries (interfaces) should not move when the system under changes.
• If these systems are not physically separated (monolith), ensure maximum control is in place to prevent violation of the boundaries.
• Architect with development in mind. Use techniques that developers will like to use.
• Architect for maintenance. How will the systems be upgraded?

Pipeline and workflow

• If the core of the assembly line is not in place, do not start business features.
• Use the GitHub flow. The less branch you have, the better.

Analysis

• Gather specification by example. Use something like Given-When-Then. Use these specifications for automated testing.

Design

• No developer should write a single line of code before having their plan approved. Do a kickoff meeting to brainstorm and draft a plan with your peers.
• Your code should not contain a breaking change and should be deployable to production the same day.
• Decomposed your story in multiple fragments deployable to production. Plan how (feature flag?) and in what order your fragments will be deployed.
• Plan time for
  • Formation
  • Refactoring
  • Security
  • Quality

Development

• Document basic code standards for all technologies involved before your first story.
• Schedule a bi-weekly meeting to review and update these standards during the project with all the problems and new ideas found. Be positive during these meetings. The team should be encouraged to better themselves.
• Merge code every day
• Leave code better than it was.

Testing

• Automate all tests.
• You need the right balance of unit and business-facing tests. Use the same structure for both kinds of tests (Given-When-Then).
• Approval by the product owners is the only manual step and only for newly activated features.