Frequently Asked Questions about .CQ

Basically, .CQ is a cloud-based web service that is designed for analyzing a C# software project with regard to its maintainability, combining the findings with user-defined data, and then compiling the overall results into a suitable report. The service will be accessible through a web portal that lets you upload the project's sources, trigger an analysis run, and perform the necessary administrative tasks. After the analysis has finished, you will receive an email with the resulting report.

As of now, .CQ is in its very early development - it's rather a concept than a fully shaped product. This is deliberately so, because the development of the product is supposed to consider user feedback and practical market needs from the beginning.

To learn more about the concepts and motivations behind .CQ, visit the Concepts page. To see a sample report, go to the Report page.

Because .CQ wants to consider the needs and ideas of potential users from the beginning, to build the best possible product. Therefore, it's a good idea to collect user input before development enters its crucial phase. This will both serve as a guidance for further product development and help to avoid investing time and effort in things that later turn out to be less important. (In the language of the Lean Startup movement: This serves to obtain a better product-market fit.)

Please see this question to learn about the various ways to give feedback.

.CQ is in its very early development stage, and further product development will depend to a large extent on the obtained customer feedback. Therefore, the roadmap is not yet very clear. The current plan is that .CQ will go live approximately in the middle of next year (2014).

To stay informed about the latest developments, you may subscribe to the .CQ newsletter.

There are three ways to tell us what you think:

