Home Customers How Bliss Applications uses Codacy to achieve engineering excellence

How Bliss Applications uses Codacy to achieve engineering excellence




We spoke with Nuno Ribeiro, DevOps Team Lead at Bliss Applications, about how Codacy helps them achieve an engineering service of excellence. We also received further information from Diogo Cunha, CTO at Bliss.

About Bliss Applications

Founded in 2009, Bliss Applications creates digital products for the various needs of their world-class clients, within different industries. Bliss Applications is part of the WYgroup, one of Portugal’s largest digital marketing groups.

The main programming languages used by Bliss Applications’ development team are C#, JavaScript, Swift, and Kotlin. In addition, they use GitHub as their version control system.

Main goal: having an engineering service of excellence 

Bliss Applications was looking for a solution to improve their development processes and the quality of their code. They also felt the need to have coding standards to help them maintain a consistent and readable codebase. 

As Diogo explained, “Having an engineering service of excellence is the goal that led us to go for a tool like Codacy. We needed to maintain standards in check as the team grows and have some refinement on the KPIs that allow us to go about our thought process.”

The road to excellence

Realizing that linters are not enough

Linting tools, also known as linters or static analyzers, help automate the code review process. They perform basic static code analysis by flagging programming errors, bugs, style issues, and security vulnerabilities early. At Bliss Applications, linters were being used in every project. As Nuno explained, “Code linters were configured on a per-project basis, and almost per developer basis. Each developer that was responsible for a specific project had the responsibility of having code linting, on that project.”

However, linters might not be the best choice for long-term or for more sophisticated software development. They can be difficult to manage, and there might not be standardization across the organization. As Nuno confessed:

“People were encouraged to use these linters, but there was not a standard that was applied across the entire company. So it was a bit difficult to manage and to have an idea of how good the quality of the code is, and the number of issues and code smells that existed on each project (…) even if the team leaders would look at the project from time to time and see if everything was okay, and look at the linters, it was very manual. So it was complicated.”

Bliss Applications understood they needed a centralized approach, so they experimented with some tools. As Nuno explained, “We liked the fact that it was a tool that was centralized, and gave us the capacity of having feedback on each code commit, for instance.”

From a competitor tool to Codacy

Although Bliss Applications liked what was being returned by the tool they were testing, it proved to have several drawbacks and limitations that were hard to overcome. Nuno confirmed that “it was a bit complicated to set up; we had to spend some time setting up and maintaining it.”

That was when they found Codacy, and it was love at first sight. As Nuno explained:

“We tried it for about a month. And we liked it immediately because it was a lot easier to set up. It gave us a lot of visibility into the quality of the code and all the tools it had for code linting and static analysis. (…) We knew that it [Codacy] was a keeper.”

Codacy’s 5-minute onboarding experience and its powerful features wrapped in a beautifully designed UI made the transition easy. Plus, Codacy’s pricing model was an advantage. The previous tool charged per lines of code that were processed and analyzed. Quoting Nuno, “if we want to put all the projects on that tool, we felt that it might be a big expense on the project.”

As such, having a pricing model based on seats was a better fit for Bliss Applications’ needs. As Nuno stated, “we have cases where developers work on two or three different projects. So we pay for one seat, but three projects are analyzed. On the other case, we had almost to pay per project because it was analyzing all the code lines from different projects, even if only one person was using it.”

From Bitbucket to GitHub, with Codacy

Bliss Applications not only changed from a competitor to Codacy, but they also changed Git provider: from Bitbucket to GitHub. 

At the time, they were already using Codacy, and changing Codacy from one Git provider to the other was an incredibly smooth process. As Nuno pointed out, “We started with Bitbucket, and we configure it [Codacy] very easily and fastly. But then we migrated to GitHub. We almost didn’t have any trouble because it was also very fast and very easy to migrate from one to another. So we had no issues with the first implementation, and the migration was very easy. People really enjoyed it.”

Coding standards – the path to follow

Code standardization across projects and teams was one of the building blocks for the engineering service of excellence that Bliss Applications aimed to achieve. Codacy helped them with this process. 

