Tag: software development

In 2015 there was a major slew of headlines dedicated to software failures at major companie which led to a discussion of best practices for software development.

In this great podcast from .Net Rocks! the discussion on how to handle technical debt takes an interesting turn towards the discrepancy in communication between different stakeholders on a software project.

Much of what comes with being an entrepreneurial leader is knowing when to accept certain tradeoffs.

It has become a recent practice in organizations to measure technical debt in their software.

Technical debt is a very important concept to developers that is often lost on the management end. Developers use the concept to describe the consequences of a pressure to meet deadlines.

It's estimated that the federal government spends about $80 billion a year on IT.

Software risks to the business, specifically Application Resiliency, headline a recent executive roundtable hosted by CAST and sponsored by IBM Italy, ZeroUno and the Boston Consulting Group.  European IT executives from the financial services industry assembled to debate the importance of mitigating software risks to their business.

In the current tech scene, it has become common practice to refer to programmers as engineers. It seems that if you aren't part of sales or marketing teams you are now entitled to being designated as an engineer. However, what has been forgotten over the 50 years of looking to turn software development into a legitimate engineering practice, is that we still haven't reached the aspiration of being just that: a legitimate engineering practice. Traditional engineers have to go through stringent regulation, certification, and apprenticeships in order to gain the title. This creates an implicit responsibility of providing reliability and public safety. Software development hasn't reached this point yet - software quality and standards are not universally valued.

So why is the tech industry using the engineering title to describe its technical workers?

There is always a battle between the amount of time you have to get things done and the amount of work you have to do to get those things done. There is usually less time than what you need to complete all that work. This time vs. work dynamic is what creates technical debt. Hitting a release deadline is often valued over writing clean code, which leads to technical debt build up. This means the next release you are working on is going to take longer, leading you to take on more debt. A cycle like this is dangerous because it leads to poorly constructed code and can even result in system failures.

In the development cycle there are many places where technical debt can rear its head and cause problems down the line for the product you’re developing. In order to tackle the problem of technical debt first teams need to know what it’s comprised of, how to identify it, and, then, how to address it’s presence in a system.

The purpose of this white paper is to portray the worldwide state of agile adoption for our readers. While much has been written about the strengths and weaknesses of the technology, little data has been published to show how widely agile methods are used. This paper corrects that by providing data from our databases for public consumption. As shown in Figure 1, agile methods have become the dominant software development paradigm used throughout the world based on data from 330 organizations. Some of these organizations are offshoots of the 120 firms and government organizations from which we have received data. Figure 2 summarizes which agile methodologies are in use by these organizations. As many said that they were using a hybrid approach, i.e., one that combined agile with traditional concepts, we have included their response and categorized them as either hybrid or hybrid/lean (agile combined with lean).

Time to market pressures are often identified as one of the key causes of technical debt. This results in a tension between releasing a poor quality application early and releasing a high quality one late. The advantages of releasing a product sooner rather than later can be immense and extremely beneficial for a business – and in the rapidly changing tech environment falling behind can be disastrous. However, one of the common misconceptions about technical debt is that it is only relevant at the code-level of software development, when technical debt can be incurred at any point of the software development life-cycle.

Ward Cunningham introduced the technical debt metaphor as a method to highlight the potential for higher costs in product development from postponing some work on software in order to release other parts faster. The comparison between financial debt and the term technical debt was meant to demonstrate the eventual need to complete postponed work and repay the principal of delaying it. Technical debt also alludes to the possibility that interest costs, associated to postponed work, can become so high that they impede any other important work from being done on a project. For these reasons, technical debt is a useful concept – as it clearly communicates the danger of postponing work. However, metaphors often conflate two comparable situations, to two identical treatments of similar situations. This can be avoided in the financial debt/technical debt coupling, by using the financial metaphor to identify the economic forces behind technical debt.

Technical debt is defined, in this post, as any code that impedes agility as a project matures. This is an important definition to keep in mind as the following attitude towards technical debt is discussed.

This post is based on an interesting paper about managing technical debt at Google.

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 into detail on how to calculate technical debt.

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 expedient design decisions build up over time and create technical debt, which needs to be paid pack before it reaches unmanageable levels. This entails refactoring bad code and reviewing questionable design decisions before defaulting on the debt created. Once the debt has been defaulted on, things start breaking all over the code base and makes working almost impossible.