{"id":3934,"date":"2014-06-24T09:00:14","date_gmt":"2014-06-24T12:00:14","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=3934"},"modified":"2018-09-24T14:47:25","modified_gmt":"2018-09-24T17:47:25","slug":"the-symptoms-of-low-internal-software-quality","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2014\/06\/the-symptoms-of-low-internal-software-quality\/","title":{"rendered":"The Symptoms of Low Internal Software Quality"},"content":{"rendered":"
\nThe first post of Low Internal Software Quality series.\n<\/div>\n

Not only physical matter deteriorates, software does too<\/h3>\n

It’s known that physical matter deteriorates. People accept that and have always dealt with it. What people don’t accept so easily is that software “deteriorates” too. Unlike physical matter, it doesn’t happen due to some physical or chemical phenomenon. It usually happens because of some business change or people change. Let me give you an example.<\/p>\n

Imagine you’re leading the tech or product team of a startup; you’re the CTO. You already launched your product’s first version, and it was a success. Your business model was validated, and now you’re in a growth stage. That’s awesome! But it has its costs, and it brings a new set of challenges.<\/p>\n

The first version of your product is working, but the codebase is not in the shape you’ll need from now on. Maybe your team’s velocity is not as good as it used be. Your team keeps complaining about the code quality. The CEO and the product director want new features, and your current projections will not meet the business needs.<\/p>\n

It’s not uncommon that one of the main sources of all these problems is the poor quality of your product’s codebase. You may need a refactoring<\/a> 1<\/a><\/sup> or a rewrite<\/a>.<\/p>\n

When the codebase is not in good shape, everyone can get frustrated<\/h3>\n

If the internal quality of your product is not good, everyone becomes frustrated.<\/p>\n

Your whole team, including developers, will get frustrated because they would like to ship features faster, but the current code quality and architecture are not helping.<\/p>\n

The IT, product, and software departments suffer because they’re not able to meet the expectations of the other departments.<\/p>\n

The customer also suffers because of frequent bugs, how long it takes for them to be resolved, and how long it takes new features to be launched.<\/p>\n

You get the picture.<\/p>\n

Identifying the symptoms<\/h3>\n

It’s the leader’s job (let’s say the CTO) to identify when a refactor<\/a> or a rewrite<\/a> is needed. In order to do that, he or she can look around for some symptoms, like the ones below:<\/p>\n