On Technical Debt http://www.ontechnicaldebt.com Online Community Wed, 17 Dec 2014 09:00:07 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.3 Move Fast, Minimize Technical Debt http://www.ontechnicaldebt.com/blog/move-fast-minimize-technical-debt/ http://www.ontechnicaldebt.com/blog/move-fast-minimize-technical-debt/#comments Wed, 17 Dec 2014 09:00:07 +0000 http://www.ontechnicaldebt.com/?p=3298 read more]]> This is post with some tips for start-ups to minimize their technical debt. First, it needs to be decided which code is going to be kept. Start-ups will often make code that is temporary and some code that will definitely be around later. Therefore, when code needs to switch from temporary to sustainable the developer team should make sure they clean up properly.

For the code that is intended to be kept, there are several steps that are helpful to making sure that technical debt does not build up in the codebase. Writing tests is always helpful, because if the code doesn’t have automated test coverage it either means that manual testing is occurring or no testing at all. Manual testing does not scale well and slows down feedback loops, while not testing at all slows down slows down development by instilling fear of breaking things and hinders bold changes. Refactoring is also key to keeping tech debt quantities low – it is important to default to keeping code very clean or else once things begin to get messy nobody feels bad about adding onto it. If making a mess intentionally, it is also important budget time later to clean it up.

This post mentions the phenomenon “normalization of deviance” where organizational cultures get used to things being broken, which can cause major issues in the code base. Therefore, when a bug appears a test should be written to expose it, then the bug should be fixed and the cause of the bug should be found and fixed as well. Being able follow some of these tips requires time, which is only possible if schedule pressure is under control. Non-technical stake-holders often want projects done quicker than the ability to produce than them well allows, finding a method to turn schedule pressure into productive ends is helpful. By making sure that hazy features are not attached to fixed dates. Production monitoring is another mode in which to make sure nothing is broken that developers are not aware of. When something is broken and unidentified it will either hover over the production logs or blindside the project, both end up wasting time. Starting with simple loggings that page every time there is a problem is one way to address unknown issues.

Building code with future improvements in mind is necessary for start-ups.  Simple code that later needs to built upon is easier if things are kept modular, preventing messes from spreading. Start-ups also use a lot of A/B testing, which helps with technical debt by keeping changes smaller as longer changes are harder to A/B test. Therefore, when an experiment was performed in the code and it succeeds and the feature will be kept and scaled up, that is the time to invest in the code. The post also recommends using a continuous integration server also allows for issues to be known about sooner, meaning it will cost less to fix them. Considering pair programming is also suggested, as it is like an instantaneous code review and the knowledge sharing aspect of it reduces bottlenecks and silos making new entrants easy to bring on.

All of these suggestions, although they may take time, are better than the alternative of accumulating technical debt which in the long run is much slower than using these tips. To read the full post go to: http://www.quora.com/How-can-startups-move-fast-while-minimising-technical-debt?utm_content=bufferdd182&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

http://www.ontechnicaldebt.com/blog/move-fast-minimize-technical-debt/feed/ 0
Inheriting Bad Code: How to Fix and Prevent it http://www.ontechnicaldebt.com/uncategorized/inheriting-bad-code-how-to-fix-and-prevent-it/ http://www.ontechnicaldebt.com/uncategorized/inheriting-bad-code-how-to-fix-and-prevent-it/#comments Tue, 16 Dec 2014 09:00:47 +0000 http://www.ontechnicaldebt.com/?p=3292 read more]]> In this presentation by Kimber Lockhart, as part of the Hack Summit (the virtual conference for programers), she discusses what to do once you’ve inherited bad code. She speaks less about the source of bad code (low budget, high pressure to meet deadlines, company’s decision to hire poor developers) and more on the steps to fix and prevent this code. She does mention that not all bad code is because of technical debt, since for her tech debt comes from a conscious decision to write poor code, but this presentation does address how to get rid of it.

Lockhart defines bad code as any code that doesn’t meet your expectations or the expectations of the company at the time. This missed expectations could be the result of insufficient testing or slow, unstable, and inconsistent conventions. In order to start addressing the poor code, three mistakes that developers often fall into are pointed out.

Big mistake #1: Not learning first and jumping into refactor and fix a system you do not fully understand.

Big mistake #2: The rewrite instinct – rewriting code is not the answer to bad code most of the time.

