Software Readiness Level
Reading miscellaneous news and articles on the US Space and Defence sector - you will invariably come across "TRL" or Technology Readiness Level. Executive summary: It is (originally) a scale for space technologies and their readiness to operate in space. Later extended to defence technologies in general.
As my thinking usually goes, I try to apply seemingly unrelated concepts to my own field of work (or hobby). What would a readiness scale look like for software?
I would assume I'm not the first to try this - but as of this writing, I haven't explicitly checked.
| Level | Name | Definition |
|---|---|---|
| 0 | Idea | No artifacts |
| 1 | Artifact | At least one artifact/document |
| 2 | Builds | Builds/compiles on at least one computer |
| 3 | Runs | Runs on one computer |
| 4 | Multi | Runs of more than one computer |
| 5 | Happy | Happy-path tests work |
| 6 | Sad | Sad-path tests work as intended |
| 7 | Prod-like | Works in a production-like environment |
| 8 | Production | Works in a production environment with real users |
| 9 | Stable | Has been working in multiple production environments with real users for at least one year |
I think the definitions are largely self-explanatory if you've worked with software development, but perhaps happy and sad are worth a few words.
Happy-path means code paths that do not result in an error, internal or otherwise. Sad-path means code paths that do result in an error.
Because of the time this is written, I suppose I should also mention how LLMs fit in. LLM-generated code lets you go quickly from 0 to 3 or perhaps 5. Attempting to jump straight from 3 to 8 is where vibe-coding seems to go wrong, normally.
This isn't meant to be a strict scale like the original TRL, it is instead meant to encourage structural thinking around what it means for software to be "ready". And perhaps applying seemingly unrelated knowledge to different problems.