• You can leave a comment directly on the page you're currently at.
• You can take the quick survey for providing more formalized feedback.
• You can discuss with other people in the forums. (There is also one for proposing and voting for specific features that you'd like to see in the final product.)

The input received on each of these channels will influence the shape of the final product.

Code monitoring and software maintenance are hard and expensive. On the other hand, maintenance makes up by far the single biggest portion of a project's total lifecycle budget. So, controlling and improving a software project's maintainability will have a huge positive impact on this budget (or, in other words: it will significantly raise its ROI).

Also, implementing any kind of code quality mechanism is a complex and expensive task that requires huge up-front investments. .CQ wants to overcome these practical problems in providing an affordable and flexible alternative which also fits smaller budgets.

You may read the Concepts page for a more detailed explanation of the motivations and concepts behind .CQ. To see a sample report, go to the Report page.

Basically, the analysis is a two-step process:

• First, some code metric measurements which are especially sensitive to maintainability are applied to the source code. These measurement results then are mapped to software maintainability characteristics, resulting in an overall maintainability score.
• Second, these data - derived from the source code - are correlated with customer-specific data that can be freely defined and entered by the user. (It can be anything that is meaningful to the project, e.g. sales figures, expenses for maintenance activities or the like...)

The results then are presented to the user in a comprehensive report document, which is useful both to developers and for project management.

You may read the Concepts page for a more detailed explanation of the motivations and concepts behind .CQ. To see a sample report, go to the Report page.

Generally, everyone who is involved in (C#) software projects. More specifically, these two groups of people:

• Software developers who work with the project's source code.
• Business executives who are concerned with the financial and strategic aspects of the project.

Generally, .CQ can be used whenever a source code and maintainability analysis of a (C#) software project is needed. While its use is not limited to any specific scenario, here are some of the more prominent use cases that one could think of:

• It can be applied to newly started projects on a frequent basis - for better monitoring development efforts.
• It may be used to analyze legacy projects - for finding potential problem areas and/or receiving guidance for possible refactoring activities.
• It can be applied to outsourced projects - for checking its general maintainability and possibly for defining respective thresholds.

In its first version, .CQ will be exclusively available for C# projects. However, the technology behind .CQ also allows for almost any other language. So, according to customer demand, there may be more to come in the future...

In short, there is none. Not yet. By design.

There is a technical concept, and a general idea of what could work and what is needed, but there is nothing like a business plan or the like. Instead of spending lots of effort to tread paths that might lead you nowhere, it is better to present a preliminary concept to the public and to see what relevant people have to say about it.

The exact pricing scheme is not yet decided upon, as it largely depends on the obtained feedback - just like most other things. Generally, .CQ is intended to be used on a frequent basis (for projects in the development phase), as well as on an as-needed basis (for already existing projects). So the most likely scheme will be a kind of 'flatrate' subscription together with some kind of pay-as-you-go option.

Formally, this website is operated by a company named dotCQ Software Development. As of now, there's exactly one person behind this company: Thomas Weller, who is a freelance software developer and consultant (C#) from Germany (Oh, and don't mind the photograph, it's more than ten years old. It's just that I currently have none at hand that would better fit the bill...).

Personally, my coding was often impaired in various degrees by bad code quality, and sometimes I even was totally frustrated about it. So, over the years, I focused more and more on this specific aspect of programming. At the same time I realized that there was no common understanding among the various stakeholders of what software quality actually is, how it affects a developer's daily work, how it can be measured, and how large its effects on a project's budget can be.

Also, I was missing a solution that is practical, affordable, easy-to-implement and easy-to-use.

Well, .CQ simply is an acronym for .NET Code Quality. - Sure, the concepts behind.CQ are in no way limited to .NET, but this is where it, historically seen, came from...

Generally, the .CQ service will be exposed through a RESTful Web API. This kind of architecture allows for calling .CQ from any context and to build any kind of client application that you can think of. When the analysis report becomes available then, the user will be notified. The following diagram illustrates this:

Because of its flexible architecture, it will be possible to integrate the .CQ system with any available technology. - Of course there will be a website, but you could also think of e.g. IDE plugins (for development), a command-line client (for Continuous Integration), etc. What exact kind of clients will be made available or scheduled for development, largely depends on the requirements that will be expressed via feedback.

Also, various different notification channels are imagineable (e.g. EMail, SMS, Twitter...). Just like the client technologies, it will depend on feedback what channel(s) will be implemented in the end.

First of all, it has to be stressed again that the Calculator on this website can only give you a rough estimate of what the likely consequences of code quality improvements might be. On top of that, a more appropriate calculation would take dozens of company- and project-specific aspects into account, and therefore might come to different results (In fact, for bigger projects, it is strongly advisable to invest upfront in more carefully assessing the project). However, the calculation is based on industry-averages and some reasonable assumptions, and therefore gives you some suitable indications of what can be expected in terms of costs and maintenance effort.

Basic Assumptions

• One man-month is calculated with 160 man-hours (8 hours per day, 20 days per month).
• In C#, one Function Point on average is roughly equivalent to 55 Source Lines of Code (SLOC). ¹
• In C#, it roughly takes 15 development-hours to produce one Function Point (FP). ²

--------
¹ Function Point Languages Table
² The Comparative Productivity of Programming Languages

Project Size

Before we can actually calculate any further metrics on the project, its size has to be determined. A software system's size can be expressed in one of three ways:

• Physical: in Source Lines of Code (SLOC) - Size _pyhs
• Functional: in Function Points (FPs) - Size _func
• By Effort: in man-years - Size _time

The way in which the system size metric is available to you, depends on the concrete circumstances. However, all the above measures convey the same fact and therefore are easily convertible into each other. The following table shows the applied formulas:

Formulas used to convert the various possible size measures. The leftmost column denotes the outcome type of the calculation, the top row refers to the available input. (The values are based on the data given above.)

-- Note: For your convenience, the next question provides some handy conversion tables. --

Calculation method

Once project size is determined, the concrete calculation method of the Calculator is quite involved. It is based on some industry averages as well as on some reasonable presumptions. With some minor modifications, it essentially follows the method found in this research study:
Ariadi Nugroho, Tobias Kuipers, and Joost Visser. 2011. An Empirical Model of Technical Debt and Interest. In: Proceedings of the 2nd Workshop on Managing Technical Debt, pp. 1-8.

Based on the values from the previous answer, here are two helpful conversion tables to quickly look up the required values (rounded to integers):

Source Lines of Code (SLOC)

Function Points (FPs)