<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Internal Quality on JAVAPRO International</title><link>https://javapro-en.svenruppert.com/tags/internal-quality/</link><description>Recent content in Internal Quality on JAVAPRO International</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 18 Jun 2025 07:00:01 +0000</lastBuildDate><atom:link href="https://javapro-en.svenruppert.com/tags/internal-quality/index.xml" rel="self" type="application/rss+xml"/><item><title>Should we stop discussing about technical debt... with top management?</title><link>https://javapro-en.svenruppert.com/should-we-stop-discussing-about-technical-debt-with-top-management/</link><pubDate>Wed, 18 Jun 2025 07:00:01 +0000</pubDate><guid>https://javapro-en.svenruppert.com/should-we-stop-discussing-about-technical-debt-with-top-management/</guid><description>&lt;p&gt;Cyclomatic complexity, coupling and cohesion, orthogonality, big O… are concepts that technical teams use when analyzing complex software systems and can establish why it is difficult to change them. Technical language refers to the technical aspects of those systems. But when we have to explain to non-technical people in the organization why an application has bugs, why a feature is not on time, or why we need a database expert to make a simple change to a service, we cannot use those concepts. To do that, we have to speak in a language that those non-technical people understand the intrinsic nature that exists in systems developed with software.&lt;/p&gt;</description></item></channel></rss>