5 ideas you should know about software quality 💡
1. Continuous Integration (CI)
Continuous Integration is a software engineering practice of merging all working copies of code into a shared repositories frequently, preferably as soon as the code change is verified for correctness.
A key benefit of doing this is that errors can be detected quickly and it becomes easy to debug and fix them — since each change introduced is small, and it’s easier to vet small changes as compared to large ones.
A complementary practice in CI is to add test coverage alongside the proposed change. Typically, developers ensure that unit tests are present and passing for the proposed change. Integration tests are usually run automatically on a CI server whenever the change is pushed to upstream. View full definition.
2. Continuous Delivery (CD)
Continuous Delivery is a software development practice that enables teams ensure that their code is always in a deployable state. Even when a large number of developers are making changes to the code, Continuous Delivery ensures that the latest code with the changes is always ready to be deployed.
Implementing Continuous Delivery is often complemented with Continuous Integration, which ensures that the latest code is always correct. Adding Continuous Quality in the development pipeline alongside these two processes ensures that code is defect-free in addition to being correct. View full definition.
3. Continuous Quality (CQ)
Continuous Quality is a software engineering practice in which isolated changes (or deltas) are immediately analysed for the code’s quality and the properties of maintainability, and reported on before they are added to a code base. The goal of CQ is to provide rapid feedback so that if issues are found that can affect maintainability of the code or contribute to increasing the technical debt, they can be identified and corrected as soon as possible.
CQ helps developers identify and fix defects and quality issues as early in the development process as possible. Since most common issues are fixed very early, implementing CQ also improves productivity during manual code reviews, so reviewers can get more time to do high-order qualitative review instead of worrying about worrying about trivial defects. View full definition.
4. Technical Debt
Technical debt quantifies the implied cost of additional software maintenance required in future because an easy, ad-hoc solution is chosen now to deliver software faster. It is a leeway that has been taken to ship things today, hoping that the time saved would bring returns in future, and the debt can be repaid. The additional maintenance work that must be performed in future to compensate for the ad-hoc decisions taken is called interest. If the interest is not paid, it accrues over time and makes it difficult to implement changes later.
Incurring technical debt is often a necessarily evil, since it helps deliver software faster. The adverse effects are caused primarily due to non-repayment of the interest and inability to implement good software development practices. View full definition.
5. Software Rot
Software rot or software decay is the slow deterioration of software performance over time leading to software becoming buggy and unusable, eventually.
When a system is created, it is generally designed to solve a known set of problems encountered by an existing set of users. Over time, the tool creators, original users, and the current problem domains change but often the old system is modified to solve these changes. A flexible system may be adaptable to certain amounts of change, but only if the current populace of creators/maintainers as well as users understand the limits. If they do not, the software often ends up less useful than if it had never been touched. View full definition.
Discover more ideas and definitions related to software quality and maintainability in Software Maintainability Glossary.
