On Technical Debt http://www.ontechnicaldebt.com Online Community Thu, 26 Feb 2015 09:00:02 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.3 Is Tracking Technical Debt A Waste Of Time? http://www.ontechnicaldebt.com/blog/is-tracking-technical-debt-a-waste-of-time/ http://www.ontechnicaldebt.com/blog/is-tracking-technical-debt-a-waste-of-time/#comments Thu, 26 Feb 2015 09:00:02 +0000 http://www.ontechnicaldebt.com/?p=3377 read more]]> Tracking technical debt in the development backlog is meant to make the costs and risks of the technical debt taken on visible; prioritizing debt payments with other work is supposed to ensure that the payments get made. This post argues that tracking debt is not worth it.

These are the reasons listed:

Some code often isn’t worth the worry – fussy coding style issues, poor variable or method naming, methods that are too big, or other inconsistencies do not need to be tracked in the backlog, They can be taken care of with a day-to-day refactoring effort – the next time you come upon the code fix it. It doesn’t cost much and if left alone the consequences aren’t debilitating. Out of date open source code or third party or third party software can be very bad leading to exploitable security vulnerabilities. Therefore, these issues shouldn’t even reach the backlog but should be fixed right away. Everything else, like software that has been updated with some bugs fixed isn’t high priority, and updating for the sake of doing so can often break other things that are needed.

The most frightening type of debt is the debt that may not even be known about so it can’t be added to the backlog. When someone more experienced joins the team suddenly this debt can suddenly be exposed. Until a change, like this, occurs this debt keep on adding up silently. Tracking debt, thus, serves no purpose for the most dangerous type of debt. Another example would be when there is debt too big to deal with effectively. Debt that was taken on early by making the wrong decisions – the wrong architecture, language, or framework were chosen at some point and now it can’t just be resolved by refactoring. Either it needs to be dealt with as is in the best way possible or it must be taken down and built up from scratch. Tracking such a kind of debt in the backlog is pointless.

Technical debt that can be handled responsibly is debt that was taken on consciously. Short cuts taken to get quicker feedback have a good chance of being rewritten or thrown out so there is not much concern about getting it right the first time – this is strategic debt. Or if there wasn’t time to write code properly the first time so quick and dirty code is used. If it is not paid down soon it is often forgotten about and loses priority to other more present and pressing issues. It may even have been paid down without you knowing it, someone else saw that it was no longer needed and deleted it or it refactors it while making another change. The code may not even be present or in use anymore and the debt taken on is still in the development backlog.

Tracking code in the backlog seems to be the responsible option and is often recommended in other posts on how to manage technical debt. However, the technical debt that has been tracked in the backlog will never be a fully accurate picture of the debt that is actually present in the system due to unknown and undiscovered debt that has yet to rear its head. Tracking technical debt in the backlog can also be a waste of time because often times the work listed doesn’t get done. The only debt worth tracking is the debt that everyone on the team has agreed is worth tackling and paying  off. It is more practical to spend time refactoring than loading the backlog with work that might not get done.

To read the full post go to: http://java.dzone.com/articles/dont-waste-time-tracking

http://www.ontechnicaldebt.com/blog/is-tracking-technical-debt-a-waste-of-time/feed/ 0
How To Calculate Technical Debt: A Top-Down Approach http://www.ontechnicaldebt.com/uncategorized/how-to-calculate-technical-debt-a-top-down-approach/ http://www.ontechnicaldebt.com/uncategorized/how-to-calculate-technical-debt-a-top-down-approach/#comments Wed, 25 Feb 2015 09:00:09 +0000 http://www.ontechnicaldebt.com/?p=3366 read more]]> 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.

Technical debt is the accumulated costs built up within an organization due to poor coding techniques, trading off between quality and time, and using suboptimal standards. The swap for short term advantages can lead to serious issues in the long term such as: application outages, security vulnerabilities, and increased maintenance costs. Technical debt began as a term referring to quick and dirty practices but has been extended to cover issues with architecture, infrastructure, integration, and processes. CIOs are now trying to identify how to calculate its actual costs and the benefits of paying down technical debt in order to justify core renewal projects, to increase maintenance budgets, or to identify the most pressing issues for maintenance work.

