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, ...
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 - ...
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" ...
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....
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 ...
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");
At this point I want to want to device strategies to reward good code.
You cannot. Goodhart's Law will quickly come into play, and your objective metrics will become the things that your developers focus on to the exclusion of all else.
If your management is disconnected from the actual stuff you're producing, or doesn't trust your team leads who do have ...
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 ...
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 ...
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 ...
There are variations based on different coding styles and languages. However, regardless of the language you use, the biggest variation is you.
Robert Martin once said:
“As the tests get more specific, the code gets more generic.”
That made me think. More specific tests mean more test code. More generic production code means less code, so test/code ...
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 ...
There are no predefined categories and no categorization would be possible for several reasons:
Some refactoring techniques just move the complexity from one point to another (not from your code to the framework or a well-tested external library, but from one location to another of the codebase). It helps reducing cyclomatic complexity and helps convincing ...
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 ...
When I understood this correctly, the Cyclomatic Complexity of main is 8 - that is the number of linearly independent paths through the code. You either get an exception at one of the seven lines, or none, but never more than one. Each of that possible "exception points" corresponds exactly to one different path through the code.
I guess when McCabe ...
No. That metric displays a fundamental misunderstanding of both testing and reliability.
Testing can only ever prove the presence of bugs, but never the absence. A test suite demonstrates that a system is capable of functioning as expected (incl. known failure modes), but except in the most simplest cases can never prove that it will always work as designed....
It depends on how much code you have out there, how long it has been out there, etc.
The time spent fixing bugs in software should be front-loaded to the first 6-12 months of release, however as time approaches infinity, the time spent on maintenance versus the time spent on initial development will exceed 100% - that's just the way things work.
While I ...
It is definitely impossible to automatically check code quality, you can only check for some minimum code quality.
Even "experienced" programmers are having trouble to formalize what actually constitutes code quality. And even among the "most skilled" ones, there's a high divergence in opinion on what is good or bad.
There are some obvious rules that ...
Number of test written is useless, and a high number of bugs found can be a measure of poor development rather than efficient QA.
Automation measures (code coverage, feature coverage...) can be good, but I think they're a more help to development (as a developer, will I know if I break something accidentally) than customers (i want to do that and it doesn't ...
You asked two very different questions.
Is tracking user metrics by IP legal?
I'm about 98% sure that keeping your log of HTTP requests and extracting the IP address of each session, and then building a geographic distribution of where your users are based on said IP address is perfectly legal everywhere in the globe.
But asking "is this thing that I'm ...
Researchers tend to say that it takes ten years to develop a deep level of expertise. This equates to around 10,000 hours of learning the craft. How many lines of code can you type in an hour?
It is probably not so much the lines of code, but what those lines of code do. The idea is that each successive target should be a bit more complex and a bit of a ...
You measure it by spending the hours necessary to manage the project.
If you wait until all is said and done, you have no way of pulling statistics out of the final product. You can't even look at the artifacts of the process and measure the contribution levels automatically without falling back on the naive statistics.
As progress is made during the ...
There are many ways to measure quality. None of them are perfect: if start thinking in absolute terms, you can create new problems. Here are a few metrics that are commonly used:
LOC per class/method
There are also binary measures that can be used as 'gates' such as conformance to standards ...