20

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


15

Just like a unit test should test behaviour not implementation your department should measure the anticipated result of the policy, not implementation of the policy. Your department wants to move to TDD. Why? What is it you're hoping to achieve through TDD? Fewer bugs raised that are regression related? Faster velocity on cases? Then you should measure ...


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


10

There's no way to accurately do this. For example, who contributes more: someone who commits 1000 lines of code in a month, or someone who spent most of his time thinking really hard, and then committing 100 lines of code that replace the 1000 lines of code? Or how about somebody that goofed off most of the month, then found those same 100 lines of code in a ...


8

Not only is it hard to say, but the answer is not very useful. Even highly experienced developers find it difficult to estimate how long a given project will take them. This is largely because the programming process consists mainly of understanding the problem fully, and elaborating a solution. The hard part is the full understanding. Writing the ...


7

If you use vector algebra (which is easy with a vector algebra library), there is no real difference between the 3-d case and the N-d case. Unfortunately, the page you link to has written out the vector math element by element, which tends to obscure this. So, paraphrasing from the article: given a line through two points A and B, the minimum distance d ...


7

There are a number of metrics that can be gathered from code reviews, some even extending throughout the lifecycle of the project. The first metric that I would recommend gathering is defect removal effectiveness (DRE). For every defect, you identify what phase the defect was introduced in and what phase it was removed in. The various defect detection ...


6

The project is complete when there isn't anything left to do that the project sponsor is willing to pay for.


5

I've found that if you can provide valid numbers, managers are more likely to act. (If they can understand the logic and the cost/benefit.) IMHO, to make a convincing case, you would need the following to show how bad it is: number of support incidents logged for the issues time spent in hours maintaining/band-aiding bad code/doing support fixes time cost ...


5

It could just be a correlation. Management tends to assign more people to help on projects they deem will be more complex, or projects that are falling behind due to lots of intransigent bugs, or projects that require a lot of coupling between various components. If you could take management decisions out of the mix, I suspect that correlation would at ...


5

Microsoft Research has done some work in this area. Check out this page: http://research.microsoft.com/en-us/people/nachin/. Though not specifically based on Halstead, Nachi and his team have done some investigation using Halstead, cyclomatic complexity, code churn, and other measures to assess relative risk and fragility for making changes in areas of code. ...


4

I also wonder if this a dangerous idea, that if objective proxies for quality become popular that business pressures will cause developers to pursue these metrics at the expense of the overall quality (those aspects of quality not measured by the proxies). Bingo, and no "if" about it. This is called "Measurement Dysfunction" and has been observed and ...


4

In a plan-driven methodology, where you have the complete requirements up-front, a complete project would satisfy all of the requirements and pass the specified unit, integration, system, and acceptance tests. In a perfect world, the project would end at the end of the plan. However, the health of the project should be tracked as part of the plan, allowing ...


4

Square metres stored as an integer may not have enough resolution to capture what you need to know. Converting to and from square feet or metres will lose information. Use floating point values to prevent this issue. Use whichever unit your primary users are likely to want for storage. If you are only targeting a US/UK market (where square feet is the ...


4

If your app will potentially be used outside the USA, Myanmar or Liberia, or will it interoperate with other systems, I'd suggest you use the more widely accepted measurement system to store the data and then convert it to whatever local mesurement system the user wants to display. Obviously the columns shouldn't be integers but real. The metric system is ...


4

what does it mean by "clearly defined rules"? It means rules that are clearly defined. For example, Source Lines of Code can be defined as physical lines of code (the number of lines separated by a carriage return), or the number of logical statements. Your assessment of the size of a program would depend greatly on which definition you use. is “blue” ...


3

It is hard to tell what metrics to collect for an unknown project with unknown goals. I would strongly recommend you to take a look at some kind of goal definition approach (such as GQM). Using this methodology you might come with metrics that best suit your needs. Basically, GQM (goal, question, metric) defines a process where: you first define your ...


3

Given the recently updated definitions of size and effort, I would suggest that perhaps the results are due to the fact that Effort (total man-hours) is actually a better estimator of true project size than the measures the source is using (Effort would be a perfect measure if all teams and team's resources were equivalent). Therefore what is really ...


3

There are metrics or proxies for many of the qualities you are interested in: Lines of code Fan in, fan out Error rate per 1000 lines of code Cyclomatic complexity Code coverage Decision point coverage Ratio of errors fixed/introduced by maintenance activities Function point analysis There are some issues with all these items: Work being done to optimise ...


3

What I'm interested in is a deeper form of quality related to the network (or graph) of types and their inter-relatedness, that is, what types does each type refer to, are there clearly identifiable clusters of interconnectivity relating to a properly tiered architecture, or conversely is there a big 'ball' of type references ('monolithic' code). This ...


3

One great resource: http://bigocheatsheet.com/ I can tell you right off the bat that: Bubble Sort is in worst case, O(N2) Insertion Sort is in worst case, O(N2) Selection Sort is in worst case, O(N2) Quick Sort is in worst case, O(N2), yet is typically O(n log n) Merge Sort is in worst case, O(n log n)


3

When you find a statement like "M number of comparisons" about sorting algorithms in literature, the author typically means the number of comparisons between the sorted elements, not the comparisons of something like loop indexes. So if you are asked this in a university assignment, I would guess that this is the number which is meant (but to make that clear,...


3

Neither. Since you are asking this question, you are probably working on a system which uses both (or a system which will be used in different countries). This means that you should be able to store distances expressed in feet or meters. In your database, do have not one, but two columns: one for the value, the other one for the unit. This would make it ...


2

Keep in mind that refactoring introduces bugs as well (which you will catch in your testing, but nonetheless are bugs and must be fixed). Don't pull a Netscape on accident. It depends on your personal definition of "refactoring." To some, this means "rewrite all the code" to others it means "change some internals." How do you tell what kind you are? Ask ...


2

There's a difference between correlation and causation; the quote seems to be saying that the total number of defects tends to be higher for projects where larger numbers of engineers are allocated. This makes perfect sense to me, I am sure MS Windows has more defects than the applications that I create, but that doesn't mean that my applications are ...


2

This seems counterintuitive, assuming a good process and capable engineers. I do not think you can assume either of these in the real world. The more people on a project, the more likely you are to have bad apples who cannot keep up and will slow down the best developers. Even if you go with the assumptions there are a few other things that slow down ...


2

Sounds like you might be over thinking it a bit, but we programmers do have a habit of doing that. Track a list of requirements. When you can mark of each requirement as tested and implemented, begin system testing the project.


2

If you have to ask the question, you don't have a project, as a project needs to be defined (think SMART Goals - Specific, Measurable, Achievable, Realistic, Time framed.). You either have a list of requirements and/or deliverable items that must be achieved, in which case it's complete when these are done. If you don't have these, you don't know what you ...


2

While largely it is true that code review would pick up problems which are rather latent that testing may or may not catch. However, in my opinion you may have a really stable (practically bug free) code but still written in such a way that it is extremely non-readable or not quite maintainable. So it may be that code review may NOT find bugs if there are no ...


2

You could be obsessed with metrics, or you could be obsessed with the best people, tools, practices for engineering and QA that you can afford. I would be much happier having several paranoid QA geniuses who have read 'Fooled by Randomness' and who like to automate than a bunch of nicely formatted reports with numbers.


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