My department is in the processes of replacing some of systems with new software.*
Part of the early process in many, many meetings to talk about things like:
What does the system absolutely need to do so that we can do our jobs? What is our end goal?
What are our processes? How do we do each task?
Do they need to be done this way?
What data do we need to keep so that we can use it, what do we need to keep but archive, and what can we get rid of?
Okay, but seriously, does it really need to be done this exact way?
Me wondering if database structure, at its most basic level, is not as inherently sensible and intuitive as I think**
During one meeting a colleague was showing our processes for extracting large datasets to send to clients.
The person heading the system change later referred to it as "the grossest demo of large scale information requests."
So, it probably says a lot about my job that my response was that it wasn't so bad, the program didn't crash that time and it even took under an hour!
*that will eventually integrate 2-3 disparate systems and cut down on So. Much. duplication of work and data. And also let us stop forcing software that was made for a completely different purpose to, well, screw up less of our data than it could.
**basic, basic level. The level that you can diagram with tables and connections. I've only done introductory database work, but the way connections and tables are structured is sheer brain-candy-dopamine-hit-enticing