The procedures for measuring code quality have become more “advanced and quantitative than the techniques typically used for measuring the technical debt associated with IT infrastructure, architecture, integration, and processes” –  in the latter areas mentioned, CIOs can achieve directionally accurate estimates of the cost of technical debt.

Before beginning to evaluate the levels of technical debt within an organization, the CIO should decide what the goals of this evaluation is; for example, if the CIO is looking to replace a 40 year old system not ever small defect within the system needs to recorded for his/her use. What should be calculated in this case is how much the system costs while running and how much would be saved once they system is retired. On the contrary, a CIO who wants to fix a system will need to identify problems, the severity of these problems, and the cost to fix them.

In order to calculate code quality debt in relation to things like claims processing or trading platform using a code-scanning tool can be a good first step. These tools often identify quality, security, and performance defects within an application and evaluate the amount of effort needed to resolve such issues. Organizations should, therefore, assess the tools available to see which meet their needs accurately. After identifying the issues that comprise the code quality debt, CIOs can calculate the costs associated with these issues, the costs to maintain them as they are, and the possible costs of debt reaching levels of business disruption. After these costs and potential costs are determined the costs needed to pay down that debt must also be assessed.

The method outlined above is a top-down approach of calculating technical debt that is more subjective than a bottom-up approach the relies more on benchmarks, estimates, and proxies. Calculating technical debt, especially from the bottom-up approach of an entire app portfolio, is a significant project to take on that could take several months to undertake. In comparison, a “bottom-up analysis of a single system or a small set of systems, or a top-down estimate of infrastructure technical debt take considerably less time”. Using such analysis allows to prioritize those areas that present the greatest risk of business disruption or areas that cost the most to carry.

To read the full post go to: http://deloitte.wsj.com/cio/2015/01/21/how-to-calculate-technical-debt/

http://www.ontechnicaldebt.com/uncategorized/how-to-calculate-technical-debt-a-top-down-approach/feed/ 0
How DevOps Can Cut Innovation-Crushing Technical Debt http://www.ontechnicaldebt.com/blog/how-devops-can-cut-innovation-crushing-technical-debt/ http://www.ontechnicaldebt.com/blog/how-devops-can-cut-innovation-crushing-technical-debt/#comments Mon, 23 Feb 2015 10:30:42 +0000 http://www.ontechnicaldebt.com/?p=3367 read more]]> 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. Organizationally, the main blame is on the developers and architects; as defects that go through production cost about 100 times more to fix than in the early stages of development. As developers move on to other projects and their priorities shift, defects become harder to fix and the interest on debt increases. Now that there is an increase in business pressure to deliver quickly on innovations how can technical debt build up be avoided?

Agile practices become helpful to look for answers on how to avoid mounting technical debt:

  1. Avoid bad spending habits – if there are constant delays in release and deployment of a project it can be easy to put off necessary work, such as code optimization, until there is time later to fix it. To avoid habits like this the condition that causes them needs to be stopped. Testing earlier in the software lifecycle and automated deployment processes make it so teams can’t hide behind delays and release bottlenecks.
  2. Consolidate debt – debt can span across multiple systems and can build up on badly designed and developed code bases – short term fixes perpetuate themselves. If there is bad code to begin with there is not incentive to improve processes in the future. Identifying the biggest problems and balancing new application development and services with fixing legacy issues can help to focus on long term benefits rather than short term fixes.
  3. Seek guidance and counselling – using code and peer level reviews, mentorship and management guidance can help. Often time IT dismisses operational considerations until debt is out of control – a DevOps approach helps by involving IT operations with development to address debt problems.
  4. Avoid ‘spend more’ initiatives – often incentives tied to function points and number of stories delivered or even lines of code written are used by development. This may guarantee a large amount of code but its usability is often not. Incentives do not necessarily promote optimal standards.
  5. Think broadly about debt position – it can be easy to blame development for mounting debt but operations is just as guilty. An example would be a failure to document infrastructural services can lead to longer problem diagnosis times. DevOps collaboration could help by involving the development team in ongoing debt reduction programs.

Technical debt can be deadly, sucking up resources and time that could be spent on innovation, using a DevOps approach could help organizations keep track of their debt and reduce it. Read the full post here: http://www.informationweek.com/strategic-cio/how-devops-can-cut-innovation-crushing-technical-debt/a/d-id/1318677

