Why does BonCode focus on maintainability of software, I’m more interested in the changeability of my software?

Good question, as you could for example also ask for the performance or security of the system. We believe maintainability is even more important because it is the prerequisite for all quality aspects. Software that is hard to maintain will have a negative impact on the scalability, security, adaptability etc of the system.

My software development environment also has the possibility to measure quality, what does BonCode add to this?

Software development environments (SDE) report to individuals who specifically use the SDE and are not adapted to managers, including project managers or CIO’s. BonCode provides quality measurements aggregated and adjusted to the level of the different stakeholders. From engineering level to boardroom and thus providing one integrated version of the truth in your software project. BonCode should be seen as a quality management system on code-, architectural- and project level.

Can BonCode measure any type of technology, or just some subset?

BonCode’s tooling is technology agnostic, meaning we can onboard almost any technology. Having said that, if BonCode can’t currently measure it today, it might be bleeding edge technology or very rarely used technology, with it’s own risk profile.

What is your business model, pricing model?

BonCode works exclusively on fixed price basis, based on the research question and scope of technology we need to research.

There’s a ton of open source tooling available in the field of software quality, what does BonCode add?

BonCode adds the interpretation of software metrics from an independent perspective. If our consultant discovers the usage of open source software quality measurement tooling within your organization, the first positive observation has been made: you have engineers that are interested in software quality.

Can BonCode provide software quality certificates

No, we can’t and our customers don’t mind. Aiming for certification leads to the certificate being the main objective which often leads to a dogmatic software metric harnass. BonCode believes high quality of software should be the main objective.

Is Team productivity something you can measure in an objective manner?

Yes, that is very doable and usable. The process here is that an a set fixed interval (eg per sprint), we measure all code that has been added, removed or modified (we call this churn). For LowCode platforms like OutSystems we use Automated Function Point Analysis to determine how much functionality has been added, removed or modified. For more traditional technologies we use LOC. If you correlate this with the amount of time your team allocated on the work, the productivty is objectively determined in terms of Funtion Points/hour or LOC/hour. We’ve learned that this type of analysis is very usable for internal or external benchmarking.

Does BonCode also asses security risks?

Yes. Security is a multi-headed monster so we will never be able to provide 100% assurance that a software system is secure. Having said that we do assess security risks on source code and architectural level based on The Open Web Application Security Project (OWASP) or customers own specific policies.

I don’t really like to send my source code to 3rd parties, how can BonCode guarantee it’s safe to upload sources?

This is fully understood, but source code analysis needs source code. We have taken every measure thinkable to guarantee the safety of your code. In highly exceptional situations we use external disk drives on your location.

We use lowcode platforms, can BonCode analyse that?

Yes.

What kind of metrics do you measure? What is the meaning of them?

Hmm, this is asking your doctor what he measures. How to summarize tens of years of science into one answer? In short: we measure what’s needed and our measurements are rooted in ISO25010. We will give three examples: 1. Unit size: the rationale is that the larger the smallest unit is, the lower the readability, testability, and maintainability. 2. Duplication: the rationale is that if you have duplicated code, the maintenance effort is duplicated, the risk for errors is duplicated, etc. 3. Complexity of code: rationale is that highly complex modules are not well understandable, testable, readable and adaptable.

Can I interpret the measurements myself?

Yes.

We develop software in an agile way, so how would software quality be relevant?

Well, working agile means that you apparently acknowledge that your future functional requirements are unpredictable and that you therefore need a software development methodology aimed at adaptability. Shouldn’t your software product not be highly adaptable? That’s what good software quality brings you.

Can we integrate BonCode’s measurements in our own -already existing- quality assurance program? How?

Yes. We export our measurements to any system of your choice.

We have an external service provider developing our software, why should we bother on quality delivered? Isn’t that their responsibility?

Yes, of course this is their responsibility. But in case your external developer delivers suboptimal software, you still have to cope with the effects of that result from there. You can outsource activities, but you can’t outsource responsibility.

We are considering the take over from a company. Can you support us in getting a clear picture of the quality of the software assets?

Yes. It is our specialty to provide fact-based insight in the risks and opportunities of software.