Sometimes "reporting" / "monitoring" is how someone does an end-run around normal product and engineering, and we skip adding what ought to be a feature or domain concept.
replyFor example, suppose someone wants special logging whenever a certain field is edited... And then you find out their real goal is to be able to copy-paste old values back in when someone calls up support and says "oops something went wrong." Now the reporting tool is an intermittent part of our customer support.
In contrast, imagine if there was a real "settings events" table that recorded changes in the app and users could go see them. Or a new concept of "revisions", instead of single mutable field.
This is absolutely the reality. Previous company my first project was on team "improving reporting", and chasing all kinds of gnarly performance tuning to make queries and sorting faster, etc. Once we did all this after a few months, come to find out the PM requesting all this missed that what users wanted was one number in hundreds of rows, and sorting so it would show on top...
replyThe team did not like that I pointed out we could have added the number to the home page in a few minutes...
My experience is always "we have a standard SQL server datamart. We just need to put a good reporting tool on that. You're a business analyst and product manager, go analyze some products."
reply"But can't you just make something exactly like we imagine? We're already paying you and buying stuff is paperwork".