http://www.ontechnicaldebt.com/blog/how-devops-can-cut-innovation-crushing-technical-debt/feed/ 0
Microservices Architecture & Reducing Technical Debt http://www.ontechnicaldebt.com/uncategorized/microservices-architecture-reducing-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/microservices-architecture-reducing-technical-debt/#comments Fri, 13 Feb 2015 09:14:24 +0000 http://www.ontechnicaldebt.com/?p=3356 read more]]> 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.

Microservices architecture could offer an easier way to pay back technical debt in a software environment where delivery speed is increasingly more important. By breaking down app functionality into API-accessible microservices, each service with its own purpose, paying technical debt can be done incrementally service by service.

There are a few reasons why microservice architecture may prove to be a little more difficult to enact than it seems; first is the difficulty in testing microservices-based-apps and second is that it is not always clear what a microservice necessarily entails. Lack of testing is often a source of technical debt because when pressed to meet stringent deadlines the testing cycle is often cut short – therefore, if testing becomes more complex, the more likely skipping them becomes. Also, in creating microservices architecture it is possible mess up and end up creating bad architecture, and bad architecture is the hardest technical debt to pay off.

Although there are complications to using microservices architecture it is likely to continue its growth in popularity. The ease in paying technical debt with this architecture is not the only reason for this, but also because it allows tapping into an existing service rather than coding from scratch. It also gives business the ability to create applications that are adaptable to change over time. However, microservices do not magically resolve problems of technical debt instantaneously; recording where and how much debt exists in the code base is necessary for any organization to keep its debt in check.

The environment in which development is occurring has just as much to do with successfully managing debt as what architecture or techniques are used to address it. If impossible deadlines are the norm, than technical debt often is passed down the line and results in high developer turn over within an organization; there is not much to be done in such a case and debt default is likely.

To read the full post go to: http://www.infoworld.com/article/2878659/application-development/reducing-technical-debt-with-microservices.html 

http://www.ontechnicaldebt.com/uncategorized/microservices-architecture-reducing-technical-debt/feed/ 0
Is Technical Debt breaking the Software Development bank balance? http://www.ontechnicaldebt.com/uncategorized/is-technical-debt-breaking-the-software-development-bank-balance/ http://www.ontechnicaldebt.com/uncategorized/is-technical-debt-breaking-the-software-development-bank-balance/#comments Mon, 02 Feb 2015 09:00:08 +0000 http://www.ontechnicaldebt.com/?p=3349 read more]]> Is technical debt still a valid metaphor in the present global software development world? The answer is yes, and this post goes on to present the benefits of such a metaphor while explaining just what technical debt is exactly. There is a growing concern on tech debt not simply because of the costs associated with it but also because mounting technical debt can delay delivery and turn into lost customer satisfaction. The impact of technical debt is often contrary to the many proposed benefits of agile development. Technical debt is the left over work from quick and dirty software – this debt is paid back from the extra efforts later on by developers to clean-up the messy code. When technical debt accumulates over time it can begin to affect the actually financial debt of an organization – either through extra man hours needed, profits lost due to late delivery, or poor user satisfaction.

Developing software quickly is becoming a growing challenge in the industry and maintaining the legacy applications within software is becoming increasingly tedious due to software complexity. This can lead to the popular use of technical debt and brittle code that is difficult to maintain and is often dreaded by developers for fear that changing one thing will have repercussions in other parts of the code. Inheriting technical debt due to open source is also becoming an issue. Open source has crown rapidly within commercial development projects, so what seems at first like source of innovation can often turn into technical debt in the future.

The metaphor of technical debt should be used to increase dialogue between development and business in order to associate the costs to business that are a direct result of decisions made during the development process. Short term speed and first to market advantage may not be worth the long term delays and costs that come as a result of mounting technical debt. Agile as a development method has been around fro some time now, but what is new is making development tools that support such a method. Making sure that automated testing is built into the process of short iterative development is highly beneficial to scoping out code issues early and avoiding technical debt build up.

To read the full post go to: http://www.computerweekly.com/blogs/cwdn/2011/09/is-technical-debt-breaking-the-software-development-bank-balance.html?asrc=EM_NLN_39160385&uid=12933816&utm_medium=EM&utm_source=NLN&utm_campaign=20150128_Word+of+the+Day%3A+technical+debt_mrouse

