If it started today, I certainly would. But I give them a pass because a) legacy code, b) legacy process, c) distributed process, and d) hardware is hard. But

If it started today, I certainly would. But I give them a pass because a) legacy code, b) legacy process, c) distributed process, and d) hardware is hard. But consider this article on how it is tested: https://embeddedbits.org/how-is-the-linux-kernel-tested/ https://embeddedbits.org/how-is-the-linux-kernel-tested/ It mentions a lot of automated testing, which is good. And if you're doing automated testing anyhow, I think TDD is the most effective way to get there. But consider this: "The kernel development process also proves that there is a big focus on testing since around 20% of the development process (2 weeks) is reserved for code integration and the other 80% (8 to 10 weeks) is focused on testing and bug fixes." 80% is a lot! And that also suggests significant lag between writing a bug and having to fix it, which means a lot more time figuring out what went wrong, and a lot more code written after the bug, meaning really fixing it might be expensive. So I think it's reasonable to ask how much more effective kernel development would be if they could safely eliminate that 80% of time spent on cleaning up after the 20%.