| This is arguably addressed in the article where they link to this article:
https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... It's a bit of an argument for "less haste, more speed". As an example, I've always found with CI (continuous integration) servers that setting them up on day 1 of a project takes almost no time, but trying to set them up 3 months (or later) into the project seems to require a lot of time. Once a CI server is set up, it invariably improves both quality and productivity significantly, they start yielding dividends on their time investment very quickly. If management claims they can't afford the relatively small amount of time required to set up a CI server, then I would argue that the lack of time only strengthens the need to have it done sooner to enable the project to move faster. For onboarding documentation, finding random time may be hard, but it's almost free if it's done by a new member as they join a team. As they get their environment up and running, they just need to document the steps as they went along. Make sure it's committed to the same source control repository, readme.md seems to work well for this. It's fine if it's initially very simple, just an unformatted list of steps in plain text is a great start. If someone is adding new technology stacks which would would affect the onboarding document, they should quickly add it at that moment, while possibly improving it a little by adding a little formatting. Future new team members should also be encouraged to improve the documentation based on their onboarding experience. Over time the document becomes quite refined and easy to keep upto date. That doesn't address all their points, but it's a start and I hope it's helpfull. |