I would like to go back to the idea of measuring performance, as I mentioned in my last post. You can't measure a developer's productivity by lines of code, because some of the most elegant and worthwhile solutions come from simple and concise code. You can't measure fewest number of bugs, or most number of bugs fixed, because then you'd write fewer lines of code, or create code with more bugs that you could fix, respectively. You can't be a tangible value on performance, just like you can't easily put a value on the length or difficulty of a project.
I read an interesting book a few years back called the Mythical Man-Month, by Fred Brooks (find out more: http://en.wikipedia.org/wiki/The_Mythical_Man-Month). The book talked about how if you have X developers and your project is delayed (as most software projects eventually become), adding more developers will actually delay the project even further. If it takes 1 man 12 months to do a project, it will not take 12 men to do the same project in 1 month. While this probably applies to any group endeavor, it think it is most apparent in software development since the communication and team work is so critical to getting a large project completed. With 12 developers, there are now 66 lines of communication possible, and the added task of dividing all the code responsibilities and coordinating how they fit together.
While the book wasn't directly talking about measuring performance, it is really the same idea. How can you measure whether someone communicated well with the rest of the team, or whether the code they contributed was more efficient or more robust than the others. You can't, without monitoring all your employees during all hours. And that would double your personnel, and don't get me started on how many more lines of communication that would create. As for me, I just try to work hard and do my job, and hope that I truly am being productive.
I read an interesting book a few years back called the Mythical Man-Month, by Fred Brooks (find out more: http://en.wikipedia.org/wiki/The_Mythical_Man-Month). The book talked about how if you have X developers and your project is delayed (as most software projects eventually become), adding more developers will actually delay the project even further. If it takes 1 man 12 months to do a project, it will not take 12 men to do the same project in 1 month. While this probably applies to any group endeavor, it think it is most apparent in software development since the communication and team work is so critical to getting a large project completed. With 12 developers, there are now 66 lines of communication possible, and the added task of dividing all the code responsibilities and coordinating how they fit together.
While the book wasn't directly talking about measuring performance, it is really the same idea. How can you measure whether someone communicated well with the rest of the team, or whether the code they contributed was more efficient or more robust than the others. You can't, without monitoring all your employees during all hours. And that would double your personnel, and don't get me started on how many more lines of communication that would create. As for me, I just try to work hard and do my job, and hope that I truly am being productive.
Comments
Hi hun, so as I was reading over your blogs I was reminded of a couple things; one is that you are a good writer, and secondly that you have mad website-making skills. I was perusing some friends websites who shall remain anonymous, and, well, your website makes me want to laugh at their websites. Seriously, it's a little bit sad.