This post presents an interesting mindset from which to build software: treating infrastructure as code so that the systems and devices which are used in software are treated as software themselves. In order to treat infrastructure as code, the tools and practices that are used in software development need to be employed in infrastructure management. Here is where the concept of technical debt comes into play and presents an clear way of tying tech debt into software quality.
Good software engineering practices can produce high quality code and systems - however, quality is often times defined in terms of functional correctness. What quality actually is, is an enabler of change. Under this definition of software quality, technical debt management fits perfectly. What technical debt does when it is not properly managed, is that it makes it more difficult for those working on code to alter or add onto existing code. So technical debt can be used to measure the quality of software if we accept that the speed and safety at which we can change code is a defining characteristic of software quality.
Poor quality systems by this definition are therefore difficult to change and when they have to be changed they require extra work (like undoing large chunks of code and creating more of a mess in the process). If this doesn't sound like a description of what occurs when working on code that has technical debt, you should do some more reading of the posts on this blog.
Despite the fact that what this post discusses on the quality of code itself, it's main subject is that of infrastructure quality and how treating infrastructure the same as code makes it easier to improve your system's infrastructure. Let's take a look at how infrastructure is just like code.
- Different people have built, changed, updated, optimized, and fixed various parts of the system's infrastructure
- This means that any change in one part of the system could result in a breakage in another area
The process of writing code creates the same circumstances as those just outlined. So acknowledging this and then using the same tools to build infrastructure, although not immediately improving quality, does better your chances at doing so. There has recently been an uptick of focus on keeping code clean which is relevant to both infrastructure and technical debt maintenance. There is often a perceived tension between what is pragmatic and what is quality work - however, this is a false dichotomy to rely on. Pragmatism is often viewed as meeting deadlines and quality is seen as being an impediment to this. What quality actually is, as detailed above, is creating something that can be viewed by the next person working on the code and understood and changed easily.
Technical debt is the result of quick and dirty coding practices and stresses your system with complex and messy code - this strains both the functionality and infrastructure of your product. By defining infrastructure under the same terms as code, keeping up the quality of both becomes simpler. You can focus on maintaining the changeability of your software under one umbrella: infrastructure and code quality meaning taking care of best practices and keeping down your debt levels.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.