Code Quality

Main Challenges

Meeting our users' expectations

• Originally an exclusive tool on one of OutSystems product lines, our challenge was to replicate its success on a new one where the architecture and conceptual model were different.
• The tool had an adoption rate of 70%, which represented more than 4000 daily code changes based on its suggestions. We knew how critical it was to not let anyone down with the new version.

New ways of design

• Although we ported over an existing tool, we had a different design system for the new product. 
• We moved a standalone tool to an integrated solution in our product’s Portal, with its own rules and constraints.
• Couldn't reuse components and interactions, which meant we had to break the existing product and build it back almost from the ground up. 

Naming issues

• Our users were used to the existing tool’s name: AI Mentor System. But our new product was also targeting new user bases who don’t know it yet. The name had to communicate well its value and appeal both to existing and new user bases.
• Balancing the tool – Code Quality - with the suite it was part of – AI Mentor System – wasn’t always straightforward, knowing the latter is a brand we intended on evolving.

The different pillars support the whole suite of AI products. The team worked on all of them separately.

Acting on known issues

For Code Quality, we didn’t limit ourselves to building the same product we had before. We used the opportunity to go through all the usage data we had already and talk to some of our power users, who often are very vocal about what’s not working or opportunities for improvement.

One of the new key features we’ve introduced was a whole activity log with a commentary mechanism, which allowed teams to more efficiently communicate as they addressed the technical debt in their code.

This included adding a reason and explanation to each technical debt finding addressed, a tagging system to guarantee key changes stand out on the activity log, and the capability to add comments beyond any finding status change. All of it was based on the feedback that teams often worked together on addressing technical debt and were finding it hard to know who did what already during that time.

Other projects