In order to decide whether to approach bad code with a rewrite developers need to ask themselves a set of questions. Do they know what the new product should do? What is going to be better about this new version? The rewrite could often end up being worse than the original. Is there anough time budgeted to complete the rewrite so that it fits your cost-benefit analysis? In other words will it be possible for 5 engineers to rewrite in 3 months what took a team of 20 to do in 3 years. Finally, in order to decide whether to rewrite, developers should ask whether the whole codebase needs to be rewritten?

After asking these questions the team needs to begin the process of fixing and preventing future problems from occurring. Lockhart demonstrates this with a simple diagram.

Screen Shot 2014-12-10 at 4.54.27 PM

She begins by discussing the steps needed to begin the process of fixing broken code. The first step, is to spend time planning and make a list in order to prioritize what needs to be fixed. This should be done in order to justify choices made to stakeholders in the project. In order to prioritize what should be fixed first developers should compare: how bad it is currently, how widespread is bad code throughout the codebase, and does this bad code cause another set of negative effects?  Once this list of prioritized list of which bad code projects to work on, the following methods can be used to improve on the code.

Encapsulating bad code is the best way to move forward with old code. Keeping the old code running but keeping it separate from new and better code by wrapping it in a module will mean no one else can add to it except to fix it. The old code can still be called upon, but encapsulating it keeps the bad code from spreading, and motivates team members who work with the encapsulated code to refactor it so as to meet the rest of the standards.

Next would be to deprecate, even if you think no one will want to copy the bad code it may be better to make sure no one else does so. Asides from flagging bad code, Lockhart recommends also marking fantastic code (for a whole feature) but also but an expiration date on that feature. What was fantastic code 3 years ago is the bad code of today – by writing a test so when the expiration date passes it runs and if the code fails someone has to explicitly look at it.

Typically, when bad code is inherited so is dead code. Lockhart suggests deleting bad code, but doing so with caution. Investing a few hours a week to create an automated system in order to identify code to be deleted would be the best way to go about deleting dead code.

While fixing the bad code that already exists, steps need to be taken to prevent such code from being created again. Lockhart first recommends writing down (better yet coding) your standards in order to make sure there are not inconsistencies in what your standards are and in the code. Asides from this preventive step, she mentions pre-deprecating as a strategy to address the bad code you know you’re creating and make sure that it is known that a decision was taken to write a shortcut. She also warns against making 10% improvements to the framework, as they may not be worth the downside of inconsistent code. Instead, it would be much better when improving the framework to make sure much more than 10% is improved on and worth the additional complexity of dealing with multiple versions in the codebase.

She concludes with a suggestion to follow up after a project, dedication 20-30% of the total time spent working on it to clean it up. This is a good step to make sure bad code does not slip into a project.

Ultimately, she ascribes to the “slow and steady wins the race” method of work as a manner to avoid sloppy code. To watch the full presentation go to: https://hacksummit.org/live/1GSWPUYHQ

http://www.ontechnicaldebt.com/uncategorized/inheriting-bad-code-how-to-fix-and-prevent-it/feed/ 0
How To Reduce Technical Debt? A Free Guide By Deloitte Consulting http://www.castsoftware.com/resources/resource/analyst-reports/tech-trends-2014-inspiring-disruption?gad=otd http://www.castsoftware.com/resources/resource/analyst-reports/tech-trends-2014-inspiring-disruption?gad=otd#comments Thu, 04 Dec 2014 15:44:20 +0000 http://www.ontechnicaldebt.com/?p=3272 read more]]> read more]]> http://www.castsoftware.com/resources/resource/analyst-reports/tech-trends-2014-inspiring-disruption?gad=otd/feed/ 0 Economics of Quality: Technical Liability and Self-insuring Software – A CISQ Presentation http://www.ontechnicaldebt.com/uncategorized/economics-of-quality-technical-liability-and-self-insuring-software-a-cisq-presentation/ http://www.ontechnicaldebt.com/uncategorized/economics-of-quality-technical-liability-and-self-insuring-software-a-cisq-presentation/#comments Wed, 03 Dec 2014 09:00:17 +0000 http://www.ontechnicaldebt.com/?p=3247 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. 

In this presentation from CISQ, by Murray Cantor senior consultant at the Cutter Consortium, the economics of quality has to do with the method in which to “systematically reason about when investing in quality is the better choice, when demand for features may at first seem more important”. Quality matters because it affects the bottom line of the business: poor quality can become very expensive in the long run. This isn’t a new idea as most of what is written about technical debt and quality has to do with the increased costs of poorly built code overtime. The approach mentioned in the presentation is to measure the business value of the software with or without quality improvement.

