24: Give software tools to good engineers
I don't like this.
Right off the bat you're creating a separation between the engineers you have. There's the "good" ones and they get new shiny objects.
Then there's the "not-good" ones and they have to suffer.
If you don't think the engineer is good - Get Rid Of Them. I know this isn't always easy. A manager of mine once asked, "Is it more or less work to fix what they've done?" and if the answer is "less work"... then they're a positive to the system.
Yeah, but if you fire them you can get someone that does work you don't need to fix.
Anyway... I don't like the distinction between "good" and "not-good" engineers. Especially when some can get things to improve their performance and the others don't.
The books specially says that not giving tools to poor engineer has them produce less poor-quality software.
Holy fucking shit - The book fundamentally suggests limiting tool usage as a mechanism to limit the engineers you don't want writing code.
Fire. Them.
If you don't trust them to write good code; or don't trust them to be able to use the tool - then you shouldn't have them on your team.
Yes, there will be bad engineers. Crappy ones that aren't QUITE crappy enough to fire... Pair them with Good ones. Put them on a team with an iron-fisted code review process.
There's a lot that can be done to mitigate poor-quality software besides "not giving them tools".
If you think this is a great way to force them out, or get them to leave... Do your job and Fire Them.
This whole bit smells like a way to get poor engineers to quit vs good utilization of tools. It's a shitty bit of advice.