MSN, Google Talk, Y! Messenger...that's all those devs are doing over there...I need statistics...I need to know what they're doing, I need to know if they're productive!!!
This might be the cry of CIOs in many places, so they send their subordinates like India Jones searching for the "holy grail" to measure developer productivity or to find a way to do it. Is this a myth??? Is there really a grail? Can there really be a way to measure!!!?? (ta da da dahhh [that's like a movie sound when they find out the killer was really the sheriff and not the father]).
Well according maybe to some CIOs they have found it!!! (Drum roll please) (Drum Rolling) (Drum still rolling)...it is....
COUNTING LINES OF CODE (Scream, run for your lives...it's ABACUSZILLA [you better get a bigger ABACUS]). Oh wow, counting code... hmmm...sounds like something from the early days and IT IS!
Source Lines of COde (SLOC) came about during the time when the most common languages available were like FORTAN and assembler, they were all line based. It was during the time of puncha cards (main way to enter data for programming). One punch card usually represented one line of code, so naturally managers wanting to see then what the productivity was like for the day for emlployee joe was to count the number of lines. For this time, this was fine.
For CIOs chasing this dream still, they're raiding a lost ark, this methodlogy was lost along with the punch cards, so if you're interested in that, by a puhch card machine and let us cut the code there...(I wonder if I could get a webservice to run on a punch card).
COME INTO THE LIGHT
There are new better ways to measure developer productivity, for example using Visual Studio Team System (VSTS). VSTS allows CIOs, team leads, BAs etc to view developer productivity in many ways. VSTS allows the BA or Team Lead (depending on your structure) to put the software requirements in spreadsheet with budgeted times for EACH requirement and then assign it to a developer, this is ELECTRONICALLY done. At the end of the day, we measure task given vs completion or non completion. Here are some other items vSTS provides.
•My Work Items: This report provides a list of the work items that are assigned to the team member's alias. By using this report, each team member can quickly locate their work item assignments instead of trying to locate their assignments in either e-mail messages or through a team communication meeting.
•Active Bugs: This report provides a list of the bug type work items that are not yet closed. By using this report, project leads, testers, and developers have a real-time status of bugs as the bugs are resolved. This report provides a more efficient and collaborative platform for the bug workflow process.
•All Work Items: This report provides a list of all the work item types and provides the project manager with a complete listing of the work items that have been created in the project.
•Remaining Work: This report provides a chart that displays the remaining work sorted by date. This report is used by the project manager to perform resource leveling on remaining work items and to report the project status to stakeholders.
•Bug Rates: This report provides a chart that displays new, active, and resolved bug work items sorted by date. This report is used to provide metrics data for the consolidated status reports and to see if there are any patterns in bug occurrences.
•Work Items by Owner: This report provides information about each team member's work items sorted by owner. The project manager also uses this report to help perform resource leveling to distribute work item tasks evenly within the team.
These are just some of the benefits of new technology to not only measure productivity but also manage the development process.
So the next time someone wants to see your SLOC tell them to go to VSTS!
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight." ~ Bill Gates.
Additional Links
http://en.wikipedia.org/wiki/Source_lines_of_code
Overview of Team System - http://msdn.microsoft.com/vstudio/teamsystem/reference/default.aspx
So what say you...VSTS or SLOC?
Dellendinho
2 comments:
Dellendinho well said,
I totally agree that SLOC is an outdated method of measuring productivity. The programming techniques have evolved and the measurement techniques have evolved as well. Using SLOC focuses on quantity and not quality. Its similar to saying you are more intelligent than everyone else because you use more words per sentence regardless of if the sentences makes sense.
I'm not familiar with VSTS but from what you mention its tools seem much more appropriate in determining productivity because it focuses on the quality of the output (whether it meets requirements) and not just how much output.
Lets home the CIOs out there realise that times have changed if they started back in the punch card days.
I as well agree with the post and I think most CIO's out there are knowledgeable about the issue, and if not they trust those who are.
The question is why doesnt this hold true in our scenario. It seems the effective leader in any position should trust his subordinates decisions in areas where they know more about the subject than that person does.
Post a Comment