http://www.ontechnicaldebt.com/uncategorized/is-technical-debt-breaking-the-software-development-bank-balance/feed/ 0
CISQ: Establishing Industry-wide Standards to improve Software Quality http://www.ontechnicaldebt.com/uncategorized/cisq-establishing-industry-wide-standards-to-improve-software-quality/ http://www.ontechnicaldebt.com/uncategorized/cisq-establishing-industry-wide-standards-to-improve-software-quality/#comments Wed, 28 Jan 2015 09:45:28 +0000 http://www.ontechnicaldebt.com/?p=3344 read more]]> 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 – what it does exactly and why it is necessary in the software industry. CISQ (managed by the Object Management Group, otherwise known as OMG) was chartered in 2009 to create specifications for measuring source code quality. Dr. Bill Curtis, executive director of CISQ and senior vice president and chief scientist at CAST software, commented in this article that the industry needs “standard, low cost, automated measures for evaluating software size and structural quality that can be used in controlling the quality, cost and risk of software that is produced either internally or by third parties…” Structural quality is an aspect of engineering software that is a cause of many system failures which have been making headlines recently. CISQ aims to set a standard for systems through its specifications: the Automated Function Point sizing standard (AFP) and the CISQ Software Quality standard. 

These two specifications aim to standardize measurements for size, automated function points, reliability, security performance efficiency, and maintainability. These measurements would help simplify outsourcing contracts and service level agreements which involve size and structural quality – allowing them to be based on universal measures, rather than various differing measurements based on contrasting attributes. The AFP provides a low cost and consistent size measurement option, compared to a subjective and expensive measurement based on manual counting. Automation and subjectivity guarantee that one person counting with AFP will produce the same number as two others counting within the codebase.

Why is a software quality standard needed? This standard is needed because a measurement on software quality is often subject to the interpretation of each person who handles the code under scrutiny. A standard like this is designed to create an understanding between developers and enterprises on how systems are analyzed based on reliability, security, efficiency, and maintainability. Structural quality is measured vis a vis pattern matching and code analysis for violations of good architectural and coding practices in source code. This can be done through automated analysis technology which can detect structural flaws immediately. For example, it would be able to detect an entry in the user interface that skips around user authentication functions and authorized data access routines – accessing the data directly. This is a security risk that could end up being a cause of likely data corruption.

Adopting the code analysis tools that are in accordance with CISQ software quality standards would allow for all stakeholders in a project to access which apps possess the greatest risk to a system. Once risks are uncovered the next step would be to establish minimum threshold requirements for quality in critical business systems. When defects within business critical systems have been making headlines and costing enterprises millions, accepting a standard will allow stakeholders to govern and maintain their systems based on measures developed by industry experience.

At the moment the standard is still in the approval process at OMG, however, Dr. Bill Curtis believes that adoption of the standard will be driven by pull rather than a push in the industry as the standard was created due to IT customers asking for it and aiding in its development. CISQ has taken on raising the structural quality of IT software and ultimately reducing the risk and cost of IT software to its users.  In standardizing software quality, CISQ evaluates certain characteristics of extant code, while other organizations approach their standards from the development process looking at software from the product level.

CISQ aims to increase the structural quality of software systems by creating a global standard. To read further clarification on which standards and specification compliment each other and how they work together read the full post: http://sdtimes.com/cisq-aims-ensure-industry-wide-software-quality-standards/

http://www.ontechnicaldebt.com/uncategorized/cisq-establishing-industry-wide-standards-to-improve-software-quality/feed/ 0
The Technical Debt Singularity http://www.ontechnicaldebt.com/uncategorized/the-technical-debt-singularity/ http://www.ontechnicaldebt.com/uncategorized/the-technical-debt-singularity/#comments Fri, 23 Jan 2015 09:00:00 +0000 http://www.ontechnicaldebt.com/?p=3339 read more]]> 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 singularity the logic follows that eventually humans will create a computer that is smarter than the human brain. Computers will be able to develop themselves at a quicker rate than humans can keep up with; the speed of development will increase exponentially heading towards infinity. This post addresses how the singularity idea can apply to technical debt.

When a software project reaches the point where it gets bogged down and grinds to halt, this is because decisions have been made that accrue technical debt. For example, writing a bit of hacky code now to complete work quickly is a decision to loan ourselves time from the future. We end up paying interest on the loan as we waste time maintaining the poor code over time. When the interest owed on technical debt exceeds the amount of man-hours in a work day a technical debt singularity occurs.

