Earlier quoted context omitted.
That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the…
It sounds like there is enough slack in the schedule that teams can decide they want to spend non-trivial amounts of time on these projects. It's surprising to hear that anyone, even the companies with big budgets, are able to hire enough people to do this without the projects getting an official seal of approval and budget. Even just taking the time to document, package, and publish is non-trivial. It seems like the…
Documentation costs productivity to write, but when there are many people who would be made more productive from it, it makes sense to do it.
I think "slack" is the right way to think about it. It isn't a free-for-all - the business still needs to run - but there's enough space to explore, to rewrite, to document, to polish, and so forth. That's where the magic happens - the unplanned and the unexpected things around that which you thought you were going to do.