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 ...
The argument of the senior architect could mean two things.
It may mean that an average developer in the company produces more lines of code when using static languages than when using dynamic ones. For instance, if fifteen developers work with Java for six months, they will write 100 KLOC, and if the same fifteen developers work with Python for six months, ...
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 ...
What exactly is the Cyclomatic complexity saying to me?
Cyclomatic complexity is not a measure of lines of code, but the number of independent paths through a module. Your cyclomatic complexity of 17,754 means that your application has 17,754 unique paths through it. This has a few implications, typically in terms of how difficult it is to understand and ...
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 - ...
Cyclomatic complexity is a way to determine if your code needs to be refactored. The code is analyzed and a complexity number is determined. Complexity is determine by branching (if statements, etc.) Complexity also might take in to account nesting of loops, etc. and other factors depending on the algorithum used.
The number is useful at the method level....
You cannot measure and you cannot quantify. Give those ideas up from the beginning. Peopleware goes into great detail about how some people offer value simply by being catalysts for the rest of the team. Those people must not be dismissed because they're not producing lines of code. Likewise, we've all worked with developers who churn out work but are so ...
About productivity and SLOC
The problem with SLOC
The problem with the SLOC metric is that it measures an approximation of the quantity of code written, without taking into account:
the quality of the code (i.e. what if for every 100 SLOC you have to add another 90 SLOC because of bugs, but that you don't know at the moment your code is delivered ?)
Software quality is really hard to measure objectively. Hard enough that there isn't a solution. I'm refraining in this answer to dabble on the question whether there can be a solution at all, but simply point out why defining one would be really hard.
Reasoning by status quo
As Kilian Foth pointed out, if there was a simple measure for "good" ...
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 ...
Code coverage tells you how much of your code is covered by tests. It does not tell you much about the quality of the tests.
For example, a code coverage of, say, 70% might be obtained by automated tests exercising trivial functionality like getters and setters and leaving out more important things like verifying that some complex computation delivers ...
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 test....
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
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");
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.
How It Is
Unfortunately, in most places I've had experience with salary is not so much based on an individual's skill level, but on company policy, local competition and stinginess. Rules are set, the company in question will have a bunch of people who don't know squat about development come up with a pay grade chart. They'll throw a couple levels (i.e. ...
Sadly, I think Location matters most. It factors in to cost of living, but, more importantly, into what companies are hiring.
If you are in a location with multiple technical companies -- companies that live and die on their technical workers -- salaries for the workers will be higher. Competition for the good workers will drive salaries up.
If you are in ...
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.
Good developers are rarer, thus harder to find and hire, than mediocre / bad ones
=> the more ...
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 ...
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.
Yes, you can tell the code has quality problems by looking at metrics to some degree.
More specifically, run a complexity analysis tool on the code base and you will get an idea of whether the code is good or bad.
For example, you could run source monitor.
What this will tell you is how complex the code is. I can tell you every problematic system that ...
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 ...
This observation is very old, and comes from a very venerable source, namely Fred Brooks in his book "The Mythical Man Month". He was a top manager at IBM, and managed many programming projects including the milions-of-lines operating system OS/360. In fact he reported that the number of bugs in a program is not proportional to the length of code, but ...
I'm assuming you are referring to a Code Coverage metric in the context of unit testing. If so, I think you indirectly have already answered your question here:
First project just used targeted unit tests here and there. Second one has a mandated 70% code coverage. If I compare the amount of defects, the 2nd one has almost an order of magnitude more of ...
As a reductio ad absurdum: the following test covers 60% of the lines of the function:
if x < 0:
whereas in this example, we have 100% coverage:
if x < 0:
Of course, only the latter has a bug.
What confuses me about code metrics is that it isn't done more. Most companies report on the efficiency of their employees, suppliers, and systems in place, but nobody seems to want to report on code. I will definitely agree with answers that state that more lines of code is a liability but what your code does is more important.
Lines Of Code:
As 'Ive ...
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 ...
For a rough estimate, use the SLOCCount program written by David Wheeler - it will analyze the lines of code and use industry estimates on programmer productivity to give you an estimate of time and money it would take to build said software.
By default it uses the COCOMO model for cost estimates, but you can customize this.
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 static void Main()
The first path is to create a new instance of the Program class. This path is taken by default ...