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.
You could say this particular person can't contribute code anymore because their code sucks and you will have fixed 0.01% of the problem. All the other programmers, all of the other humans, are going to make mistakes too, because that's pretty much what we humans do all the time.
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. For example you might might note that 35% of the bugs found are type foo, so you add a check for foo bugs directly in the IDE. 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.
So anyway yeah, their process is apparently maturity level zero, on a 0-3 scale.
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
CMMI and similar are quite passé, for many good reasons. But the general concept of having an auditable design control process is not. It need be possible to understand what piece of code is intended to do and how it was tested, without a lot of effort. There needs to be a process of assessing readiness of code before it is allowed into a release, that is more robust that relying on both the competence and good intentions of any individual.
interlard - vt., to intersperse; diversify
-- Webster's New World Dictionary Of The American Language
"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 person can't contribute code anymore because their code sucks and you will have fixed 0.01% of the problem. All the other programmers, all of the other humans, are going to make mistakes too, because that's pretty much what we humans do all the time.
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. For example you might might note that 35% of the bugs found are type foo, so you add a check for foo bugs directly in the IDE.
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.
So anyway yeah, their process is apparently maturity level zero, on a 0-3 scale.
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: (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
Re: (Score:2)
CMMI and similar are quite passé, for many good reasons. But the general concept of having an auditable design control process is not. It need be possible to understand what piece of code is intended to do and how it was tested, without a lot of effort. There needs to be a process of assessing readiness of code before it is allowed into a release, that is more robust that relying on both the competence and good intentions of any individual.