38

Technical debt is just an abstract idea that, somewhere along the lines of designing, building, testing, and maintaining a system, certain decisions were made such that the product has become more difficult to test and maintain. Having more technical debt means that it will become more difficult to continue to develop a system - you either need to cope with ...


29

I think the metric you are looking for is LCOM4, although it applies more to classes. Sonar explains it nicely here: ...metric : LCOM4 (Lack Of Cohesion Methods) to measure how cohesive classes are. Interpreting this metric is pretty simple as value 1 means that a class has only one responsibility (good) and value X means that a class has probably X ...


23

Sonar has a technical debt heuristic as well as several other features useful to a software project. It also supports a pretty wide range of languages. SonarQube (formerly Sonar) is an open source platform for Continuous Inspection of code quality... Support 25+ languages: Java, C/C++, C#, PHP, Flex, Groovy, JavaScript, Python, PL/SQL, COBOL, etc....


21

As noted in the comments, size of the binary could be very important for some embedded systems - especially old ones. However, as you've noted in the update to the question There is no customer or product driven arguments for it. It is a big server that is installed as singleton of a dedicated machine, where the executable size is completely ignorable in ...


17

One measure that Michael Feather's has described is, "The Active Set of Classes". He measures the number of classes added against those "closed". The describes class closure as: A class is closed on the date at which no further modifications happen to it from that date to the present. He uses these measures to create charts like this: The smaller ...


16

Afferent coupling: Number of responsibilities Efferent coupling: Number of dependencies Instability: Ratio of efferent coupling to total coupling (Afferent + Efferent). Instability is supported in various code metric tools.


11

Whenever I hear of attempts to associate some type of code-based metric with software defects, the first thing that I think of is McCabe's cyclomatic complexity. Various studies have found that there is a correlation between a high cyclomatic complexity and number of defects. However, other studies that looked at modules with a similar size (in terms of ...


9

Measure technical debt in terms of the amount of work required to eliminate the debt: if it'll take you and your team 3 months to get your code to the shape you'd like it to be in, you've got 3 team-months of debt. The cost of carrying the debt, like interest on a loan, is the amount of extra work that you incur due to the debt: if 50% of the work your team ...


9

Thilo's answer is probably most accurate historically, but the "negative code" metaphor can also include performance and memory use - rewarding efforts to defer execution or allocation of something until it is actually needed. This "procrastination pays" mentality produced such tongue-in-cheek axioms such as "Doing nothing is always faster than doing ...


8

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 ...


7

I have discussed possible correlations in one of my blog posts: Correllation between Cyclomatic Complexity and Bugs density: Is this the real Issue? The answer is no. Keeping the size constant, studies show no correlation between CC and defect density. However, there are other two interesting correlations to study: The first one is: Does CC ...


7

The paper posted in John R. Strohm's answer is somewhat misleading. Although I don't disagree that there is a relationship between cyclomatic complexity and lines of code, it looks like cyclomatic complexity has been misused by applying cyclomatic complexity at the project level. First, cyclomatic complexity should be applied at a method level, not a ...


6

LCOM4 is the fourth version of LCOM. See http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4, under the subheading "Readings for LCOM4."


6

There is a metric of cyclomatic complexity per source statements - it's called cyclomatic complexity density. This metric can be used to estimate the maintenance time and effort required for software projects.


6

There have been a few changes and updates, so I'm going with rev4 of your question. The main argument for this practice is that -Os binary size correlates with code complexity. You're asking size-optimized binary size to act as a proxy for code complexity; from version to version that number can go up or down. If you said that observed "up" ...


5

In between developers a fairly reliable measure of technical debt seem to be WTFs/minute. Issue with this "metric" is that it is typically rather difficult to communicate "outside". Metric that worked for me in communicating technical debt to "outsiders" was amount of testing and bug fixing effort (especially for fixing regression bugs) needed for ...


5

I hate to use an analogy from finance but it seems really appropriate. When you're pricing something (assets of any kind), it can have both intrinsic and extrinsic value. In this case, the existing code has intrinsic value which would be a quantity corresponding to the relative quality of said code and it would also have extrinsic value (value from what ...


5

Code metrics are simply sensors that indicate when something is out of an expected range. Taken in isolation, they really aren't that interesting as you point out, you can already guess at what it's going to tell you. They become more interesting when you start to compare trends. This is one area where Continuous Integration/Deployment environments start ...


4

I think the question is how much would it cost to "buy back" your technical debt--that is, how much work is it to fix it? Well, it's up to the team to figure that out. During sprint planning, I ask the team to estimate the complexity of fixing technical debt items in the same way they would estimate the complexity of a user story. At that point, it's a ...


4

As long as there is a relatively consistent mapping of features to classes, or for that matter, file system you could hook something like gource into your version control system and very quickly get a sense on where most of the development is focussed on (and thereby which parts of the code are the most unstable). This assumes you have a relatively tidy ...


4

It all depends how they intend to use your answer. One person might "bucket" responses as follows: 100 lines or less: all you have written is demos or school assignments. Unless it's a language designed for little scripts, you probably don't know it thoroughly or work with it regularly. 100,00 lines or less: you write normal sized programs and probably ...


4

Just because the programming language abstracts the branches away into a boolean expression, doesn't mean they aren't there. If you looked at what actually gets executed, it looks like this: +-----------+ |is A true? +------------------+ +----+------+ | | | +-...


4

Code metrics are most useful for large code bases where you may not be able oversee or even know about each part of the code. Usually these situations happen when you have to work with code you have not written yourself. It gives you a good indication on problem areas in the code. In your question I read that you have expected certain values at certain ...


3

It just depends. If all your program does is Console.WriteLine over and over.. chances are it won't have any bugs no matter how big it gets. If you're writing the next great document database, chances are you'll have a lot of bugs. You couldn't scrape this information from github because you don't know how hard the problems people are trying to solve.. If ...


3

There are three issues with this question. 1. LOC Lines of code is a terrible measure, especially with the assumption that more lines is better than less. Imagine two students who are asked to solve the same problem. One starts writing code, and during the entire exercise, writes more and more of it, never reading it. At the end of the exercise, the code ...


3

In the book Code Complete, p.457, Steve McConnell says that "control-flow complexity is important because it has been correlated with low reliability and and frequent errors". He then mentions a few references that support that correlation, including McCabe himself (who is credited with having developed the cyclomatic complexity metric). Most of these pre-...


3

I think that, It's not the number of hours that the coder worked on but number of project he worked upon which consist of complex tasks and how he handled those different tasks. How he can break the complex task into small pieces and can build it up from scratch using reusable code. How much he understands programming concepts and best practices while coding....


3

@jwenting is right that the number of lines should not be the primary reason for refactoring methods. Nevertheless it is a often an indicator for a "code smell". And when the situation is so clear as in your logging example, where the SRP is clearly violated, the method should be refactored. So your main criteria for "when to refactor" should be the SRP ...


3

The general approach to measure these figures is: Establish a test plan with sufficient coverage. Execute the formal test plan (could be automated or manual tests), and register the failed test and if necessary the bug reports issued after root cause analysis. Compare the figures with the KLOCs which can be computed automatically from source code. ...


2

As noted in a previous reply, this statement in the accepted answer is clearly incorrect. The ratio has about the same prediction ability as either used separately. CC density has been found to make sense by various researchers, although it does not seem to have gained significant popularity among practitioners. There is evidence from two well-known ...


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