So the original developer writes crap code (whether as a result of burn-out and exhaustion, or just that is the level of talent they have), and the fault for that code almost making it into the kernel is a lack of review, without any responsibility on the coder? And then, once the issue has been identified and the process criticised, the people who gave that person the ability to post such crap code are more focussed on being upset about the criticism than they are about addressing the code and quality issue
> So the original developer writes crap code (whether as a result of burn-out and exhaustion, or just that is the level of talent they have), and the fault for that code almost making it into the kernel is a lack of review, without any responsibility on the coder?
Yes. The problem is that crap code gets into the OS. If your system is dependent on every programmer being really good, all the time, and never making any mistakes, your system sucks. You need to fix the system.
Software development teams / systems are frequently analyzed on a four-level scale. 1-4 or 0-3, depending on which system you use to do the analysis. No systematic code review means the team is at the bottom of the scale, maturity 1 on a 1-4 scale. Moving up a notch, you have teams that routinely and systematically review code. A notch up from that, you do code reviews and keep track of the results so you can improve over time. A notch up from that, you're helping the industry get better - your tracking is good enough that other organizations learn from your stats or processes.
That was interesting. I've not come across that before. Thanks for posting.
Thank you for your comment. A couple of systems that are commonly used include CMMI and SAMM if you want to check them out further. I've found them useful for helping to a) find areas that most need improvement and b) report on that in a way management responds to. You can tell management that there is "technical debt" and they might kinda understand that, but a looking at the development process through a maturity model allows one to communicate in a way is clearly well-thought-out. It's also referencing a widely accepted standard rather than just being someone's opinion.
"Not my monkeys, not my circus" (Score:5, Interesting)
So the original developer writes crap code (whether as a result of burn-out and exhaustion, or just that is the level of talent they have), and the fault for that code almost making it into the kernel is a lack of review, without any responsibility on the coder?
And then, once the issue has been identified and the process criticised, the people who gave that person the ability to post such crap code are more focussed on being upset about the criticism than they are about addressing the code and quality issue
Yes The distro is much bigger than one programmer (Score:4, Insightful)
> So the original developer writes crap code (whether as a result of burn-out and exhaustion, or just that is the level of talent they have), and the fault for that code almost making it into the kernel is a lack of review, without any responsibility on the coder?
Yes. The problem is that crap code gets into the OS.
If your system is dependent on every programmer being really good, all the time, and never making any mistakes, your system sucks. You need to fix the system.
You could say this particular pers
Re: (Score:2)
Software development teams / systems are frequently analyzed on a four-level scale. 1-4 or 0-3, depending on which system you use to do the analysis. No systematic code review means the team is at the bottom of the scale, maturity 1 on a 1-4 scale. Moving up a notch, you have teams that routinely and systematically review code. A notch up from that, you do code reviews and keep track of the results so you can improve over time. A notch up from that, you're helping the industry get better - your tracking is good enough that other organizations learn from your stats or processes.
That was interesting. I've not come across that before. Thanks for posting.
Re:Yes The distro is much bigger than one programm (Score:3)
Thank you for your comment. A couple of systems that are commonly used include CMMI and SAMM if you want to check them out further. I've found them useful for helping to a) find areas that most need improvement and b) report on that in a way management responds to. You can tell management that there is "technical debt" and they might kinda understand that, but a looking at the development process through a maturity model allows one to communicate in a way is clearly well-thought-out. It's also referencing a widely accepted standard rather than just being someone's opinion.