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 ...
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 ...
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 ...
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 ...
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.
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 ...
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 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 or ...
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....
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 ...
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 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 ...
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 ...
It's important that all code base is shared and visible to the team.
Promote pair programing.
Use a static code analyzer, this tools are configurable and come with a preset set of rules that can be tweaked.
Integrate the SCA to the continuous integration workflow and publish automatic semaphore reports visible to anyone.
Don't do this. You're not going to like this, but you're missing the point of story card sizing. It's NOT to measure productivity. It's to measure relative complexity of work. These are not the same thing, and never will be. See, there's a fuzzy correlation between requirement complexity and time to completion, but that's ALL that it is. Your goal ...
Your characteristics of unit tests are missing some of important features in my opinion:
Reflects and traceable to requirements
Tests all of the requirements for that unit under test
Covers all corner cases
Tests every line of the code & possibly every decision path
The main point of a good test is that it fails when something is wrong and not when ...
Here is a counterexample for your senior architect: Suppose I want to write a hierarchy of three classes, two of which derive from the third, implementing some virtual functions that the base class defines.
If I write these three classes in C++, that's pretty straight forward. I declare the classes, use virtual at the correct places, and be done.
If I ...
I'll be the contrarian.
We track SLoC at our job (although we don't use it directly in staffing decisions), and I've had people argue what most people are saying in their answers. In effect, "LoC doesn't matter because X technology lets us do more with less code" or "Better developers write better, shorter code, and so they don't write more than anyone ...
Being 'the other guy', I'll answer here, and be precise about what I say (which I was not particularly precise with over on other formums).
Using the code example above, I calculate the cyclomatic complexity as 8, and I have comments in the code to show how I calculate that. To describe the paths I will consider a successful loop through all the thro() ...
There are a few metrics that we used at my last job to evaluate QA:
Number of bugs found. I hate this one. It's like "Number of lines of code written" for a developer.
Number of automated test cases produced.
Percentage of total application covered in functional testing.
Number of bugs found in staging vs production.
In the end, your QA team's job is to ...