Internal Software Quality & Messy Code
Internal Software Quality and Technical Debt are two concepts that are tightly linked: if we can measure the technical quality in our messy code, we can then start to measure the technical debt. Join the conversation on the relationship between Technical Debt and quality in software development. If you are interested in blogging for us, let us know!
By Frances Lash | April 2, 2015
This post seeks to respond to a question on how to restructure a poorly formulated monolith, and whether reformulating it into another poorly formulated set of microservices is ever the correct answer. This question is used to highlight the idea that a team which is incapable of creating a well structured monolith probably won’t be ... read more
By Frances Lash | April 1, 2015
In this post the question “how to create value for businesses at a time when labour arbitrage in the outsourcing industry has plummeted?” is looked into and one of the strategies that has been employed is to reduce technical debt. Business productivity is directly linked to application software health, which in turn depends on code ... read more
By Frances Lash | March 25, 2015
This post beings with an interesting statement: that in a start up environment technical debt often feels inevitable. Technical debt can be seen as a function of moving fast, minimum variable products (MVP), prototypes, agile practices, and of releasing the product to market as soon as possible.
The idea of using a minimum variable product to ... read more
By Frances Lash | March 17, 2015
This post describes a new term related to technical debt: technical embezzlement. In order to further define the term, building off of technical debt is necessary. Technical debt refers to the eventual consequences of poor system design, architecture, or development in a codebase. If this debt is not repaid it begins to accumulate interest and ... read more
By Frances Lash | March 13, 2015
Technical debt is usually incurred when a team consciously makes the decision to put in less than optimal technical work for the short term gain of their project. For example, the team may not put in depth automated tests into their code in order to get the product to market sooner. The key to technical ... read more
By Frances Lash | February 25, 2015
As business leaders become more involved with IT investment decisions many CIOs have found it more difficult to receive funding for maintenance of applications and infrastructure. The result of this is that technical debt has become an even more useful term to explain to business stakeholders the importance of IT maintenance investments. This post goes ... read more
By Frances Lash | February 23, 2015
In this post, technical debt management is looked at from a DevOps approach. Technical debt is defined here, as the price organizations pay when releasing poorly designed code. Companies that collect a large amount of technical debt are in risk of running into a situation where any innovation takes a backseat to putting out fires. ... read more
By Frances Lash | February 13, 2015
Paying off technical debt, according to this post, can be made easier with microservices architecture. When building a code base, eventually, trade-offs between quality and delivering on time will arise. The benefit of trade-offs in software is that the option to later go back and fix these shortcuts is available. Quick and dirty shortcuts and ... read more
By Frances Lash | January 28, 2015
CISQ is the Consortium for IT Software Quality, a special interest group of the Object Management Group organized to create standards for measuring software quality, including the definition of technical debt and factors that influence it: security, performance, reliability, and maintainability.
This article, from SD Times, goes into depth about the Consortium of IT Software Quality – ... read more
By Frances Lash | January 23, 2015
A technology singularity, in terms laid out by this post on technical debt, is a point when technology created by humans reaches the point where it can no longer be understood by its creators. A mathematical singularity is a point beyond which odd or unpredictable behaviours can be recognized. In formulating the hypothesis for this ... read more