Technical debt is not always a negative thing, but when it goes un-managed it can bring work to a halt. In order to avoid this, paying down interest is necessary. Whether this be by refactoring, writing automated tests, or fixing poor processes. Keeping technical debt under control can be made easier by following some of the strategies outlined in this post:

  • Source control in order to better manage changes made in the code base
  • Automated testing throughout code in order to have continuous integration/delivery
  • Improving communication with business managers so they understand the consequences of shipping too fast
  • Visually monitoring technical debt and paying it back whenever possible

Starting off the new year with a focus on more long term development could keep the probability of technical debt singularity at bay and improve the quality of any software project. Communicating with business stakeholders to make sure deadlines are realistic and don’t infringe on quality is necessary in order to keep technical debt from building up uncontrollably.

To read the full post go to: http://workingwithdevs.com/technical-debt-singularity/?utm_content=bufferfb58a&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

http://www.ontechnicaldebt.com/uncategorized/the-technical-debt-singularity/feed/ 0
Is Refactoring “Needless Rework”? – Refactoring for Design Level Smells http://www.ontechnicaldebt.com/uncategorized/is-refactoring-needless-rework-refactoring-for-design-level-smells/ http://www.ontechnicaldebt.com/uncategorized/is-refactoring-needless-rework-refactoring-for-design-level-smells/#comments Mon, 19 Jan 2015 09:00:21 +0000 http://www.ontechnicaldebt.com/?p=3335 read more]]> Here’s a post that delves into the necessity of refactoring in software engineering, comparing the practicality of refactoring in software to restructuring in urban planning. It begins by stating that when running software projects that span millions of lines of code the original design is usually good, over a period of time, however, the design begins to degrade. Gradually work slows down and more time is needed to make fixes or enhancements. In order to get work going at a faster speed, developers introduce more shortcuts building more technical debt until it reaches a state where development comes to a halt. There are only two options to follow this: rewrite or refactor.

Most developers would prefer to rewrite but this is a less practical option from a business perspective. Refactoring is the only real practical option. In the example of the city of Bangalore where sudden overcrowding from the IT boom created high amounts of traffic congestion, overhauling the whole city as a solution is not feasible. Refactoring or restructuring is the more appropriate solution and is needed at different levels. In the long term, metro lines would be the best solution but their construction is inconvenient for the citizens in the short term. Therefore, expanding roads, building overpasses, and smoothing out roads are good short term solutions. These examples of restructuring (refactoring) can also be applied to software systems at the architecture, design, and code levels.

The main focus is refactoring for design level smells. Design smells are, going back to the example of Bangalore, symptoms of creaking infrastructure like: missing roads, bottleneck junctions, and footpath roads being used by non-pedestrians. Similar symptoms can be found in software like missing abstractions, deficient encapsulation, and broken hierarchies.

Every engineering discipline has to manage non-optimal and sub-optimal solutions. Changing requirements and rapidly emerging technologies makes software engineering have more of a need for quick adaptation. This is one of the reasons agile practices have gained momentum in the past years and why it focuses so strongly on refactoring. Refactoring is therefore necessary in forming core practices for creating high quality software.

To read the full post go to: http://www.designsmells.com/article.php?id=7

http://www.ontechnicaldebt.com/uncategorized/is-refactoring-needless-rework-refactoring-for-design-level-smells/feed/ 0
Technical Debt is Risk Management http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-risk-management/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-risk-management/#comments Fri, 09 Jan 2015 09:00:31 +0000 http://www.ontechnicaldebt.com/?p=3331 read more]]> If refactoring code reduces a code base by 80%, then the chance of missing a necessary change in the code base and the risk of missing something in testing that damages the production business are also reduced. Therefore, by this logic, the management of technical debt is in fact risk management. Using the analogy of a kitchen for technical debt can be helpful – a kitchen where everything is in the place a professional chef would expect it to be is a clean kitchen. However, a kitchen where things are in the wrong place and scattered around is kitchen with technical debt because the chef has to clean up and prepare before even beginning his work.

