Saturday, October 28, 2006

Measuring Developer Productivity

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

Friday, October 20, 2006

Microsoft Certification for Project Managers

Yes the MS is at it again. They will be launching a new certification geared towards project management similar to their new generation technology specialist certs.
So what's the new name??? Ahh...It hasn't been decided yet but they will know pretty soon to coincide with an upcoming PMI conference.

So what do you all think, is microsoft certification in PM going to hold any water? Will it have the same requirements like PMI (x hours experience etc) before doing exams or will the dump trucks come in and mess up the exams...feedback people. Check out some links on the Microsoft and MCPMag website.

http://www.microsoft.com/presspass/features/2006/oct06/10-20project2007.mspx
http://www.mcpmag.com/news/article.asp?EditorialsID=1084

Dell

Monday, October 16, 2006

MSDN Solution Architecture for Banking Industry

Excellent move. Microsoft has finally released a very important part of their MSDN site. Solution Architectures for the banking system. At a first glance the site
http://msdn.microsoft.com/architecture/industry/finservs/banking/ has quite a bit that alot of banking architects would be interested in. The ones I found interesting are
  1. The Global Bank scenario - about designing, developing service oriented application. This gaves a strong overview of why you need a SOA to move forward. (There is also a video on the front page)
  2. IFX service orientation Study for payment processing (this one even comes with a demo) - financial interexchange standard. I would advise any banking solutions architect serious about SOA to read this document.

These both will have immediate impact on any adapting organization. Bon Apetite!

Dellendinho

Saturday, October 14, 2006

Keeping up with the Frameworks!

This post isn't about frameworks running side by side etc but it's really about the architects & developers that have to manage these frameworks in their environment.

For the last 6 years of so, Microsoft have launched 3 different framework versions (1) .NET Framework 1 (2) .NET Framework 2 and (3) .NET Framework 3 (to be released soon) .
http://en.wikipedia.org/wiki/.NET_Framework

The advice would be to get certified on all, as they're released, learn about them and get certified as early as possible. Makes sense right. That's if you were around when it just came out, but what if you've fallen behind (i.e. still coding in version 1.1 and haven't started on 2.0 yet) can that approach really work?

There's an issue circulating among my peers and that is, going forward, which frameworks and their supported technologies do I get certified on to be a marketable developer. In my opinion, get certified on all of them!

The logic for backward certification

Currently our company is pushing to do some new developments and this will be done on .NET Framework 3.0 (WCF) and some done in .NET Framework 2.0 whilst still maintaining tonnes of code we have currently in .NET Framework 1.1.

Companies may not have the funding to upgrade their stable applications to target different frameworks, so v1.1 might be around for a very long time and someone has to maintain it.

Microsoft has made the certification track clear for everyone. After completing the 3 exams required to become a Microsoft Certified Application Developer (MCAD) a developer can easily upgrade to the Microsft Certified Professional Developer (MCPD) by doing two additional exams.

In my opinion it's a quick path to the new versions whilst being very much in touch with the previous version. The key is to complete these ASAP and then be ready for the release of the new Microsoft exams on the newest framework.

Dellendinho