Does CodeCaseĀ interpret 100 % of a code?
CodeCase rarely interprets 100 % of a code, and thatās not the objective, but in the majority of cases it gets very close. We often find that code that is not interpreted is useless.
To optimize our coverage rates, we enrich our grammars at the beginning of each project.
How many languages are supported by CodeCase Suite ?
Our CodeCase Suite (Understanding ā Simplifying - Building) understands almost all languages : C#, Delphi, Java, VBA, VB, C++, Cobol, Fortran, C, VB6, etc.
Is the code produced by CodeCase Suite (automatic generation) good quality?
Yes, it is indeed, for two reasons:
- Our code generation base is a specific UMM - our proprietary meta-model : we build a refactored model before every generation of code.
- Each project to generate code corresponds to a specific configuration of the code generation engine depending on the encoding rules used by the customer, special development environments, specific frameworks and best practices.
What exactly does CodeCaseĀ interpret?
CodeCase interprets anything that is described in the form of a code, i.e.:
- non-object-oriented languages
- object-oriented languages
- interactions with data bases (SQL)
- configuration files (XML, CSPROJā¦)
- external dependencies with frameworks, middleware, diverse libraries and the related APIsā¦
- the comments on the code
Why isĀ CodeCase useful for developers?
Developers can instantly measure the impact of any modifications on the rest of the IT system. There is much less trial and error and they can execute tasks related to corrective maintenance and upgrades more rapidly. CodeCase makes it possible to analyse code interactively and choose the level (macro or micro) of analysis. Developers have a uniform interpretation of all the components of an IT system, as well as their relationship and mutual impacts.
After the intervention of CodeCase, are the Customerās IS dependent on CodeCase tools or framework ?
NO. None of our activities introduces any dependency on CodeCase Suite. Intervention by CodeCase does not create any dependency on third parties. The customerās IT system can work without our tools.
How does CodeCase deal with comments?
CodeCase reads the comments and interprets them by associating them with their programming context. For the purposes of interpretation, they are linked to the methods, classes and objects they comment on.
What are the limitations of CodeCase interpretation capabilities?
- dynamic and / or interpreted languages (e.g. Ruby, Python, Objective C, Perl)
- database contents
- the bugs linked to execution of the code (Active Maps conducts a static analysis of the code)
Sales related questions
Do you carry out Proof of Concept tests (POCs)?
We carry out POCs on the customerās premises for all our areas of expertise by jointly defining precise KPIs. In the space of a few days, these POCs enable us to very accurately estimate the technical and financial challenges involved in an IT system transformation project.
What cost savings can be expected from CodeCase intervention ?
For complete transformation projects or the creation of an IT system, we are able to reduce the customerās bill by an average of 45 %.
Customers entrust us with their IT system transformation projects in order to reimburse their technical debt.
According to a survey conducted jointly by GARTNER and CAST in 2011, involving an audit of 750 applications, the average cost per line of code for reimbursing technical debt was $3.61.
With CodeCase, the average cost of reimbursing the debt is $2.
1. An indebted code is rich in embedded āifsā with low automation of unit tests and copy / pastes that do not comply with development standards. It also includes dead code, a high number of comments...
2. The CRASH Report - 2011/12 (CAST Report on Application Software Health)
Do you manage Testing Coverage improvement ?Ā
What is hidden behind the phrase ātechnical debtā?
The term technical debt is used to describe an accumulation of imperfections in an IT project as a whole. The principal characteristic of technical debt is that it remains very difficult to detect and is almost painless: its faults are not visible to users and are not synonymous with bugs. Technical debt is like an iceberg: only the part on the surface is visible. Technical debt is a set of hidden software quality problems, which, like an iceberg can cause a project to crash when they break surface.
What does technical debt look like on an everyday basis to IT teams?
Although it is difficult to quantify, the submerged part is quite visible from a technical point of view: the structural complexity of the code (e.g. a code rich in embedded āifsā and other conditionals, such as while, else, switch, for...), the coverage and degree of automation of the unit tests, the copy / pastes, the lack of compliance with development standards, dead code and the number of comments, are just so many factors that go to make up this debt. The more numerous these factors in the applications, the higher the level of debt.
How does technical debt accumulate?
All these imperfections gradually add up during the lifetime of the project for a number of reasons: sloppy design work, partial (or even non-existent) documentation, lack of time to satisfy ever more pressing business needs and a lack of structural control of the application. Rapid encoding and sloppy design work help to satisfy the time constraints imposed by the business. This is the very way in which, without realising it, we enter into debt, the reimbursement of which is more or less painful throughout the lifetime of the project. A rushed product code becomes a āfinancial burdenā, which creates a debt the future interest on which is reimbursed by all those involved in the project.
The outstanding capital is the cost of refactoring the code into a specific design that is agile to change.
The interest receivable is the additional costs paid if the team has to work with a poor quality basic code.
What are the consequences of technical debt?
These technical imperfections, the submerged part of the iceberg, have direct adverse consequences for the IT Department and the Business as a whole. For the IT Department, the time required for development and adding functionalities is longer and goes hand in hand with a loss of agility to change. Deadlines are missed and the teams become demotivated by the growing dissatisfaction of having to deliver lower quality work. The Business can no longer devote its budget to new projects that add value, but has to pay for maintenance and debugging. User satisfaction declines and TTMs tend to get stretched...