Every development team will have their own definition of where things should be in their code – anything that does not conform to this standard becomes technical debt in the code base and makes working with this code significantly more risky. The types of risks that can be introduced by the presence of technical debt are:

  • Delivery Risk – Technical debt has a habit of blowing up in the test phase were it can no longer be managed by responded to. For example, a bug can resurface several times because of a lack of proper regression testing.
  • Business Care Risk – if code contains tech debt, there is a higher probability that the code will behave in more unpredictable ways than if it were without debt. This means that changes made to code may not present the value expected.
  • Risk to Existing Model – when code has technical debt the likelihood of it causing a failure in production that damages the existing production system increases greatly.

If a team is approaching a project from a risk management perspective, paying off technical debt before making any changes is the more responsible move. By looking at the code base as a portfolio of sold call options makes it so every component of the system has its technical debt accounted for. The measure of technical debt present should be calculated as how much effort it takes to pay it down, how complex the debt is, and how many team members can work on the component. The product owner can create what is called a “tornado map” which is a high level road map for the next 6 months to a year by which the team can decide what debt to address now and which can be left for a later date. In some cases technical debt may take a long time to fix or be too complex to estimate effectively, paying down this debt early is often the best solution.

Technical debt has quite a bit to do with the skills and perceptions of the team working on any code base. One team may consider their code base clean when in reality it contains a lot of risk. This is an instance when someone with a lot of experience in identifying dead code would be helpful.

To read the full post go to: http://theitriskmanager.wordpress.com/2014/12/31/technical-debt-is-risk-management/

http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-risk-management/feed/ 0
The Three Kinds of Code: Divergent Perceptions about Cost http://www.ontechnicaldebt.com/uncategorized/the-three-kinds-of-code-divergent-perception-about-cost/ http://www.ontechnicaldebt.com/uncategorized/the-three-kinds-of-code-divergent-perception-about-cost/#comments Mon, 05 Jan 2015 09:00:04 +0000 http://www.ontechnicaldebt.com/?p=3316 read more]]> This post discusses the three categories of code that can be found within a certain project and that confusion about them plus a misunderstanding about their actual cost can lead to trouble. The three categories of code follow:

  1. Temporary Code: or code written to throw away within a day or week – if it breaks it’s alright because it was made to be replaced anyway.
  2. Sustainable Code: code built to last with strong automated testing and holds up to standards that the team is happy to maintain.
  3. “Sloppy” (the post refers to it under a different name) Code: pertains to quick fixes, code written by amateurs, rush jobs, things that were meant to be cleaned up but never were.

When a business person expresses what the want (something cheap and quick but not fragile) they propose a solution that falls into the sloppy category. Developers react poorly to this solution demonstrating divergent perceptions about cost between developers and business stakeholders.

Screen Shot 2014-12-31 at 12.35.35 PM

Given that the perception of costs differ, it is natural that the business person would prefer the sloppy action – it is more valuable than the temporary option but doing things sustainably costs cost more. The developer side rejects what they see as the high cost option. From each of their perspectives they are right, they are just looking at different costs.

Rewriting the headers can demonstrate this:

Experienced developers are more aware of longterm costs because those are generally assumed to be their problem. The maintenance of sloppy code adds up and is not often attributed to excess schedule pressure from business stakeholders. Developers, however, can be perceived as increasingly unproductive and unreliable. Sloppy code build-up (sometimes referred to as technical debt) is not just bad for developers but for the whole organization. If the cost of software continuously increases than it becomes a powerful advantage for competitors who are more thoughtful and disciplined in their processes.

Many parts of the agile world either explicitly or implicitly rule out the use of sloppy ode. In the example of extreme programming, a project is begun with a number of sustainable practices including: pair programming, test driven development, and constant refactoring. Quality is a fixed variable in the planning process. In order to avoid the creeping use of sloppy code make sure that everyone on the development team are invested in the long-term. Stakeholder’s should be educated on how expensive supposed cheap solutions are. Temporary solutions should be truly be temporary by agreeing in advance on an end date, if a permanent solution is the follow up it should be included in the budget, and when the end date approaches push back should be denied and the team should be reminded of the previous agreement. Ultimately, keeping a keen eye out for sloppy code in disguise is important. For example, out sourcing or off shoring a project can seem cheap and easy but it can end up being sloppy code sold as sustainable code.

To read the full post go to: http://agilefocus.com/2009/06/22/the-3-kinds-of-code/ 

http://www.ontechnicaldebt.com/uncategorized/the-three-kinds-of-code-divergent-perception-about-cost/feed/ 0