On Technical Debt http://www.ontechnicaldebt.com Online Community Mon, 14 Jul 2014 13:07:10 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.1 Meta-Architecture: The Solution to Architecture Technical Debt? http://www.ontechnicaldebt.com/uncategorized/meta-architecture-the-solution-to-architecture-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/meta-architecture-the-solution-to-architecture-technical-debt/#comments Fri, 11 Jul 2014 14:59:14 +0000 http://www.ontechnicaldebt.com/?p=3059 read more]]> One of the mantras of Agile development teams is to do “just good enough” to get the job done. This is what drives the creation of  architecture that meets the bare minimum requirements to function. But the “just good enough” mindset is an easy way to incur technical debt.

This is what the post, Architecture Technical Debt: The Curse of Agile?, addresses. The challenge of Agile teams, since they follow  the “good enough” mantra, is to have well-planned technical debt that is manageable in the future so that they can continue being Agile. But here we run into a conflict in the mindset of Agile teams. The “just good enough” attitude makes architecture messy, which inherently means you are avoiding any planning of architecture technical debt, and actually taking the time to have well-planned technical debt goes further than “just good enough” architecture – and this is seen as not Agile.

So what is the solution to this architecture technical debt problem? Agile teams believe that code cannot be complete and short-cut free in early iterations and put out what is “just good enough” for today because change overtime is a constant factor in software design. In order to get over the conflict that we’ve run into for architecture technical debt, Agile architecture must happen above the software architecture level at the meta-level. When creating meta-architecture  you’re not thinking about the architecture itself, but how it changes overtime and how to support that change by evolving the architecture. The idea behind meta-architecture is summed up concisely at the end of this post: “Building software following Agile methods isn’t enough. You must also implement architecture that is inherently Agile, and for that, you need meta-architecture.”

To read the full post and learn more about Agile architecture technical debt and meta-architecture go here: http://www.devx.com/blog/agile/architecture-technical-debt-the-curse-of-agile.html

http://www.ontechnicaldebt.com/uncategorized/meta-architecture-the-solution-to-architecture-technical-debt/feed/ 0
Effective Teams; Always Releasable http://www.ontechnicaldebt.com/blog/effective-teams-always-releasable/ http://www.ontechnicaldebt.com/blog/effective-teams-always-releasable/#comments Thu, 03 Jul 2014 15:18:24 +0000 http://www.ontechnicaldebt.com/?p=3045 read more]]> Here is a short and sweet post in a series about effective development teams. The content of the article is pretty standard technical debt overview. First, that what often prevents teams from achieving their optimal goals is their software. Software that is burdened with loose ends in the source code or where there is too much technical debt that there isn’t enough time for to pay back. The solution presented in the post, is that to prevent technical debt from sneaking in you have to write clean code.  “Code that is as simple as possible and as understandable as possible. Code that is so easy to understand that defects cannot hide in it.” This can be done through refactoring code before adding changes – and making sure the changes you make are clean.

This isn’t new information, and the post doesn’t go into depth on the subject of refactoring, technical debt, or clean code – but what was the most helpful about this post was the diagram posted on technical debt. It’s reminiscent of an economic quantity demanded vs. price level graph, but explains in clearly that to suppress technical debt, ideally the cost of change over time should be low and the responsiveness to change over time should be high. This visual representation of a term that is not usually easily explained or visualized is really a nice reference to keep in mind when trying to explain technical debt.

To read the full post go here: http://www.planetgeek.ch/2014/06/12/effective-teams-always-releasable/#more-5431

CoC vs. Responsiveness to change


http://www.ontechnicaldebt.com/blog/effective-teams-always-releasable/feed/ 0
Technical Debt 101: More Haste, Less Speed http://www.ontechnicaldebt.com/blog/technical-debt-101-more-haste-less-speed/ http://www.ontechnicaldebt.com/blog/technical-debt-101-more-haste-less-speed/#comments Mon, 30 Jun 2014 21:33:49 +0000 http://www.ontechnicaldebt.com/?p=3031 read more]]> This is a really interesting post (which cites our interview with Steve McConnell on how to communicate technical debt) that delves into the culture surrounding technical debt management. Using comparisons to civil engineering and biblical references, this post goes deep into the analogy of technical debt.

The debt analogy has been used to explain to non-technical managers that “every time you don’t write software based on the best possible practices and understanding of the business domain, you incur in a technical debt.” However, technical debt is only  when conscious design decisions are made, with a plan to pay off the shortcuts taken. This distinction must be made or else it becomes easy to define technical debt as simply bad code. This difference is difficult to explain, as management does not precisely understand the concept of technical debt as it is not easily seen. It is then the responsibility of the technical team to make management understand the burden of debt and to change the culture that misunderstands it.

