bubthegreat/stages-of-software.txt

## stages-of-software.txt
1. Reasonable

First, before you even start building software, make sure it's reasonable.

Does it use well established design patterns like https://learn.microsoft.com/en-us/azure/architecture/patterns/?
Does it make sense for the workload you're trying to service with it?
Can it operate on it's own?
Does it have pathways for expected failure points, like database connection failures, unhandled exceptions, etc.
Can it scale up in the way you've designed it if you have automated scaling?
Can you iterate on it without impacting your existing production instance and still have it tested in a valid scenario?
Does it have good isolation in scope and well defined service boundaries?

2. Running

Once you've determined it's reasonable the first thing you need to do is to get something running.  Get it running local, make sure you can actually get a proof of concept running.  This shoudl be the first step to make sure that you've accounted for problems in the reasonable stage.

3. Repeatable

Once your service runs, you need to make sure it's repeatable.  This means unit testing, integration testing, containerization, deployment configurations, environment variables instead of hard coding, developer environment setup automation through something like tilt, etc.

4. Reliable

Once it's running and repeatable you can iterate to make sure your service is reliable.  Identify error pathways, add error handling, add alerting and monitoring so you know what your service is doing

5. Refined

OPtimize your application - this is more of the maintenance phase, but sometimes it means going back and fixing the quality of life issues that slow you down or prevent you from removing manual toil.

6. Retireable

Make sure there is a plan in place for how to REMOVE this software, and understanding it's choke points and interfaces.
	1. Reasonable

	First, before you even start building software, make sure it's reasonable.

	Does it use well established design patterns like https://learn.microsoft.com/en-us/azure/architecture/patterns/?
	Does it make sense for the workload you're trying to service with it?
	Can it operate on it's own?
	Does it have pathways for expected failure points, like database connection failures, unhandled exceptions, etc.
	Can it scale up in the way you've designed it if you have automated scaling?
	Can you iterate on it without impacting your existing production instance and still have it tested in a valid scenario?
	Does it have good isolation in scope and well defined service boundaries?

	2. Running

	Once you've determined it's reasonable the first thing you need to do is to get something running. Get it running local, make sure you can actually get a proof of concept running. This shoudl be the first step to make sure that you've accounted for problems in the reasonable stage.

	3. Repeatable

	Once your service runs, you need to make sure it's repeatable. This means unit testing, integration testing, containerization, deployment configurations, environment variables instead of hard coding, developer environment setup automation through something like tilt, etc.

	4. Reliable

	Once it's running and repeatable you can iterate to make sure your service is reliable. Identify error pathways, add error handling, add alerting and monitoring so you know what your service is doing

	5. Refined

	OPtimize your application - this is more of the maintenance phase, but sometimes it means going back and fixing the quality of life issues that slow you down or prevent you from removing manual toil.

	6. Retireable

	Make sure there is a plan in place for how to REMOVE this software, and understanding it's choke points and interfaces.