From here, the presentation goes onto explain the methodology behind computing product value (net present value or NPV) that consists of business core elements.

For a product, P: NPV(P) = NPV(Benefits) – NPV (Dev costs) – NPV (After delivery costs)

  • Benefits: how you measure success: revenue, cost avoidance, new customers, labor savings, mission
  • Development costs: coding, deployment, distribution…
  • After market costs: service, warrantee, technical debt (cost of addressing code shortfalls), technical liability (cost of addressing bad business outcomes)

Technical liability can be construed as being the result of technical debt, bad business outcomes coming about because of issues with the business product. There are different types of technical liability:

  • Context dependent liability: there will be more liability assumed for the next release of an avionics dashboard than for the next release of angry birds
  • Uncertain liability: liability involves the likelihood of future events – liability is best described by probability distribution (likelihood x liability)

The net present value of a product is affected by the level of quality. Investing in quality may affect the benefits by increasing utility but may also lower benefits by delaying market release. Investments on quality may also increase development costs because of a drive for efficiency while reducing after delivery costs (technical debt and liability). After calculating the affects of quality on NPV a investment decision needs to be made. At some point when investing on quality, there are diminishing returns and the money may be spent elsewhere. In fact, ROI can turn negative, and when it does it’s time to ship, lowering the cost of enhancing quality can also mean shipping higher quality while also maintaining a positive ROI.

ROI = [NPV(P1) - NPV(Po)] ÷ [Cost(P1) - Cost(Po)]

  • P1 = product with enhanced quality
  • Po = product with initial quality

This process of calculating when to invest in better quality is necessary in order to make a well-informed, information-driven conversation with stakeholders, with staff and have better budget discussions. This requires skills that are not common so it is necessary to start building the capabilities necessary to begin these discussions.

To see the whole presentation and more presentations from CISQ on technical debt go to http://it-cisq.org/ and request a free membership (becoming a free member keeps you up-to-date with standards work and puts you on the invite list for events, as well as giving you access to seminars and presentations online).

http://www.ontechnicaldebt.com/uncategorized/economics-of-quality-technical-liability-and-self-insuring-software-a-cisq-presentation/feed/ 0
Technical Debt: What it is and why should you care? http://www.ontechnicaldebt.com/blog/technical-debt-what-it-is-and-why-should-you-care/ http://www.ontechnicaldebt.com/blog/technical-debt-what-it-is-and-why-should-you-care/#comments Mon, 01 Dec 2014 09:00:58 +0000 http://www.ontechnicaldebt.com/?p=3242 read more]]> Technical debt is often directly responsible for many problems that occur when building high quality software quickly – especially as companies move towards more agile methodologies. Technical debt is generally the sacrifice of quality for speed, so when cutting corners to meet a deadline you are accruing technical debt . This debt taken on was a strategic as a conscious decision was made to take on said debt. Tech debt has its own interest that manifests itself as code that is difficult to read and understand and takes longer to add onto than it should.

Suboptimal code can result in more defects and less confidence in the code, which can in turn lead to employee dissatisfaction. This post cites a study from Gartner that estimated that technical debt will reach $1 trillion USD by 2015. High amounts of technical debt mean that software takes much longer to develop than usual, therefore it is imperative to address the technical debt problem. First, identifying technical debt is necessary. Then tech debt and tech debt remediation should be added into the backlog in order to know what areas cary the worst technical debt and must be worked on.

Changing mindset can help in this process: viewing products as products and not as short term projects will make investment necessary to keep them free of technical debt and create quality code. Adopting development processes that make it ensure excellent code quality will make enhancements easier, defects sparse, and releases more frequent. The post ends by stating: if there is money to fix it later, why is there never money to do things right the first time?

To read the full post go to: http://sdtimes.com/technical-debt-care/

http://www.ontechnicaldebt.com/blog/technical-debt-what-it-is-and-why-should-you-care/feed/ 0
Technical Debt – What Can You Do http://www.ontechnicaldebt.com/blog/technical-debt-what-can-you-do/ http://www.ontechnicaldebt.com/blog/technical-debt-what-can-you-do/#comments Fri, 28 Nov 2014 09:00:05 +0000 http://www.ontechnicaldebt.com/?p=3221 read more]]> It is often suggested that businesses seek to create minimal viable products. In other words, to only develop the most important core features that allow for the prompt delivery of a product making time to market the most important factor in product development. The inherent problem with this approach is that there has been a conscious decision to only build what is needed right now. Overtime, design can feel cobbled together and difficult to manage.