Here, this post begins to explain how technical debt and poor practices mount in an organization. Unrealistic deadlines and hubris of the consequences of tech debt allow for it to get out of control. Technical debt is about a trade off between payment now by holding off on a design decision and payment later by factoring in the proper code. It has to be made clear that not planning out quality control on applications will start affecting a company’s strategy by making processes much, much slower.

Ultimately, this post isn’t only about how to reduce technical debt, but how to change management’s view and handling of the concept,  so that it is no longer acceptable to keep piling it on and excusing bad code as a result.

To read the full post go here: https://medium.com/@joaomilho/e29070811b84

http://www.ontechnicaldebt.com/blog/technical-debt-101-more-haste-less-speed/feed/ 0
Technical Debt: What, Why, and How http://www.ontechnicaldebt.com/blog/technical-debt-what-why-and-how/ http://www.ontechnicaldebt.com/blog/technical-debt-what-why-and-how/#comments Wed, 25 Jun 2014 21:00:16 +0000 http://www.ontechnicaldebt.com/?p=3022 read more]]> Here’s post that was cited in the article we recommended previously (Architectural Debt and Moving to Software-defined Architectures) that gives a clear and detailed description of technical debt. Technical debt is broken down, by Steve Mconnell CEO at Construx,  into two basic types: debt incurred unintentionally (the result of unplanned poor work) and debt incurred intentionally (a conscious decision was made to optimize for the present rather than the future). The majority of this post focuses on the the debt incurred intentionally or strategically as it is the most common occurrence of technical debt.

The post goes into several factors that play into servicing, accumulating, and communicating about technical debt. For example,  debt is usually more acceptable to business staff than to the technical staff who face the challenge  of communicating the existence of technical debt. This post provides an overview of not just what technical debt is, but how within an organization it needs to be handled as a topic of discussion and kept under control.

Find out more about the different types of technical debt and the attitudes surrounding it here: http://www.construx.com/10x_Software_Development/Technical_Debt/

http://www.ontechnicaldebt.com/blog/technical-debt-what-why-and-how/feed/ 0
Architectural Debt and Moving to Software Defined Architectures http://www.ontechnicaldebt.com/blog/architectural-debt-and-moving-to-software-defined-architectures/ http://www.ontechnicaldebt.com/blog/architectural-debt-and-moving-to-software-defined-architectures/#comments Wed, 25 Jun 2014 17:33:38 +0000 http://www.ontechnicaldebt.com/?p=3019 read more]]> This article gives us an in depth look at another type of IT debt: architectural debt. It starts off with the jarring statistic that 72% of IT budgets are usually spent “keeping the lights on” or in other words day-to-day maintenance. The only way to reduce this proportion of the budget dedicated to maintenance is to address its cause.

Here is where architectural debt comes into the picture. The more we move to software defined architectures, that rely heavily on integration and automation, complexity arises in the face of changes to support loosely coupled and highly integrated data center architecture. In simpler terms the implications of a a generation of architectural decisions accumulate debt  as we try to move forward to more automated efficient network processes.

Example: The choice of scripting languages used has much more of an impact than is usually thought. If you have a disparate set of object models and interfaces through which services are provisioned system entropy will occur. System entropy is when “as a system is modified, its disorder, or entropy, always increases”.

Ultimately to avoid entropy, architectural debt must be reduced. Software defined architectures become a better  mode through which to manage architectural debt and reduce day-to-day expenses, as  they can contain architectural debt as well.

To read the full article and get a fuller look into architectural debt click here: http://devops.sys-con.com/node/3110908

http://www.ontechnicaldebt.com/blog/architectural-debt-and-moving-to-software-defined-architectures/feed/ 0
The One Cost Engineers and Product Managers Don’t Consider http://www.ontechnicaldebt.com/blog/the-one-cost-engineers-and-product-managers-dont-consider/ http://www.ontechnicaldebt.com/blog/the-one-cost-engineers-and-product-managers-dont-consider/#comments Tue, 24 Jun 2014 21:08:27 +0000 http://www.ontechnicaldebt.com/?p=3015 read more]]> Kris Gale, VP Engineering at Yammer, in this article writes about a highly ignored cost: the complexity cost. Gale explains this cost as the debt accumulated by complicating features or technology to solve problems. The implementation of a new complicated feature is only a small fraction of the work needed to support and maintain that feature. Good engineering is about finding the most cost-effective solution to a problem. Therefore, when adding a feature the question should not be: “how hard would it be to add?” but “how much more complicated does it get with the addition?” The best way to eliminate complexity cost is data. Testing the impact of each change made to existing code can eliminate negative and neutral changes to the product, and preemptively save by just dropping a feature that does not log its usage. Gale ends with emphasizing simplicity in the product, code, and communication. The value is in what gets used and this mindset speeds up the development process and cuts the complexity cost.

