Tag Info

Hot answers tagged

138

Sounds like it would do more harm than good. Ignoring for a moment whether it is fair for a manager to do that, let's look at the logistics... Problem 1: Are all bugs created equal? Developer 1 introduces a bug: Erases all customer data and curses at them. Developer 2 introduces two bugs: Form labels are not left aligned, and the calendaring feature is off ...


72

In 16 years I've never actually found a workable metric of the sort you're looking for. Essentially to be useful anything would need to be measurable, representative and ungameable (that is the system can't be played by clever developers). There are simply too many variables within software development to make it measurable as piece work in this way. The ...


47

Programmers are notorious for optimizing what managers start rewarding. If you reward LOC, then you get lots of whitespace to pad out the lines of code metric. If you try to punish by bug count, you will start getting into wars where the developers claim that X is not their bug (the bug is in the compiler or API or just somewhere else) - and the bug filed ...


40

In a word No First : I've never had my projects remain stable enough that I could establish the SMART goals with any meaning. The time scales between when my roles change on a project and when perf reviews are done are just too far out of sync. Second: Measuring individual performance is a great way to create a "not my job" mentality and negative ...


31

Metrics work best in factories, and programmers don't work on an assembly line. I completely understand the desire to measure productivity. But would you use the same metric for a family doctor and a heart surgeon? How about for Michelangelo painting the Sistine Chapel, and some guy in Mexico cranking out black velvet Elvis paintings? Louis de Broglie ...


30

You can take a look at the Programmer Competency Matrix and see where you are on that and where there might be room for improvement. Getting involved with the local development scene can be beneficial as well, since you'll be in a position to compare yourself against developers from different environments (i.e. not just your co-workers). To see what your ...


22

"Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs."- Bill Gates


21

You need an experienced developer or teamleader (who is not associated with those remote programmers) to estimate how long some task may take, and the effectiveness is measured by comparing their required time against the estimates. To be sure that the estimates are good, you could randomly pick a few tasks and have them executed by an in-house team you have ...


21

Contrary to intuition, the number of errors per 1000 lines of does seem to be relatively constant, reguardless of the specific language involved. Steve McConnell, author of Code Complete and Software Estimation: Demystifying the Black Art goes over this area in some detail. I don't have my copies readily to hand - they're sitting on my bookshelf at work - ...


18

The claim is - at best - naive. SLOC isn't exactly a reliable metric for anything useful, except perhaps comparing the size of two or more projects. Furthermore there are two distinct types of SLOC, physical LOC and logical LOC, and those might differ significantly. Consider this example, from Wikipedia: for (i = 0; i < 100; i += 1) printf("hello"); ...


17

It's not the size of the project. It's the quality. Take the time to do it right so that it is worthy of being a portfolio piece. So long as the project is sufficiently large enough to demonstrate the knowledge you want to convey, only quality will matter.


17

When we interview, we ask for this on the final interview. I will start by saying that size doesn't matter and then qualify a little (isn't that always the way). If I ask someone to submit a piece of code they feel proud of and want to stamp their name to and they send me a single file then I'm going to lose confidence. In one case, I received a long ASCX ...


17

This a dangerous idea. "Objective" proxies for quality lead directly to management rewards and developers will pursue these metrics at the expense of the actual quality. This is the law of unintended consequences. Quality -- while important -- is only one small aspect of software. Functionality and value created by the software are far, far more ...


17

Developers should hold themselves accountable for the quality of the code they produce, and they should expect that their manager will do the same. But that doesn't mean that some developer should get a demerit every time a bug is reported. No manager in their right mind would say: Well, Johnson, you checked in 500 lines of code last week, and so far ...


16

No, they should not. This is no manual labour and none creates bugs intentionally. How can we expect productivity from a sad horrified programmer? Things should be cool around him. Ultimately noone get benefitted from penalizing.


14