For example, when writing an application there isn’t a need for user permissions but at some point there will be. At this moment in time adding to the system to manage permissions would be over design, but in the next versions you will need to add users. There are two choices of how to manage adding permissions: 1) take two hours to add a single permission or 2) take 2 days to refactor and make the system more maintainable. The refactoring option significantly reduces the time needed to add permissions in the future. This is technical debt, measuring the difference between a system’s optimal state (refactored solution) and its current state (cobbled together mess of today).

The trouble with technical debt is that business owners have difficulty understanding its consequences because of developers inability to communicate risks in a business-value-driven way. Most businesses ignore it as it takes too much time and costs too much but there are ways to manage technical debt.

To read the full post go to: https://brosteins.com/2014/11/19/technical-debt-can/

http://www.ontechnicaldebt.com/blog/technical-debt-what-can-you-do/feed/ 0
Why is Programming so Hard? – Incidental and Accidental Complexity http://www.ontechnicaldebt.com/uncategorized/why-is-programming-so-hard-incidental-and-accidental-complexity/ http://www.ontechnicaldebt.com/uncategorized/why-is-programming-so-hard-incidental-and-accidental-complexity/#comments Tue, 25 Nov 2014 09:00:24 +0000 http://www.ontechnicaldebt.com/?p=3206 read more]]> Accidental complexity can be referred to as technical debt or sometimes spoken about as incidental complexity – ultimately there is a difference between conscious and unconscious sources of poor code. If it is deliberately decided to deliver suboptimal products, there is a perceived hurry to ship to market. If there is a strong enough incentive to pay the cost of rushing a product, the scenario incurs technical debt because there was a conscious decision to incur that debt. However, this post points out that often when speaking of technical debt, the poor code is not a result of expedited release but because of poor skill or lack of understanding – all in all this code is not tech debt but is sloppy code.

The post recommends speaking about whether lack of quality in code was intentional or not by calling the lack of quality “lack of craftsmanship”. When looking at source code sometimes there is a complexity present that could have been avoided if there were more time, money, or skill. This post states that figuring out the difference between sloppy code and technical debt doesn’t really matter, as the actions needed to resolve the problems caused by both are the same. As long as there is an awareness of the distinction between releasing ‘too early’ for different reasons and that there is always room to improve skills in order to avoid unnecessary complexity.

To read the full post go to: http://xlntconsulting.blogspot.ca/2014/11/why-is-programming-so-hard.html

http://www.ontechnicaldebt.com/uncategorized/why-is-programming-so-hard-incidental-and-accidental-complexity/feed/ 0
Pay Yourself First: The Art Of Reducing Technical Debt http://www.ontechnicaldebt.com/uncategorized/pay-yourself-first-the-art-of-reducing-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/pay-yourself-first-the-art-of-reducing-technical-debt/#comments Mon, 17 Nov 2014 09:00:05 +0000 http://www.ontechnicaldebt.com/?p=3200 read more]]> Technical debt acts as negative interest on your time that continues to accrue while you work. Here is a post that goes beyond this definition in order to come up with a ‘pay yourself first’ technique to reducing technical debt overtime.

The example of technical debt given in this post is when in one case software is installed into one machine which only takes 20 minutes; however, if this needs to be repeated on 50 machines what seemed to be a simple and quick task multiplies in work and time required to complete. In another case, 8 hours of time is spent upfront automating the task which in the future would increase the ability to write scripts and if it needed to be installed on 24 more computers it would end up winning on time invested. This demonstrates the advantage of automation and reducing technical debt, but with debt much times already present there needs to be a method to pay it off.

The post refers to David Chilton’s book, The Wealthy Barber, in order to take the method of paying yourself first that he presents. Paying yourself first, in the financial sense the book refers to, means setting aside 10% of your pay and putting it away – which in short term won’t affect you but ” the long term net effect is great because of compounding benefits of the base amount growing”. This method can be reappropriated for the use of reducing technical debt by spending 10% of each day making changes to reduce debt currently present. This can be done by writing or improving a script to automate a process, meet with stakeholders to build better feedback loops, or spending an hour with training materials.  Asides from this technique of setting aside time daily to reduce debt, making meetings a more effective use of time is important. In a meeting there should be a person designated to writing down task and those responsible for those tasks and make sure that there is ‘meaty’ content at the heart of the meeting. 

