Great article. I appreciate the recognition that there are other software- development models which may make more sense for specific scenarios. Some projects do not need 99.999% uptime if it's going to double the cost, and some do.
The name "mono-environment" might be misleading for some, as "mono" might be understood to mean that there is only one environment in total.
The practice of "development-in-production" is becoming increasingly rare but it is worth mentioning. That would be where there is no separate development environment at all. I'm not recommending it in 2026! This method is sometimes chosen because the cost of setting up a development environment that is a good match with production is too high. Similar to what the article says about the downsides of staging, sometimes the cost of creating and maintaining a separate dev environment is high, and the risk of breaking production is acceptable.
An example is when a small team inherits a complex but stable legacy project, they only need to make a few cosmetic changes, it is nearing its end of life, and some outages are tolerable. If there is no dev environment already, why invest in creating it?
Returning to my point about "mono" meaning "one" - naming is hard. I would prefer to use names which more clearly distinguish between these environment topologies. I would suggest "dev-in-prod" and "dev-plus-prod".
It is interesting to also consider dry land which is below sea level.
"For an average height person standing on a beach, their horizon is around 4.5km away."
For an average height person standing at sea level, near a large depression such as the Dead Sea, for example, you may be able to see land at a much greater distance.
I doubt if this factor would impact your findings for the longest sight lines on Earth, but perhaps for some local findings.
Also, applying the same concept to other planets has some surprising results. The tallest mountain in the solar system, Olympus Mons, has very gentle slopes. So gentle that from the peak all you can see is Olympus Mons itself.
> "adjusting their level of detail according to the distance from the camera, a technique known as “billboarding”
No, billboarding is a technique in three-dimensional graphics in which a sprite is rendered perpendicular to the camera without respect to camera movement. Commonly used in early 3D racing games to display background details such as trees, people, and... billboards. It looks ok when driving normally, but the illusion fails when you stop driving and face the side of the road.
The name "mono-environment" might be misleading for some, as "mono" might be understood to mean that there is only one environment in total.
The practice of "development-in-production" is becoming increasingly rare but it is worth mentioning. That would be where there is no separate development environment at all. I'm not recommending it in 2026! This method is sometimes chosen because the cost of setting up a development environment that is a good match with production is too high. Similar to what the article says about the downsides of staging, sometimes the cost of creating and maintaining a separate dev environment is high, and the risk of breaking production is acceptable.
An example is when a small team inherits a complex but stable legacy project, they only need to make a few cosmetic changes, it is nearing its end of life, and some outages are tolerable. If there is no dev environment already, why invest in creating it?
Returning to my point about "mono" meaning "one" - naming is hard. I would prefer to use names which more clearly distinguish between these environment topologies. I would suggest "dev-in-prod" and "dev-plus-prod".