Fractal problems

There was a meeting yesterday. For whatever reason, the department head wanted to recognize every project team that has published something this quarter as part of a rulemaking project. Seeing a parade of present, active projects, one thing about them jumped out at me: there was quite a bit of overlap with the doomed project.

There were at least two projects with basic goals that overlapped heavily with the doomed project. And these are not trivial issues that the doomed project covers in a paragraph or two. Operational L__, the huge thing added from scratch relatively late, has a rulemaking project devoted to it. So does the general issue of closing the loophole. As for how big that is, it's the thing discussed here, the issue that contributes one phrase to every single section. I have the sense that there were even more overlapping projects than that, but I wasn't taking good notes.

I've mentioned that a "kitchen sink" approach for the doomed project has been one of the big problems with it from the very start. What surprised me yesterday was learning just how unnecessary a lot of it is. When SMEs claimed that certain things like XYZ really need to be done in the doomed project, I took them at face value. Apparently operational L__ and the loophole really don't need to be here, though. Which is funny, because the closing the loophole sounds like a no-brainer even to a non-expert like me, but if there's a whole other project to address it, we shouldn't have to do that here. I'm sure that the responsible department would argue that it needs to be in the doomed project because the doomed project is scheduled to be finished before the loophole project, and that might have been true if the loophole were the only other extra in the doomed project, but considering how fast it's going now...