Cheat Sheet: Project Kick-Off

Introduction

I regularly spot the same things in projects that make me think “I wish we’d considered this earlier”.

This post is a checklist for myself to think about when kicking off a new project. Some items apply when joining an existing project too.

It’s currently in draft format and needs reorganising, but I want to get it out there.

I plan to keep this post updated as I think of new things to add or change over time.

Pipelines and CI/CD

• Static code analysis in pipelines
  • Linters?
  • Sonarqube?
• Automated accessibility testing
• Can you go to prod on day one?
• Can you avoid branch-based CI and focus on trunk-based development?
• If you absolutely must generate release notes, can you automate this in your pipelines?
• Your pipelines should fail if they find dependencies with known issues (using something like npm audit)

Monitoring, Logging, Observability and Alerting

• How will you know when something has gone wrong?
• Can you include both correlation IDs and customer-journey IDs in your logs from day 1?
• Do you need Google Analytics on your frontend?
• Is Instana something you should look at using?

Other stuff

• Feature flags/toggles - will they be easy to add if you need them? Why not just add this capability from day 1?
• Is your team skilled at outside-in TDD? If not, can you coach them during the project?
• Does the problem you are trying to solve actually need software written?
  • Is there an open source tool that already solves the problem at hand?
  • What’s the smallest, leanest MVP you can get away with?
• Can you set the codebase up such that a developer can clone it, build it, and run the tests locally with little to no effort?

Architecture

• Remember that your job is to write software that is easy to change and maintain.
• Clean Architecture - is this an option?
  • Can you get away with a hexagonal monolith?
• Does your architecture allow for blue/green or canary deployments?
• How much infrastructure work can you outsource to existing solutions, or at least write as code?
  • Serverless framework - will this work for you?
• Where are the high-level boundaries in your domain?
• What are your obvious initial integration points?
• Are your VPCs, and all related network and security boundaries, laid out in a logical fashion and, if needed, easy to change later?
• If you are using a cloud provider like AWS, do they have a simple, recommended infrastructure pattern you can follow?
• Do you need to ship data to a data warehouse?
• Do you need different read and write models?
• Do you need to think about CQRS?
• Do you really need a document DB? Or is this software inherently mapping entities that are more relational?
• Can you automate dependency updates somehow?
  • Dependabot?
  • Renovate?

Technology

• Can you achieve your goals using boring technology?
• Can you choose one language that will work in all areas of your code?
• Is your chosen language/stack/framework etc. a popular and proven one that you can easily hire for later on?

Team shape

• How close can you get to your customer?
• What’s the smallest, leanest team you can get away with?
• Can you get a product owner and a few real users on your team?
  • How do you know what your users actually want and need?

Processes

• Do you need fancy processes, scaling frameworks, Scrum masters etc.?
  • Or is your team disciplined enough to take a simple Kanban approach without needing “management”?

Main sources for this post

• Lessons and mentors over the course of my career.
• Lots of conversations with Neil Kidd, David Capper, and Craig J. Bass.
• Dave Farley’s YouTube channel.