As Nuno stated, “The fact that we could create a standard that was applied across projects, meaning that we have visibility of what were the rules that were implemented for all the projects, and having that set up equally for projects from the same technology stack, it was a big advantage (…) So we have company-wide quality and rule bases for all projects.” 

Having the standards in a centralized tool also meant that checking if everything was set up correctly was no longer the responsibility of a single developer. As Nuno said, “we don’t have to go project by project; we can just implement that and then go to Codacy dashboard. We can also just watch the notifications we receive or go to GitHub and watch the feedback from Codacy, and it’s a lot easier to see how the projects are doing. Basically, it gives us easy access to that visibility.” 

The visibility provided by Codacy is a big plus for Bliss Applications. They see having all the information in the same place as a significant advantage. As Nuno pointed out:

“I would really enforce the fact that having this tool, and being able to implement it across projects, and having something where we can view the quality of projects, the quality of the code, the code smells, all the linter rules… all of that on a single page, and across all of the organization, it’s really exciting.”

People’s time on code reviews has also decreased because Codacy will flag them if something goes wrong or is not up to standards. As Diogo added, “I felt people had a bit more awareness when the code was not being committed to the standards. This decreased the time invested by actual people when looking into PRs because some of the work was already automatically done.”

Codacy onboarding  – the beauty is in the simplicity

With more and more projects and people being onboard to Codacy, the tool is an integral part of the development process at Bliss Applications. So do the developers need an explanation on how to use the tool? According to Nuno, not really: “For Codacy, we don’t have a specific tutorial on how to use it, and we don’t really explain it (…) because it’s very simple to use. And if the developer has used code linters before, even if it’s only local in his machine, he will understand the concept itself.” 

Codacy helps Bliss Applications without getting in the way. It’s a very straightforward tool to use, and developers are seeing the benefits of using Codacy. Quoting Nuno, “Everyone is using it without an issue. Some people are now asking to join (…) So I think that bit by bit, people are starting to understand the importance of this, and some people may be talking to each other and are starting to feel the need also to have this tool.”

Changing developers behavior 

Developers are pleased with Codacy because the tool allows them to write better code while maintaining peace of mind. They know that Codacy will flag them if something goes wrong and will even give them suggestions on how to improve. As Nuno commented:

“There is a general appreciation [for the tool]. But people also find it interesting that Codacy adds comments to analyzed commits on GitHub. After a few seconds, you have not only your code analyzed in terms of issues but also comments on each issue and how to solve them directly on GitHub on each PR. And people find that funny, in a good sense.”

The usage of Codacy can even influence behavioral changes in developers and promote healthy competition among them. As Nuno pointed out, “People really like to see their quality codes with a grade A. Sometimes when I configure a new project in Codacy, the first time they [the developers] look at it, they start comparing the quality grades to other projects. They say, ‘Hey, that project is quality A, we are in quality B, we have to improve this.’ So it’s also creating a sense of good competition inside the company.”

Developers started incorporating the feedback provided by Codacy and taking action based on that feedback. As Nuno told us, “People are looking at what the tool is saying, what the tool returns in terms of the code issues and are actively looking at it and have that responsibility of fixing those issues, no matter how big or small they are.”

Future directions for Bliss Applications and Codacy

The next step for Bliss Applications is to expand their usage of Codacy to even more teams working on different projects. It’s also time to aim at bolder goals and unlock the full potential of using a tool like Codacy.

We look forward to seeing what Bliss Applications accomplishes in its mission of helping clients follow their bliss. Always with an engineering service of excellence in mind.


Please enter your comment!
Please enter your name here

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Recent posts

Codacy Quality: the best solution to ship higher-quality code

Did you know that the average developer spends 42% of their week working on code maintenance? Although unplanned work will always...

Becoming a Code Review Master

On September 20th, we did a webinar called Becoming a Code Review Master. Guest speaker Curtis Einsmann, former AWS engineer and...

Announcing our Series B

Hi there.  Today we’re glad to announce that we raised our Series B of $15M led by...

How to tackle technical debt (for teams using Scrum)

Technical debt happens in all software projects, regardless of the programming languages, frameworks, or project methodologies used. It is a common...

Who should care about code coverage

Code coverage tells us what percentage of our code is covered by tests. There are different code coverage types, and a...