Better understand how we work, and the value we add to you and your company.
Bliss reviews your code quality and searches for common pitfalls before calculating which are the good lines of code.
But how does it work?
We first review the quality of the code itself, ensuring all common industry standards are met. This includes things like code redundancy (unnecessarily repeated code), unnecessary code complexity (it pays to keep things simple), test coverage (to avoid breaking down) and many other best-practices that could cause problems as the product grows.
These red flags give us the bad lines of code and allows us to also see which are the good lines.
Makes sense, but where is the count derived from?
At the core of our calculations is a series of static analysis that is tuned for each language. Depending on a customer’s particular situation, these particular values can be customized and we welcome feedback from everywhere.
As more customers come onboard with Bliss our calculations and comparison data will become more and more accurate over time, lending to even more precise numbers.
In the end, this currently allows us to make two calculations for our customers:
As Bliss grows we hope to better refine these two calculations, but also introduce more ways that non-technical entrepreneurs can participate in technical projects. Likewise, we hope to create real value for developers and technical entrepreneurs by applying code quality tests in real-time and illustrating ways to fix potential problems, as well as calculating (based on comparative data) which problems could save the most money.
Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The term 'technical debt' was first coined by Ward Cunningham in 1992.
Bliss measures technical debt as an accumulation of flags reported by various static analysers run against the code base. These are configured to use the best available analyzers for each language - the details of which can be seen in the code details section.
We attempt to remove all open source and code generated by various platforms before counting the lines in each commit by a developer. As this code has not been written, it is not code that should be considered as effort. Although it may be vital code, and more often preferable than custom written code, we are measuring code written by the developer in this number. If the code written results in limited functionality or features that fail, this is visible progress you can see in the project and we do not attempt to measure this purely from the lines of code.
The lines of code is not the cost to design or plan out the workflow of your application. It is also not the value of the business. If your project looks good and is easy to use, this is already visible when the project is used. We do count and display the mostly invisible act of writing code and tests. Our goal it to allow non technical people visibility into the amount of code and the quality in terms that can easily be understood.
We scan the code for open source and any code that has a copyright message indicating it was included from an open project. If your project was derived from an open source base, we recognize certain open source commits and exclude those from the value and debt calculations. For instance, if you include jQuery or code you did not write, this is not part of your code's asset base and should be excluded. If the entire project is opensource, we are testing adding this as a free service - please tweet to us @bliss_ai to have your project included.
There is nothing wrong with including open source in your project, just be aware of the restrictions this brings. There is good FAQ here that goes into many of the questions people have. Also, there a lawyers who specialize in this area if want to place restrictions on the use of your product and have concerns included open source might prevent you from doing so.
It is common practice to place a copyright statement at the top of certain important files in your project. Developers do this to identify who owns code and the copyright. We scan the code and look for certain standard ways of claiming ownership and extract the owners so you can review. If you see a company name that should not be there, you should look into it as from a code ownership point of view, it looks like they have a claim to part of your project. If this under a license or agreement, that might be fine but we want you to be aware of it.
Code rot is either a slow deterioration of software performance over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or otherwise called "legacy" and in need of upgrade. If the software is in active use, you will probably see this as unhappy customers and an increase in support calls and bugs. Also you will see an ever increasing back log or feature change requests that are not being resolved. more...
We look for code that is test code based on the pattern in the project settings page (e.g. test spec). This code is then weighed against your acceptable level of debt to determine how much test code should be present. As you move away from this target, the project is flagged with test debt. Adding more test code, will remove this debt. As a general guide we expect just over 20% test code. We can also accept test coverage reports from your CI service via a webhook - contact us to set this up.
Queens or Kings are appointed every 20 hours. They consist of king points that are valued in lines of code added or removed (yes removing counts). However, technical debt lines get a 50% boost. If you add 1 technical debt point, you are penalized 1.5 king points. Conversley, removing technical debt (e.g. adding test code, removing complexity) will count 50% more. In most cases, writing some solid tests and removing complexity or duplication, is the easiest way to become and stay king.
Any team member that has access to your projects, can also get the code reports via Bliss. Just have them signup and connect their github or bitbucket accounts, and any projects you have added, will also be available for them (we don't ask for duplicate payments and access is managed from github or bitbucket).
We have included all Californian and federal holidays when calculating times. Your browser has also reported you in the time zone: 'PST'. We will be allowing different holiday sets soon, please contact us if you would like us to add holidays for your region.
We look at best practices given the platform in use. The linter list shows which Best Practices tools are available for the various languages.
We look at whether your software team can scale and issues around code where it might be hard to read, maintain or evolve, rather than things that are specifically wrong. The linter list shows which complexity tools are available for the various languages.
We use static analysis tools which checks your application for security vulnerabilities. The linter list shows which security tools are available for the various languages.
We use static analysis tools which checks your application for code errors and warnings and is an essential development tool that ensures your code remains clean and consistent.
This is where we will be able to report the exact lines and causes for the debt.
It's time to analyse your code! To get started with our automated metrics, we'll need to be able to view your code.
If you have a GitHub or Bitbucket account simply sync your account below and we'll list your projects.
Via the Share settings add "founderbliss" to your repository.Click after shared
"Alone we can do so little, together we can do so much." --Helen Keller