There's a simple answer: you can't. And moreover, you shouldn't. You want to measure your own productivity, but you can generalize: how can you measure productivity of programmers? First of all you have to define what you mean for "productivity": amount of code produced? Amount of design (or specification) implemented? Number of issues fixed? Quality of ...


14

My intuition goes like this: The more people assigned to a project of given size, the bigger the communication overhead => the higher the chances of misunderstandings and all sorts of communication problems => the higher the number of resulting defects. And Good developers are rarer, thus harder to find and hire, than mediocre / bad ones => the more ...


13

include the value you added to the pair programming in the performance review - did you help the other programmer learn useful things? (and vice-versa, did you listen to his/her sage advice and cooperate well?) a performance review should not be a competition, it should be a coaching evaluation relative to your personal goals (which are presumably in line ...


12

We've used SMART goals in the large corporation where I work. They're meaningless for the most part. Goals come down from upper management and are lofty and abstract. Relating them to concrete projects and development is usually a joke. Most of the projects that come into the group come from the business and are to meet a specific business need. So you ...


11

Ohloh is a website that keeps track of many open source projects and calculates the estimated cost by using the basic COCOMO model. With Ohloh, the number of lines in the codebase (which is used to calculate the man-months expended to produce the software) and the average cost of a developer, which appears to be set to a default value of $55000/year, but ...


11

A manager recently announced that were were spending far too much time fixing bugs. Above sounds very ignorant. Suggested reading for cases like that: Facts and Fallacies of Software Engineering by Robert L. Glass, particularly "Fact 43. Maintenance is a solution, not a problem." Wikipedia article mentions 80% efforts spent on software maintenance. ...


10

Well I tend to use the fingers metric. I hold up my fingers to count and say: Me: "How many offshore testing teams would I consider working with?" Me: "Umm... None." Then the problem of defining other metrics goes away. Now, before that gets marked down... The only reason I would use an offshore testing team, is if I was testing a localised ...


10

The only concrete measure for an employed developer is the number of hours spend coding and fixing bugs, and the money you get paid for it. If you are staying late at night 6 days a week for 50K US$ a year, then you have a problem. No matter how many lines of code your boss want you to be responsible for, you won't handle more than you can do, taking account ...


9

Take a look on Jeff's posts on the subject: A Visit from the Metrics Maid Software Engineering: Dead? There is an old, but good, post from Joel too, closely related to software metrics, and I strongly recommend its reading: The Econ 101 Management Method The key point, for me, is this, quoting Jeff: "Responsible use of the metrics is just as important as ...


9

Yes, if set correctly. If set correctly, the objectives can improve both the team and the individual people. They should be aligned to the job too and designed for the individual. I've been in places where a whole DBA team has the same bland objectives, as well as high level hand me downs such as "conform to global and regional KPIs as determined by the ...


9

The first question to ask is if your "bug fixing" is actually fixing coding bugs or something else. The fixing of actual code bugs should be relatively small in most cases as long as you have a good code base. If you're working with a poor code base, extensive bug fixing is inevitable. However, in the course of putting a program into production, you'll find ...


9

The cyclomatic complexity of the most basic console application is 2 for a simple reason: aside the Main() method, there is also a constructor. It's like writing: public class Program { public Program() { } public static void Main() { } } The first path is to create a new instance of the Program class. This path is taken by ...


9

I suppose it depends on the capabilities of your programming staff, and in no small part on your sensibilities as a manager. Some programmers are staunch advocates of TDD, and will not write any code without writing a unit test first. Other programmers are perfectly capable of creating perfectly good, bug free programs without writing a single unit ...


8

Won't this "source code metrics" crap EVER die? Raw source lines of code (SLOC) is the oldest, easiest, most basic metric there is. Halstead originally proposed a whole bunch of metrics. Lots of people were having lots of fun writing measurement programs until some spoilsport did the obvious study, and demonstrated that each and every single Halstead ...



Only top voted, non community-wiki answers of a minimum length are eligible