Over at Coding Horror, Jeff Atwood has run off the rails and gone over to the dark side. He has uttered words that are indistinguishable from those that come forth from the majority of Corporate America Information Technology management. Don't believe it? Check it out for yourselves. I'll be waiting for you when you've read it.
http://www.codinghorror.com/blog/archives/001160.html
Not being one to beat about the bush, let me offer this comment to Jeff's idea.
No, no and thrice no!
Since pastors aren't supposed to say naughty words, I am left with little alternative but to fire up some sarcasm and get to it.
There are so many things wrong with this perspective that it's almost impossible to know where to start debunking this foolish notion. After all, if quantity was all that mattered, then the Microsoft Vista operating system would be the best thing since sliced bread, the bee's knees and the cream of the crop all mixed in together and served with a cherry on top. Last I heard, it was seven shades of dreadful. (Or at least that's what I hear, I use Mac's at home and my employer hasn't moved past Windows XP yet.)
I've mentioned this before in this blog, but the system that I and my co-workers are trying to fix, is an eight year accretion of code. If quantity trumps quality then how come I can't find any in the system? There isn't any. I've looked. My co-workers have looked. And then because we hoped there was something of merit in there, we ran some automated code quality tests on the codebase and some of the modules on their own break the email system when the error logs are emailed internally. That's quite a lot of errors and not a lot of quality.
If quantity trumps quality, then how come the twelve line blank templated JavaDoc before each of the methods don't give me the warm fuzzies? It should. I mean, what's not to like about fifty percent of the source code in any randomly selected Java source file being empty JavaDoc? And broken JavaDoc with invalid JavaDoc tags at that. Goodness, I bet Jeff would love them. There's so many of them, I might ship him a few as we have so many of them to spare.
Now, don't get me wrong here, I think that the best way to learn to write code is to read a little theory and write a lot of code and throw it away. Then repeat. Read a little more theory and then write a bunch more code and throw it away again. Keep repeating this, as I have for about twenty eight years, and you'll be a fairly good programmer. It's not quantity of practice code that I object to, it's the inference that any code base can attain quality by just churning out code with no regard to quality.
Sorry. Ain't gonna happen!
You see, the ceramics example that Jeff gives us just proves that practice does help. There were items made by the "bulk" half of the class that were excellent, because the quest for quantity effectively forced the students to practice their craft. But the admission that not everything was of high quality shows the problem.
Any programming project is the sum of all the code that gets written for it.
By seeking quantity and taking a "quality be damned" approach, you may eventually have the quality that comes from practice, but that quality code will be on top of the early dross and a diamond in the mud, while still a diamond is still muddy and hard to appreciate.
So, may I suggest, as I have learned from experience, that quality comes from caring and practice and not as an accidental discovery within bulk code.
http://www.codinghorror.com/blog/archives/001160.html
Not being one to beat about the bush, let me offer this comment to Jeff's idea.
No, no and thrice no!
Since pastors aren't supposed to say naughty words, I am left with little alternative but to fire up some sarcasm and get to it.
There are so many things wrong with this perspective that it's almost impossible to know where to start debunking this foolish notion. After all, if quantity was all that mattered, then the Microsoft Vista operating system would be the best thing since sliced bread, the bee's knees and the cream of the crop all mixed in together and served with a cherry on top. Last I heard, it was seven shades of dreadful. (Or at least that's what I hear, I use Mac's at home and my employer hasn't moved past Windows XP yet.)
I've mentioned this before in this blog, but the system that I and my co-workers are trying to fix, is an eight year accretion of code. If quantity trumps quality then how come I can't find any in the system? There isn't any. I've looked. My co-workers have looked. And then because we hoped there was something of merit in there, we ran some automated code quality tests on the codebase and some of the modules on their own break the email system when the error logs are emailed internally. That's quite a lot of errors and not a lot of quality.
If quantity trumps quality, then how come the twelve line blank templated JavaDoc before each of the methods don't give me the warm fuzzies? It should. I mean, what's not to like about fifty percent of the source code in any randomly selected Java source file being empty JavaDoc? And broken JavaDoc with invalid JavaDoc tags at that. Goodness, I bet Jeff would love them. There's so many of them, I might ship him a few as we have so many of them to spare.
Now, don't get me wrong here, I think that the best way to learn to write code is to read a little theory and write a lot of code and throw it away. Then repeat. Read a little more theory and then write a bunch more code and throw it away again. Keep repeating this, as I have for about twenty eight years, and you'll be a fairly good programmer. It's not quantity of practice code that I object to, it's the inference that any code base can attain quality by just churning out code with no regard to quality.
Sorry. Ain't gonna happen!
You see, the ceramics example that Jeff gives us just proves that practice does help. There were items made by the "bulk" half of the class that were excellent, because the quest for quantity effectively forced the students to practice their craft. But the admission that not everything was of high quality shows the problem.
Any programming project is the sum of all the code that gets written for it.
By seeking quantity and taking a "quality be damned" approach, you may eventually have the quality that comes from practice, but that quality code will be on top of the early dross and a diamond in the mud, while still a diamond is still muddy and hard to appreciate.
So, may I suggest, as I have learned from experience, that quality comes from caring and practice and not as an accidental discovery within bulk code.
1 comment:
I think the point of his article is that many people waste way too much time on planning and design, trying to come up with the perfect solution, thus putting off the actual work - sometimes indefinitely because they are afraid of "doing it wrong". The hardest part is getting started, right? I've found, in my many coding projects over the past 15 years, that I get the most accomplished when I dig right in and start coding. Of course, after I get things working, I see areas for improvement and refactor, comment, etc. This is the key cycle that should go on until the project is complete: Write, review, and refactor. You'll accomplish much more, much faster that way. The dynamics change a little on an enterprise level, but as an individual programmer on a team, the rule stands.
Post a Comment