Read the full article here: http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider


http://www.ontechnicaldebt.com/blog/the-one-cost-engineers-and-product-managers-dont-consider/feed/ 0
Reducing Technical Debt… Encouraging Software Developers to Document Code http://www.ontechnicaldebt.com/blog/reducing-technical-debt-encouraging-software-developers-to-document-code/ http://www.ontechnicaldebt.com/blog/reducing-technical-debt-encouraging-software-developers-to-document-code/#comments Mon, 23 Jun 2014 17:35:29 +0000 http://www.ontechnicaldebt.com/?p=3010 read more]]> Documentation debt is often overlooked by software developers and this post provides efficient ways of using persuasive technology (which is computer technology designed with the goal of shaping or changing attitudes and behavior)  to encourage programmers to document their code.

We thought this post was very interesting as it notes a sub-element of technical debt. This type of debt can occur when there isn’t sufficient internal documentation – such as code comments – that accumulate to make code maintenance more difficult. In the presentation they’ve attached it is stated that 40%-60% of maintenance time is spent on studying the software prior to modifying it, because of lack of appropriate documentation.

This is worthy of some note and  provided is the free downloadable paper that this post and presentation are based on.


Read the full post here: http://effectivesoftwaredesign.com/2014/06/22/reducing-technical-debt/


http://www.ontechnicaldebt.com/blog/reducing-technical-debt-encouraging-software-developers-to-document-code/feed/ 0
“Real Options” for Technical Debt http://www.ontechnicaldebt.com/events/upcoming-events/real-options-for-technical-debt/ http://www.ontechnicaldebt.com/events/upcoming-events/real-options-for-technical-debt/#comments Wed, 18 Jun 2014 15:41:35 +0000 http://www.ontechnicaldebt.com/?p=3005 read more]]> An interesting presentation is going on tomorrow about technical debt and the “real options” to balancing short term market  goals with long term stability. The process of taking out technical debt isn’t what’s difficult, knowing when you are accumulating debt and keeping track of it is the challenge. The event will be hosted by Agile Iowa with speaker Ryan Bergman, a software architect and programmer for John Deere Intelligent Solutions Group.  If you are able to make it, this event could offer a practical and valuable  approach to managing your technical debt. More information and registration here.

http://www.ontechnicaldebt.com/events/upcoming-events/real-options-for-technical-debt/feed/ 0
Webinar: How to Reverse Your Technical Debt http://www.ontechnicaldebt.com/blog/webinar-how-to-reverse-your-technical-debt/ http://www.ontechnicaldebt.com/blog/webinar-how-to-reverse-your-technical-debt/#comments Wed, 04 Jun 2014 16:30:00 +0000 http://www.ontechnicaldebt.com/?p=2992 read more]]> There’s an interesting webinar that will be taking place in a couple of days about strategies on how to reverse Technical Debt. Deloitte directors for Deloitte Consulting, David Sisk and Scott Buchholz, will be discussing the different techniques that can be used in the context of large IT organizations. We all know how hard it is to reserve Technical Debt once it has been taken on… And we all know how important it is to manage it to help drive business innovation. Based on what we’ve heard, this should be a pretty pragmatic, hands-on session about overcoming the challenges of tackling technical debt. More information and registration here.

http://www.ontechnicaldebt.com/blog/webinar-how-to-reverse-your-technical-debt/feed/ 0
Technical Debt – Breaking the Poor Development Cycle http://www.ontechnicaldebt.com/blog/technical-debt-breaking-the-poor-development-cycle/ http://www.ontechnicaldebt.com/blog/technical-debt-breaking-the-poor-development-cycle/#comments Wed, 30 Apr 2014 20:47:56 +0000 http://www.ontechnicaldebt.com/?p=2985 read more]]> A comprehensive treatment of the cost and impact of technical debt on the developer, the team and the mission. This post illustrates the vicious cycle that technical debt causes for the development organizations, including frequent incidents and hot-fixes, resulting in deprecating condition of the code base. It also talks about some techniques to break out of the cycle at each possible step in the cycle. It ends with some hints for project managers and IT leaders to consider in breaking the typical habits of organizations in order to counteract the buildup of technical debt.

Technical Debt Cycle






Read the full post here: http://devmgrblog.blogspot.co.nz/2014/01/technical-debt-breaking-cycle.html


http://www.ontechnicaldebt.com/blog/technical-debt-breaking-the-poor-development-cycle/feed/ 0