The limit of process improvement
Posted by posted by Francis @ 2/14/2009 08:20:00 PM
Jeff Atwood had a really quotable sentence in his latest blog post: Coding Horror: Real Ultimate Programming Power"Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off."
This funny sentence expresses something that I have had a really hard time expressing for the past few years: Rules and processes don't make your terrible programmers better, it limits the damage that they can cause to your project.
Not all problems can be solved by adding process.
The only long term solution to dealing with terrible programmers is to give them the tools to become good programmers. Training, mentoring and support. And the training shouldn't be about process but about the craft of programming. Reading code, using a debugger, how to solve a problem with software.
Labels: work
5 Comments:
At great companies, the process is good when it automatically throw the right people out of the bus - From Good to Great Book :)
Oops, this is not what I meant to say, lol :)
I meant to say: At great companies, the process automatically throw the wrong people out of the bus - From Good to Great book :)
If our process doesn't repulse the wrong people or "bad programmers" as you call it, then improving the process is needed, but not the kind of process improvement that saves time and money, but the kind of process improvement that differentiate between good programmers and not so good ones and repel the second type away.
Indeed. A great dish recipe doesn't necessarily make one a great cook. It can help but there is more to it.
I agree with the concept of people jumping off the bus if they don't like the processes in place. This works when workers are a commodity and are easy to replace.
Good programmers are not so easy to find. Schools don't give programmers the skills they need. New grads are told how to write code. They don't know how to read it. They are not told how to use a debugger effectively. They have never navigated a code base bigger than a few thousand lines of code.
Skills that work when you are doing a CompSci assignment fail to scale-up to real-life projects.
Yes indeed. Mentoring and coaching can also be a part of the process, training for best practices...etc. I guess what I am trying to say is: process improvement shouldn't stop in my opinion. The definition of process improvement should grow as well to include more topics like training, mentoring, coaching...etc
Post a Comment
<< Home