God mode – when should you use it?
What exactly is god mode?
As developers, we have access to the database. You can access the data in its raw form. You can make changes to the data in the database using tools like tableplus assuming you have been given write access to the DB. This is god mode. You can manipulate the data in the system and change the lives of the users (assuming your micro-service is of some significance to the customer).
When and who can have god mode?
|Stage||Developer||Internal user||Regular user|
|Complete/Lovable||yes||Start restricting god mode||No|
|Complete / Lovable High scale||Only for team leads or senior members of the team||Non existent||No|
No more god mode when subsystem starts to achieve more and more scale and starts to have more and more consequence.
- Internal user – internal employee. uses god mode via the UI. maybe someone who handles operations etc.
- Regular user – Consumer of your software. Mostly external to the company.
- Stages – Maturity stages of a product
In the early stages of a system we are trying to establish that:
- The data structures are designed right
- The processes are designed right
Here we are optimizing for flexibly and agility. We want to change fast and build fast.
- Most of our UI will be representation of the database object on the screen.
- God modes for editing the object.
- More flexibility for the user
When the value hypothesis is proven, we exit the early stage approach of building systems.
We enter the stage where the systems start to take on the scale. When we do take on the scale, the ability to change fast is not that much of a requirement. When scale happens keeping the data structures consistent reduces clean up work for developers. It also makes it simpler for developers to continue focusing on incremental features instead of firefighting.
In this stage we apply the principles of
- Don’t make me think
- You want to do minimum data clean up work (no firefighting)
- You want to make sure your data integrity cannot be compromised
- You want to make sure your systems are idiot proof.
In this stage:
- You remove god mode or restrict it to very few people (less than 3)
- More controllers that does a specific process that some individual want to do.
- This controller makes sure the change in data structure is idiot proof.
- App looks less like a database and more like a set of very specific actions that you can do.