I'm setting a record for most posts to this blog in a week.....
One of the biggest team problems you'll run across is the zealotry for the One True Way. Editor wars, code format wars, process wars, ad nauseum.
I read this recently, and it encapsulates the entire view - everyone who holds a strong opinion about software details. But the key takeaway point is that it's almost never a good idea to rewrite something if the only reason is that "I don't like it the way it is"
Case in point, I was given responsibility over a process that needed a significant new feature. By and large, the code was moderately inbred, 10 years of tweaks and fixes. I made two significant refactorings before adding the feature - I changed the polarity of the flag variables - they used 0 to mean set (do X) and 1 to mean unset (don't do X), and changing them to be 1 for set and 0 for unset brought this process in line with the rest of the system; and I replaced 4-5 chunks of repeated code with an extracted method - so that I could clone it for the new feature, which did all the normal stuff, but with additional data to process.
The rest of the code I left alone, not even changing the brace style to suit my common style, because it was safer to not change working code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, May 13, 2008
Recognizing Competence
Amazingly, someone is more pessimistic than I am about getting through to management!
It is true that many (most) managers who are not developers have little means to distinguish between good and bad developers. And to make it harder for them, the criteria that some of the responses to the link claim will help managers tell the difference are flawed - it's not always the competent developers who complain about conditions.
From the Ninja Historical Documents, I refer to one of my former colleagues. He was very vocal about all the problems our group had - schedules, technical defects, missing requirements. However, we discovered after he left that he was not nearly as good as he thought he was - a number of key pieces of our libraries that he had coded were not at all functional. So the mere appearance of competence is not enough; the managers will not have the technical chops to tell if any given developer can walk the walk.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It is true that many (most) managers who are not developers have little means to distinguish between good and bad developers. And to make it harder for them, the criteria that some of the responses to the link claim will help managers tell the difference are flawed - it's not always the competent developers who complain about conditions.
From the Ninja Historical Documents, I refer to one of my former colleagues. He was very vocal about all the problems our group had - schedules, technical defects, missing requirements. However, we discovered after he left that he was not nearly as good as he thought he was - a number of key pieces of our libraries that he had coded were not at all functional. So the mere appearance of competence is not enough; the managers will not have the technical chops to tell if any given developer can walk the walk.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Backshoring
So with all the jobs going over to India, what are we to make of this post?
Sounds like programmers are not all interchangeable, and it takes local people who know how the product is to be used, in order to develop good software!
I think that my earlier comments on this subject are valid.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sounds like programmers are not all interchangeable, and it takes local people who know how the product is to be used, in order to develop good software!
I think that my earlier comments on this subject are valid.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)