Ultimately, the point of this post is to inspire daily reduction of technical debt which in the long term will “pay off in dividends”. To read the full post go to: http://www.discoposse.com/index.php/2014/11/09/pay-yourself-first-the-art-of-reducing-technical-debt/   

http://www.ontechnicaldebt.com/uncategorized/pay-yourself-first-the-art-of-reducing-technical-debt/feed/ 0
The Problem With “Technical Debt” And Other Agile Terms http://www.ontechnicaldebt.com/uncategorized/the-problem-with-technical-debt-and-other-agile-terms/ http://www.ontechnicaldebt.com/uncategorized/the-problem-with-technical-debt-and-other-agile-terms/#comments Wed, 12 Nov 2014 09:00:50 +0000 http://www.ontechnicaldebt.com/?p=3186 read more]]> Technical debt, as a term, serves to incentivize change within app and portfolio management. However, it fails to translate with business leaders, therefore failing to push through with the change it seeks to promote. In this post, Phil Murphy expands on his love/hate relationship with the term; lauding the “sentiment for change” it inspires, but criticizing that it does not fully express the fact that both technical and business sides of a firm suffer from technical debt.

In his defence of technical debt Murphy states that opting for expedient change over refactoring code has left app portfolios with heavy amounts of accrued debt. This daunting amount of debt ends up becoming a “self fulfilling prophecy” – as it’s too large to tackle and therefore ignored until a later date. This ignored debt ends up consuming much of the percentages that could be spent on business technology, and in the age of the costumer where quickly building mobile apps and costumer facing is highly important, technical debt serves to severely slow down change velocity.

Although Murphy appreciates the change that technical debt highlights must happen in the app and portfolio level, his ‘hate’ for the term comes from it’s inability to translate into business leaders’ language. Leading off with the word technical doesn’t do much to help motivate the business side of a firm to act on the problem (technical has to do with IT, it’s not business’ problem). Another way in which business leaders can react to technical debt is that it is debt that the technical side of the firm created, therefore it is their responsibility.

What Murphy concludes is that there is a problem of communication when it comes to technical debt. In order to resolve this, there must be an effort to avoid using jargon and to simply speak to business leaders in terms they understand.

To read the full post go to: http://blogs.forrester.com/phil_murphy/14-11-07-the_problem_with_technical_debt_and_other_agile_terms

http://www.ontechnicaldebt.com/uncategorized/the-problem-with-technical-debt-and-other-agile-terms/feed/ 0
The Broken Windows Theory of Technical Debt http://www.ontechnicaldebt.com/blog/the-broken-windows-theory-of-technical-debt/ http://www.ontechnicaldebt.com/blog/the-broken-windows-theory-of-technical-debt/#comments Thu, 06 Nov 2014 09:00:50 +0000 http://www.ontechnicaldebt.com/?p=3182 read more]]> Technical debt is often treated as an afterthought; teams convince themselves that they have taken into account the extra time and effort required to address tech debt in their planning, making it easy to justify carrying debt for a long time. One way to explain the side effects of carrying on small amounts of technical debt that are difficult to identify, is to compare tech debt build up to the broken window theory. Broken windows is a crime theory developed in the 1980s in which low level crimes (such as vandalism) when ignored, are followed by the prevalence of larger and more serious crimes. Broken windows set a norm of behaviour for the community, in which people adjust themselves to more criminal or antisocial attitudes. This gradually causes the neighbourhood to become more run down and dangerous.

This theory can apply to products as well. Short term solutions and dirty fixes build up in code acting like vandalism in a neighbourhood. If a code is ugly and difficult to work with adding more quick and dirty work begins to take on less significance in the developer’s mind. Subconsciously, developers lower their standards because why would they bother doing good work if it is likely to be the only good code in the project or likely to get written over? Thus, cutting corners on code becomes the broken window in the neighbourhood that leads to more serious problems in the future.  The solution to broken windows, in this post, is to fix all the windows that are already broke and make it high priority to rapidly fix and new breaks that occur – identifying the biggest problems in the code base and tackling these first. In order to prevent the reoccurrence of broken windows teams must weigh the priorities of delivering new and improved features fast vs. paying off technical debt – avoiding the build up of technical debt may mean slower delivery on new features but it also helps to build a better product.

To read the full post on technical debt and broken windows go to: http://www.mindtheproduct.com/2014/11/the-broken-windows-theory-of-technical-debt/

http://www.ontechnicaldebt.com/blog/the-broken-windows-theory-of-technical-debt/feed/ 0