Tag: technical debt

Posted on

Outsourcing Technical Debt Retirement Projects

From time to time, people ask me about the wisdom of outsourcing technical debt retirement projects. Because the answer depends so strongly on the particulars of the situation, there’s no general answer. But there are general guidelines—factors to consider when making the decision. Let’s refine the question first, in the form of a case:

Our organization uses an array of software and hardware assets to execute our mission. We developed some of these systems so long ago that the original developers have departed. They left here for other companies, or they left in spinoffs, or they moved on to other parts of our company. Some of these moves were due to reorganizations, some to promotions, and some to personal career decisions.

Most of the people who are now maintaining these assets have learned by doing.  This has been necessary because we haven’t kept the documentation current enough to be a reliable reference. We know that the systems harbor significant levels of technical debt, and the documentation itself carries debt. So we want to retire all that debt, but it’s a big job. Should we hire contractors? Or a vendor who specializes in large scale technical debt retirement projects?

This is a typical situation, but many variables are unspecified. And typically, even more variables are unknown. Those unspecified or unknown variables make the decision tricky. To illustrate, I’ve listed below seven issues that would affect decisions about outsourcing technical debt retirement projects.

In-house staff probably has useful knowledge
Deciding about outsourcing technical debt retirement?
The dilemma: outsource technical debt retirement, or do the work in-house?

If the in-house staff has much undocumented information about the current configuration of the assets, they have an enormous advantage over contractors or an outside vendor trying to do the same work. And even though the in-house staff wasn’t involved in initial development, they probably have valuable knowledge of the asset if they’ve been engaged in maintenance or enhancement to any significant degree. And they probably know more about the assets than any outsider would. So if the ultimate decision is to outsource the work, try to devise an arrangement in which the most knowledgeable in-house staff are acting in a reference role.

Debt retirement effectiveness depends on knowledge of enterprise strategy

Knowledge of enterprise strategy is useful in technical debt retirement projects. For example, suppose we know that a future project will be rendering some or all of a given asset irrelevant. We can use that knowledge to focus the debt retirement effort.

However, in some cases, revealing strategy to outside vendors is risky, even with ironclad NDAs in place. So some asset owners avoid revealing strategy information. They accept that the outside vendor might perform otherwise-wasteful tasks. This approach can be a low-cost way to manage the risks that arise from revealing strategy. Others choose to perform the work in-house. Working in-house enables them to use their knowledge of strategic direction when allocating effort in debt retirement or when deciding what the transformed asset should look like.

Detailed knowledge of the debt retirement effort is itself valuable

Knowledge of the what and why of the actual debt retirement work can be helpful in resolving any difficulties that surface after completion. That knowledge is also helpful in future work on similar assets.

With outsourcing, after the work is done, any unreported information about what the vendor did and why they did it departs with them. If in-house staff perform the work, that information remains in-house. This can be very helpful if the asset is a critical asset, or if you expect further future enhancement work or debt retirement work on that asset or similar assets.

Debt retirement work almost inevitably generates new knowledge

When people work on debt retirement, they usually have specific objectives. Even so, as they work, they generally uncover issues they hadn’t anticipated. Both in-house staff and contractors experience these aha’s. The difference between them is what happens after the work is done.

If in-house staff does the work, they can use this newfound knowledge in other projects, including new development. Not necessarily so with the outside vendor. If the same vendor is employed again for another effort, they can apply that knowledge if doing so is in scope for the next contract. But if that vendor doesn’t return, or the scope of subsequent efforts doesn’t permit it, then they can’t apply that knowledge. Moreover, the vendor might not even report what they found, though most would because they hope it will lead to more work. If they do report it, the in-house contract monitor should be sophisticated enough to recognize how valuable that kind of information is. Sadly, many are not.

Asset service disruptions can be problematic

Another difficulty with outsourcing technical debt retirement projects relates to asset service disruptions. In some debt retirement efforts, some assets must be taken out of service for periods that are moderately disruptive or worse. In-house staff likely have relationships of long standing that make cooperation, negotiation, and consideration relatively easy.

If negotiation difficulties arise, the lowest level executive or manager who’s responsible for all parties can facilitate resolution. And over time, with practice, all parties learn to work out these issues more effectively. With outside vendors, this process can be more difficult, because of the absence of existing relationships, the termination of relationships when vendors exit the scene, and the lack of formal authority of some specific executive or manager.

If in-house staff can’t do the work, consider hiring

If the in-house staff is overloaded, or if they lack the skills necessary to take on the technical debt retirement effort, outsourcing can seem like the only workable approach. Not so fast though. If a stream of debt retirement projects is in your future, consider the advantages of building a debt retirement function with a long-term agenda. Examine again the factors cited above to determine the scale of the advantages of building such a team.

Outsourcing probably works well for refactoring

The one activity for which outsourcing can be a big win is refactoring. Refactoring doesn’t usually require much knowledge of company strategy. And it doesn’t require much “non-localizable” knowledge. That is, the requirement that the refactoring not cause changes in asset behavior enables the asset owner to write a very tight contract with the debt retirement team. They can then perform their work with confidence because they can test the asset’s behavior incrementally. Also, with refactoring, asset service disruptions are usually minimal.

One last suggestion. With outsourcing, the vendor might have significantly more experience with technical debt retirement efforts than does the client. This asymmetry gives the vendor an advantage at every stage. For technical debt retirement efforts, they know more about contracting, devising statements of work, defining acceptance criteria, and managing risk. Most important, they have experience dealing with the many speed bumps that can occur in these projects. To manage the risks of that advantage, consider retaining a consultant experienced in these situations. This person’s role is to monitor communications between enterprise and vendor to ensure fairness. The mere presence of such an individual can deter the vendor from some of the abuses that can be so tempting in these asymmetric situations when trouble arises.

Other posts in this thread

Posted on

Retiring technical debt in irreplaceable assets

Last updated on December 10th, 2018 at 02:53 pm

Before designing a project to retire some portion of the technical debt borne by a critical, irreplaceable asset, it’s best to acknowledge that the project design problem is very likely a wicked problem in the sense of Rittel and Webber [Rittel 1973]. (See my post “Retiring technical debt can be a wicked problem”) In the series of posts of which this is the first, I suggest some basic preparations that form a necessary foundation for success in approaching the problem of designing projects to retire technical debt in irreplaceable assets.

A map of the U.S. Interstate Highway System
A map of the U.S. Interstate Highway System. The map shows primary roadways, omitting most of the urban loop and spur roads that are actually part of the system. In 2016, the total length of highways in the system was about 50,000 miles (about 80,000 km). About 25% of all vehicle miles driven in the U.S. are driven on this system. The cost to build it was about USD 500 billion in 2016 currency. Given the advances since the 1950s in technologies such as rail, electronics, data management, and artificial intelligence, and given the effects of petroleum combustion on global climate, one wonders whether such a system would be the right choice if construction were to begin today. If alternatives would be better, then this system might be regarded as technical debt. But replacing it might not be practical. Finding a way to retire the technical debt without replacing the entire asset might be the most viable solution. Image by SPUI courtesy Wikipedia.

As I’ve noted in previous posts, the problems associated with retiring technical debt can be wicked problems. And if some of these problems aren’t strictly wicked problems, they can possess many of the attributes of wicked problems in degrees sufficient to challenge the best of us. That’s why approaching a technical debt retirement project as you would any other project is a high-risk way to proceed.

For convenience and to avoid confusion, in my last post I adopted the following terminology:

  • DRP is the Debt Retirement Project
  • DDRP is the effort to design the DRP
  • DBA be the set of Debt Bearing Assets undergoing modification in the context of the DRP
  • IA is the set of assets, excluding the DBA assets, that interact directly or indirectly with assets in the DBA

In the posts in this thread, convenience demands that we add at least one more shorthand term:

  • TDIQ is the Technical Debt In Question. That is, it’s the kind of technical debt we’re trying to retire from the assets among the DBA. Other instances of the TDIQ might also be found elsewhere, in other assets, but retiring those instances of the TDIQ is beyond the scope of the DRP.

Know when and why we need to retire technical debt

For those technical debt retirement projects that exhibit a high degree of wickedness, clearly communicating the mission of the DRP is essential to success. The DRP team will be dealing with many stakeholders who are in the early stages of familiarity with the term technical debt. Some of them might be cooperating reluctantly. Expressing the objectives and benefits of the DRP in a clear and inspiring way will be very helpful. With that in mind, I offer the following reminder of the reasons for tackling such a large and risky project that produces so few results immediately visible to customers.

Examining alternatives to retiring the TDIQ is a good place to begin. One alternative is simply letting the TDIQ remain in place. Call this alternative “Do Nothing.” A second alternative to retiring the TDIQ is replacing the debt-bearing asset with something fresh and clean and debt-free. Call this alternative “Replace the Asset.” The problem many organizations face is that they cannot always rely on these alternatives. In some circumstances, the only viable option is debt retirement. And because these two alternatives to debt retirement aren’t always practical, some organizations must develop the expertise and assets necessary to retire widespread technical debt in large, critical, irreplaceable systems. Below is a high-level discussion of these alternatives to debt retirement.

Do Nothing

The first alternative is to find ways to accept that the DBA will continue to operate in their current condition, bearing the technical debt that they now bear. This alternative might be acceptable for some assets, including those that are relatively static and which need no further enhancement or extension. This category also includes those assets the organization can afford to live without.

One disadvantage of the “Do Nothing” approach is that technology moves rapidly. What seems acceptable today might be, in the very near future, old-fashioned, behind the times, or non-compliant with future laws or regulations. Styles, fashions, technologies, laws, regulations, markets, and customer expectations all change rapidly. And even if the asset doesn’t change what it does, the organization might need to enhance it in ways that become very expensive to accomplish due to the technical debt the asset carries.

For these reasons, Do Nothing can be a high-risk strategy.

Replace the Asset

The second alternative to retiring the TDIQ is to replace the entire asset. For this option, the question of affordability arises. In some instances this alternative is practical, but for many assets, the organization simply cannot afford to purchase or design and construct replacements. And for those assets that “learn”, and which contain data gathered from experience over a long period of time, retiring the asset can require developing some means of recovering the experience data and migrating it to the replacement asset—a potentially daunting effort in itself.

Replacement is especially problematic when the asset is proprietary. If the organization created the asset itself, they might have constructed it over an extended period of time. Replacement with commercial products will require extensive adaptation of those products, or adaptation of organizational processes. Replacement with assets of its own making will likely be costly.

Thus, when organizations depend on assets that they must enhance or extend, and which they cannot afford to replace in their entirety, they must develop the expertise and resources needed to address the technical debt that such assets inevitably accumulate.

This series of posts explores the issues that arise when an organization undertakes to retire the technical debt that its irreplaceable assets are carrying. Below, I’ll be inserting links to the subsequent posts in this series.

Other posts in this thread

References

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:
Posted on

Managing technical debt

Last updated on August 24th, 2019 at 05:57 pm

Managing technical debt is something few organizations now do, and fewer do well. Several issues make managing technical debt difficult and they’re discussed elsewhere in this blog. This thread explores tactics for dealing with those issues from a variety of initial conditions. For example, tactics that work well for an organization that already has control of its technical debt, and which wants to keep it under control, might not work at all for an organization that’s just beginning to address a vast portfolio of runaway technical debt. The needs of these two organizations differ. The approaches they must take might then also differ.

A jumble of jigsaw puzzle pieces. Managing technical debt can be like solving a puzzle.
A jumble of jigsaw puzzle pieces. Where do we begin? With these puzzles, we usually begin with two assumptions: (a) we have all the pieces, and (b) they fit together to make coherent whole. These assumptions might not be valid for the puzzle of technical debt in any given organization.

The first three posts in this thread illustrate the differences among organization in different stages of developing technical debt management practices. In “Leverage points for technical debt management,” I begin to address the needs of strategists working in an organization just beginning to manage its technical debt, and asking the question, “Where do we begin?” In “Undercounting nonexistent debt items,” I offer an observation about a risk that accompanies most attempts to assess the volume of outstanding technical debt. Such assessments are frequently undertaken in organizations at early stages of the technical debt management effort. In “Crowdsourcing debt identification,” I discuss a method for maintaining the contents of a database of technical debt items. Data maintenance is something that might be undertaken in the context of a more advance technical debt management program.

Whatever approach is adopted, it must address factors that include technology, business objectives, politics, culture, psychology, and organizational behavior. So what you’ll find in this thread are insights, observations, and recommendations that address one or more of the issues related to these fields. “Demodularization can help control technical debt” considers mostly technical strategies. “Undercounting nonexistent debt items” is an exploration of a psychological phenomenon.  “Leverage points for technical debt management” considers the organization as a system and discusses tactics for altering it. And “Legacy debt incurred intentionally” explores how existing technical debt can grow as long as it remains outstanding.

Accounting issues also play a role. “Metrics for technical debt management: the basics” is a basic discussion of measurement issues. “Accounting for technical debt” looks into the matter of accounting for technical debt financially. And “Three cognitive biases” is a study of how technical debt is affected by the way we think about it.

Posts in this thread:

References

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:
Posted on

Crowdsourcing debt identification

I have often expressed the view that the people of the organization know where much of their technical debt is, or they can find it fairly quickly. To exploit this resource, what’s needed is a systematic method for gathering what they know to produce a database that can serve as a starting point for further investigation. We might call this part of the debt identification process “crowdsourcing debt identification.”

A crowd
A crowd. Crowds are powerful when they coordinate their actions.

When an organization first undertakes to manage its technical debt, one of the many initial tasks is identifying its existing technical debt. There are tools for executing some of this task, at least for software assets, and they are useful. But because they’re in an early stage of development, and because many non-software assets also carry technical debt, human assistance is required. And that’s the place where crowdsourcing can help.

For example, if you ask engineers for examples of technical debt in the assets they work on regularly, they can rattle off a few examples without hesitation. But a few days later, while working on whatever task has focus that day, they’ll realize that they could have mentioned another painful item. And they’ll want to report it. Gathering that kind of information is very helpful to the debt identification effort. That’s crowdsourcing in action.

But investment is required for crowdsourcing to be effective. We must educate the people who will be doing the reporting, and we must give them tools to make reporting quick and easy.

Reporting issues

Crowdsourcing debt identification will produce a stream of “incident reports” by Debt Reporters (DRs) that must be interpreted by people we might call Debt Report Administrators (DRAs), who then recast the reports for later investigation by experts in the assets involved. Common difficulties that add to workload of DRAs include:

Inconsistent definitions of technical debt

Lack of uniformity in understanding what technical debt is and isn’t can cause DRs to report as potential debt items some artifacts that aren’t manifestations of technical debt, or worse, they might fail to report items that are.

Only education of the DRs about the organizational definition of technical debt can enhance consistency.

Repeated reporting of previously reported debt items

Unaware that an item has been previously reported, DRs might file reports unnecessarily. Some of these duplications are easily identified, but if the language used in the report is different enough, identifying duplicates can take time.

We can reduce duplication by making available descriptions of previously reported items in multiple forms.

Inconsistent descriptions of debt items

DRA must be able to recognize when two different DRs use different language to describe the same debt item. If they do not, then the debt report database will contain an unrecognized duplication.

The asset expert must then address this situation.

Failure to report known debt items

Some people, pressed by the urgency of their “own work,” might not report debt items they know about, or might hurriedly file low-quality reports. A high incidence of this behavior is an indicator of a deeper organizational issue: namely, that some people do not regard technical debt management as a worthy activity.

Tracking report quality and report frequency is one way to determine how much regard the people of the organization have for the debt management effort.

Report format and content

The act of reporting a potential technical debt item must not be burdensome — it must be easy. A Web-based form is a minimum. Users must be able to prefill some fields common to all their reports, and save the result as a template. Fields they might want to prefill include their personal identity and the asset identity. DRs might need several templates, depending upon the number of assets with which they interact. Switching from one template to another must also be easy.

Several authors have proposed report templates, Below is one due to Foganholi, et al. [Foganholi 2015]. (TD is technical debt)

IDTD identification number
DateDate of TD identification
ResponsiblePerson or role who should fix this TD item
TypeDesign, documentation, defect, testing, or other type of debt
ProjectName of project or software application
LocationList of files/classes/methods or documents/pages involved
DescriptionDescribes the anomaly and possible impacts on future maintenance
Estimated principalHow much work is required to pay off this TD item on a three-point scale: High/Medium/Low
Estimated interest amountHow much extra work will need to be performed in the future if this TD item is not paid off now on a three-point scale: High/Medium/Low
Estimated interest probabilityHow likely is it that this item, if not paid off, will cause extra work to be necessary in the future on a three-point scale: High/Medium/Low
IntentionalYes/No/Don’t Know
Fixed byPerson or role who really fix this TD item
Fixed dateDate of TD conclusion
Realized principalHow much work was required to pay off this TD item on a three-point scale: High/Medium/Low
Realized interest amountHow much extra work was needed to be performed if this TD item was not paid off at moment of detection, on a three-point scale: High/Medium/Low

While this template might be useful for tracking the technical debt item, it contains fields that aren’t needed for crowdsourcing debt identification. A simplified template for crowdsourcing debt identification might look like this:

Identifying Report TitleYour identifier for this report
DateDate of report (prefilled)
TypeDrop down menu of debt types, including “other”
ProjectName of the project sponsoring the work which led to your observation of the debt item
Location of debt itemList of assets involved, including specific location within complex assets
DescriptionDescribe the debt item including
  • Whether your current effort has created it and if so, how

  • Possible impact on present or future maintenance or enhancement efforts

  • Whether it has led to, or is a result of, contagion

  • How it’s affecting your work
IntentionalYes/No/Don’t Know
Asset experts then receive these reports and take one or more of the following actions:
  • Seek further information from the DR.
  • Reject the report as not involving technical debt. (Rejection data is used to assess the effectiveness of the education program)
  • Attach the report to a new or existing debt item, incorporating relevant information from the report into the debt item’s data.

What the asset experts produce, which contains information like that suggested by Foganholi, et al. will be the basis of further analysis and eventual retirement of the debt item.

Conclusions

Investment in ease-of-use for the reporting process is essential for at least three reasons:
  • The reporting responsibility might  be seen as an addition burden beyond the current workload.
  • In many organizations, reporting on technical debt might be seen as a secondary responsibility.
  • Unless technical debt retirements rapidly become common occurrences, reporting might be seen as a waste of effort. The reporting itself must therefore be easy.

These phenomena all exert negative pressure on report quality and tend to suppress report frequency. Ease-of-use can mitigate these effects.

References

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

Other posts in this thread

Related posts

  • Nine indicators of wickedness
    By carefully observing what happens when we actually try to retire some kinds of technical debt, we can better understand the degree of the degree of wickedness of the effort. That understanding helps manage risk in technical debt retirement projects, reducing costs and speeding execution.
  • Degrees of wickedness
    Designing technical debt retirement projects can be a wicked problem. But there can be degrees of wickedness. And wickedness can have dimensions, too.
  • Retiring technical debt can be a super wicked problem
    A subset of wicked problems can be viewed as super wicked, if time is running out, if the central authority fails to act, and if the people who cause them influence the solution. Some technical debt retirement situations qualify as super wicked problems.
  • Retiring technical debt can be a wicked problem
    Retiring technical debt isn’t just a problem, it’s a wicked problem. And that explains many of the difficulties we associate with retiring technical debts that involve many stakeholders, assets, revenue streams, infrastructure, architectures, policies, or strategies.
  • Synergy between the reification error and confirmation bias
    The tendency to underestimate technical debt retirement costs is due, in part to the interaction between the consequences of the reification error and the consequences of confirmation bias. Here are some recommendations for mitigating these effects.
  • Managing technical debt
    Managing technical debt is something few organizations now do, and fewer do well. This thread explores tactics for dealing with a variety of technical debt situations.
Posted on

Using SMART goals for technical debt reduction

Last updated on May 9th, 2019 at 02:17 pm

Attempting to reduce the enterprise burden of technical debt by setting so-called “SMART goals” in the obvious way can often produce disappointing results. SMART, due to George T. Doran [Doran 1981], is a widely used approach for expressing management goals. “SMART” is an acronym for “Specific, Measurable, Attainable, Realistic, and Time-boxed,” though the last three words (the “ART”) are chosen in various alternative ways. Doran himself used “assignable, realistic, and time-related.”

Prof. George T. Doran (1939-2011), creator of the S.M.A.R.T acronym for setting management objectives
Prof. George T. Doran (1939-2011), creator of the S.M.A.R.T acronym for setting management objectives. Watch a 2010 interview of Prof. Doran at YouTube.
SMART is so embedded in management culture that many assume without investigation that expressing technical debt reduction goals directly using the SMART pattern will produce the desired results. Also embedded in management culture is the aphorism, “You get what you measure.” [Ariely 2010]  [Bouwers 2010] Combining these two ideas in a straightforward way, one might express the technical debt reduction goal as, “Reduce the burden of technical debt by 20% per year for each of the next five years.”

There is ample support for a claim that this “direct” approach to applying the SMART technique will be ineffective. The fundamental issue is that so much of employee behavior affects technical debt indirectly that it overwhelms the effects of employee behaviors that affect technical debt directly. The result is that although the direct approach does cause some employees to adopt desirable behaviors, their impact is not significant enough compared to the effects of the behaviors of employees who see little connection between their own activities and the burden of technical debt, or who are subject to competing constraints on their behaviors that then cause them to act in ways that increase technical debt.

That’s why it’s necessary for management to develop a series of SMART goals that affect behaviors that have indirect effects on technical debt. In the first part of this post, “Setting a direct SMART goal for technical debt reduction is problematic,” I explore the problems inherent in the direct approach. In the second part, “How to set SMART goals for technical debt,” I provide examples of SMART goals that touch on behaviors that have indirect effects on technical debt.

Setting a direct SMART goal for technical debt reduction is problematic

Let’s begin by exploring some of the problems with the direct approach. In this section, I assume that management has set a SMART goal for the enterprise in the form, “Reduce the burden of technical debt by 20% per year for each of the next five years.” But there’s nothing special about the numbers. My comments below apply to the form of the goal, rather than the specific numbers.

The direct approach assumes measurability

To attain a goal of a 20% reduction in technical debt in a given year, we must be able to measure the level of technical debt at the beginning of the year and the level at the end of the year, presumably with confidence in the 90% range or better. Such a measurement with the precision required might not be possible. Moreover, in most cases the probability that such a measurement is possible is low. For these reasons, setting periodic goals for total technical debt is not a useful management tool.

Consider a simple example. One form of technical debt—and it’s a common form—is missing or incompletely implemented capability. In some instances, the metaphorical principal (MPrin) of a given instance of this debt in the current year can change spontaneously to a dramatically larger value in the following year (or even the following week), due to changes in the underlying asset unrelated to the technical debt, or due to debt contagion, or due to any number of other reasons. When this happens, the technical debt retirement effort for that year can appear to have suffered a serious setback, even though the technical debt retirement teams might have been performing perfectly well.

The direct approach assumes a static principal

With most financial debts, the principal amount is specified at the time of loan origination. Moreover, we can compute the principal at any time given the mathematical formulas specified in the loan agreement.

By contrast, in many cases, the metaphorical principal amount of a technical debt might be neither fixed nor readily computable. We can estimate the MPrin of a given kind of technical debt at a given time, and we can even make forward projections of those estimates. But they are merely estimates, and their error bars can be enormous. See “Policy implications of the properties of MPrin” and “Useful projections of MPrin might not be attainable.”

The direct approach focuses on MPrin, not MICs

Objectives expressed in terms of the volume of technical debt—the total MPrin—are at risk of missing the point. Total MPrin is not what matters most. What matters is MICs—the total cost of carrying the debt. Even more important is the timing of arrival of the MICs.

And like MPrin, MICs can vary in wild and unpredictable ways. For example, the MICs for a piece of technical debt borne by an asset that isn’t undergoing maintenance or enhancement can be zero; in a later time period, when that asset is undergoing enhancement, the MICs can be very high indeed. See  “MICs on technical debt can be unpredictable” for a detailed discussion.

Priority setting for technical debt retirement is most effective when it takes into account the timing of MICs. For example, if we know that we must enhance a particular asset by FY21 Q3, and if we know that it bears technical debt that adds to the cost of the enhancement, retiring that debt in FY20 would be advisable. On the other hand, if that form of technical debt has no effect on MICs for the foreseeable future, retiring that technical debt might not be worth the effort.

The direct approach fails to distinguish legacy technical debt from incremental technical debt

Unless policies are already in place governing the formation of new technical debt—what I call incremental technical debt—technical debt retirement programs might encounter severe difficulty meeting their goals. The technical debt retirement program might simply be unable to keep up with the formation of new technical debt resulting from new development or from ongoing maintenance and enhancement of existing assets.

The direct approach fails to anticipate the formation of enterprise-exogenous technical debt

Technical debt can sometimes form as a result of innovations, changes in standards, or changes in regulations that occur entirely external to the enterprise. I call such technical debt enterprise-exogenous. When this happens, the technical debt retirement effort can appear to have suffered a serious setback, even though the technical debt retirement teams might have been performing perfectly well. Before initiating a technical debt reduction program, it’s wise to first deploy a program that’s capable of retiring technical debt at a pace that at least equals the pace of formation of enterprise-exogenous technical debt.

Incurring technical debt is sometimes the responsible thing to do

At times, incurring technical debt is prudent. In some situations, accepting the debt you’ve incurred—even for the long term—might be called for. Because strict goals about total technical debt can lead to reluctance to incur debt that has a legitimate  business purpose, whatever goals are set for total technical debt must be nuanced enough to deal with these situations. Goals for total technical debt that adhere strictly to the SMART goal pattern sometimes lack the necessary level of nuance.

How to set SMART goals for technical debt

SMART goals can work for technical debt management, but we must express them in ways that are more closely related to behavioral choices. Here are some examples of SMART goals that can be effective elements of the technical debt management program. Some of these examples are admittedly incomplete. For example,  I offer no proof of assignability, attainability, or realism, because they can vary from organization to organization, or because the goal in question must be distributed across multiple organizational elements in ways peculiar to the organization.

At least 30% of incremental technical debt will be secured technical debt at the end of Year 1; 60% by the end of Year 2

Incremental technical debt is technical debt that’s incurred in the course of work currently underway or just recently completed. Because it’s so well understood, its MPrin can be estimated with higher precision than is usually possible with legacy technical debt. That precision is needed for defining the collateral and resources used to secure the debt.

A secured technical debt, like a secured financial debt, is one for which the enterprise reserves the resources needed to retire the debt. However, unlike a financial debt, the resources required to retire a technical debt might not be purely financial. Beyond financial resources, they might include particular staff, equipment, test beds, and downtime. The commitment might extend beyond the current fiscal period. Secured technical debt is a powerful means of driving down total technical debt burden, but it might require modification of internal budget management processes and fiscal reporting. Policymakers can help in designing and deploying the necessary changes.

Within one year, at least 50% of all incremental technical debt will be retired within one year of its origination; 70% within 18 months

This goal also exploits the fact that incremental technical debt can be estimated with relatively high precision. As a goal, it builds on the goal above by requiring that the resources pledged to retire incremental debts actually be expended as intended.

Within one year, all engineers and their direct supervisors will be educated in basic technical debt concepts

The educational materials will be developed in the next five months and piloted with 10% of the technical staff within seven months. The material will include an online proficiency test that 90% of engineers will have successfully passed within a year.

Within one year, 90% of project plans will include projections of the MPrin of the incremental technical debt they expect to generate for each delivery cycle

This information is useful for making forward projections of resources needed to secure incremental technical debt. Tracking the accuracy of these projections helps project planners improve their estimates.

Within one year, initiate a practice of identifying the top five forms of legacy technical debt, ranked by the volume of the contagion

Debt contagion is the propagation of a given form of technical debt by creating new system elements or assets in forms compatible with elements already identified as technical debt. By examining the body of incremental technical debt created enterprise-wide in a given time period (say, by fiscal quarter), we can determine the portion of that incremental debt that results from contagion, for each type of contagious legacy technical debt. This data is needed to identify the most contagious forms of legacy technical debt. They are prime candidates for debt retirement.

Within one year, initiate an industrial intelligence practice that is responsible for projecting the formation of enterprise-exogenous technical debt

This group must have a sophisticated grasp of the technologies in use within the enterprise that already bear enterprise-exogenous technical debt, or which could be subject to the formation of enterprise-exogenous technical debt. Its responsibilities cover enterprise products and services, as well as enterprise infrastructure. It issues advisories as needed, and an annual forecast. The group is also responsible for recommending and monitoring participation in industrial standards organizations. The group reports to the CIO or CTO.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.

Available: here; Retrieved: June 4, 2018

Cited in:

[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

Other posts in this thread

Posted on

Exogenous technical debt

Last updated on July 24th, 2018 at 07:30 pm

Mastering understanding of exogenous technical debt—debt that arises from causes not directly related to the asset that bears the debt—is essential to controlling technical debt formation. Exogenous technical debt is particularly troublesome to those who work on the affected assets. They can’t control its formation, and they’re rarely responsible for creating it. But their internal customers and those who control resources often fail to understand this. Indeed, those who work on the affected assets are often blamed for the formation of exogenous technical debt even though they had no role in its formation, and could have done nothing to prevent its formation.

Asbestos with muscovite.
Asbestos with muscovite. Asbestos is a family of six minerals that occur naturally in fibrous form. The fibers are all known carcinogens. Until 1990, it was widely used in many common building materials, including insulation, plaster, and drywall joint compound. It is now banned, but it’s present in many existing structures, including homes and offices. The installation of the ban caused these structures to incur exogenous technical debt. Photo by Aramgutang courtesy Wikipedia.

Technical debt is exogenous when it’s brought about by an activity not directly related to the assets in which the debt appears. The word exogenous comes from the Greek exo– (outside) + –genous (related to producing). So exogenous technical debt is that portion of an asset’s debt that comes about from activities or decisions that don’t involve the asset directly.

Because so much technical debt is produced indirectly, controlling its direct formation—for example, by engineering teams—isn’t sufficient for achieving enterprise control of technical debt formation. To control technical debt formation, we must track which activities produce it, including both direct and indirect effects. Allocating technical debt retirement costs to the activities that brought that debt about, even if the allocation doesn’t affect budget authority for those activities, is therefore a useful practice. Knowledge about which past activities created technical debt, and how much, is helpful for long-term reduction in the rate of technical debt formation.

When we think of technical debt, we tend to think of activities that produce it relatively directly. We often imagine it as resulting solely from engineering activity, or from decisions not to undertake engineering activity. In either case the activity involved, whether undertaken or not, is activity directly involving the asset that carries—or will be carrying—the technical debt. This kind of technical debt is endogenous technical debt. The word endogenous comes from the Greek endo– (within or inside) + –genous (related to producing).  So endogenous technical debt is that portion of an asset’s debt that comes about from activities or decisions that directly involve the asset.

More about endogenous technical debt in future posts. For now, let’s look more closely at exogenous technical debt, and its policy implications.

Examples of exogenous technical debt

In “Spontaneous generation,” I examined one scenario in which technical debt formation occurs spontaneously—that is, in the absence of engineering activity. Specifically, I noted how the emergence of the HTML5 standard led to the formation of technical debt in some (if not all) existing Web sites, in the sense that they didn’t exploit capabilities that had become available in HTML5. Moreover, some sites whose developers had elected to emulate capabilities of the new standard by exploiting alternative technologies needed rehabilitation to remove the emulation and replace it with use of facilities in the HTML5 standard. All of these artifacts—including those that existed, and those that didn’t—comprised technical debt. This scenario thus led to the formation of exogenous technical debt.

In a second example, AMUFC, A Made-Up Fictitious Corporation, incurs technical debt when the vendor that supplies the operating system (OS) for AMUFC’s desktop computers announces the date of the end of extended support for the version of the OS in use at AMUFC. Because the end of extended support brings an end to security updates, AMUFC must retire that debt by migrating to the next version of that vendor’s OS before extended support actually ends.

In both of these examples, the forces that lead to formation of exogenous technical debt are external to both the enterprise and the enterprise’s assets. But what makes technical debt exogenous is that the forces that led to its formation are unrelated to any of the engineering work being performed on the asset that carries the debt. This restriction is loose enough to also include technical debt that arises from any change or activity external to the asset, but within the enterprise.

Exogenous technical debt arising from actions within the enterprise

Exogenous technical debt can arise from activities or decisions that take place entirely within the enterprise.

For example, consider a line of mobile devices developed and marketed by AMUFC (A Made-Up Fictitious Corporation). Until this past year, AMUFC has been developing ever more capable devices, thereby extending its line of offerings at the high end—the more expensive and capable members of the line. But this past quarter, AMUFC developed a low-end member of the line, and as often happens, price constraints led to innovations that could produce considerable savings in manufacturing costs if those innovations were applied to all members of the line. In effect, then, the designs of the previously developed models in this line of devices have incurred exogenous technical debt. The debt is exogenous because the activity that led to debt formation was not performed on the assets that now carry the debt, even though the activity that led to debt formation occurred within the enterprise. This kind of exogenous technical debt might be termed asset-exogenous. Exogenous technical debt of the kind that’s incurred by activity beyond the enterprise might be termed enterprise-exogenous.

Exogeneity versus endogeneity

For asset-exogenous technical debt, ambiguity between endogeneity and exogeneity can arise. The example above regarding the line of mobile devices produced by AMUFC provides an illustration.

For convenience, call the team that developed one of the high-end devices Team High. Call the team that developed the low-end device Team Low. From the perspective of Team High, the technical debt due to the innovations discovered by Team Low is exogenous. But from the perspective of the VP Mobile Devices, that same technical debt might be regarded as endogenous. The debt can be endogenous at VP level because it’s possible to regard the entire product line as a single asset, and that might actually be the preferred perspective of VP Mobile Devices.

Exogeneity and legacy technical debt

The technical debt portfolio of a given asset can contain a mix a technical debt that arose from various past incidents. In assessing the condition of the asset, it’s useful to distinguish this existing debt from debt that’s incurred as a consequence of any current activity or decisions. Call this pre-existing technical debt legacy technical debt.

The legacy technical debt carried by an asset is technical debt associated with that asset, and which exists in that asset in any form prior to undertaking work on that asset. For example, in planning a project to renovate the hallways and common areas of a high-rise apartment building, workers discover that beneath the existing carpeting is a layer of floor tile containing asbestos. Management has decided to remove the tile. In this context, the floor tile can be viewed as legacy technical debt. It isn’t directly related to the objectives of the current renovation, but removing it will enhance the safety of future renovations, enable certification of the building as asbestos-free, increase the property value, and reduce the cost of eventual demolition. In this situation asbestos removal amounts to retirement of legacy technical debt, and accounting for it as part of the common-area renovation would be misleading.

When contemplating efforts to retire legacy technical debt, exogeneity becomes a factor in allocating the necessary resources. If the debt in question is enterprise-exogenous, then we can justifiably budget the effort from enterprise-level accounts if appropriate. For other cases, other pools of resources become relevant depending on what actions created the debt. For example, if the exogenous technical debt arose because of a departmental change in standards, debt retirement costs can justifiably be allocated to the standards effort. If the exogenous technical debt arose from innovations in other members of the asset’s product line, those debt retirement costs can justifiably be allocated to the product line.

Policy insights

Understanding the properties of exogenous technical debt can be a foundation for policy innovations that enhance enterprise agility.

Culture transformation

Widespread understanding the distinction between exogenous and endogenous technical debt is helpful in controlling blaming behavior that targets the engineering teams responsible for developing and maintaining technological assets.

Understanding of asset-exogenous technical debt helps non-engineers understand how their actions and decisions can lead to technical debt formation, even when there is no apparent direct connection between those actions or decisions and the assets in question.

Resource allocation

Data about the technical debt creation effects of enterprise activities is helpful in allocating technical debt retirement costs. For example, when we know all the implications of reorganization, including its impact on internal data about the enterprise itself, we can charge data-related activity to the reorganization instead of to general accounts of the Information Technology function. This helps the enterprise understand the true costs of reorganization.

Similarly, data about enterprise-exogenous technical debt helps planners understand how to deploy resources to gather external intelligence about trends that can affect internal assets. Such data is also useful for setting levels of support and participation in industrial standards organizations or in lobbying government officials.

Knowing the formation history of exogenous technical debt provides useful guidance for those charged with allocating the costs of retiring technical debt or preventing its formation.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.

Available: here; Retrieved: June 4, 2018

Cited in:

[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

Other posts in this thread

Posted on

The Tragedy of the Commons is a distraction

Last updated on July 24th, 2018 at 08:19 pm

Many believe that technical debt arises, in part, because of a phenomenon known as the Tragedy of the Commons [Hardin 1968], which is an allegory that purports to demonstrate that the user communities associated with shared resources inevitably degrade those resources until they’re depleted. The allegory supposedly supports the thesis that only monocratic control of an asset can provide the strict regulation that prevents its inevitable degradation as a result of shared use. Advocates of this approach to limiting the degradation arising from the expansion of technical debt hold that assigning sole ownership of resources, resource by resource, is the only effective method of controlling technical debt.

A map of the Boston Common and Public Garden, circa 1890. This is the kind of “common” referred to in the tragedy of the commons.
A map of the Boston Common and Public Garden, circa 1890. By that time it was basically a park. But as late as 1830 it was still being used as a cow pasture. They didn’t have refrigeration at the home scale then, except by ice blocks, and the best way to get fresh dairy products was to have a cow. In the very early days, 1633-1640, anyone could graze on the Common, but as wealthy people acquired more animals, the common became overgrazed, and a 70-cow limit was imposed. That limit stood until 1830. It’s an example of a method for managing a shared resource. This map is from an atlas of Boston published by G.W. Bromley & Co.,, courtesy Wikimedia Commons
The resources in question here are the assets that tend to accumulate, or are accumulating, or have accumulated, technical debt. Adherents of the theory would impose order by dividing each technological asset into one or more sectors, sometimes called development silos, with only one organizational unit designated as the “owner,” empowered to develop, maintain, or extend that sector [Bossavit 2013] [Morris 2012]. Irreconcilable disagreements about the direction or purpose of a particular sector of the asset presumably would be resolved by branching.

Ironically, such an approach would — and demonstrably does — produce significant technical debt in the form of duplication of artifacts and services. Moreover, it elevates costs relative to a truly shared asset, by reducing sharing, and increasing the need for testing. We can regard such an approach as dysfunctional conflict avoidance [Brenner 2016b].

Although at one time the Tragedy of the Commons was regarded as a universally valid concept in political economics, subsequent research has demonstrated that the principle it describes is not generally applicable. Hardin first described the Tragedy of the Commons in 1968, in the form of an allegory [Hardin 1968]. In his words:

Picture a pasture open to all. It is to be expected that each herdsman will try to keep as many cattle as possible on the commons. Such an arrangement may work reasonably satisfactorily for centuries because tribal wars, poaching, and disease keep the numbers of both man and beast well below the carrying capacity of the land. Finally, however, comes the day of reckoning, that is, the day when the long-desired goal of social stability becomes a reality. At this point, the inherent logic of the commons remorselessly generates tragedy.

As a rational being, each herdsman seeks to maximize his gain. Explicitly or implicitly, more or less consciously, he asks, “What is the utility to me of adding one more animal to my herd?”

Hardin then explains that each herdsman is compelled by the logic of the situation to exploit the shared resource to the maximum. Each herdsman puts his own interests ahead of the welfare of the resource.

And so it goes, supposedly, with technical debt. Each user of the shared asset expends resources on development, maintenance, and enhancement only to the extent that the expenditure is justified by immediate need. Retiring any legacy technical debt, or any technical debt accumulated in the course of meeting those immediate needs, is regarded as low priority. Because resources for debt retirement are rarely if ever sufficient to meet the need, technical debt grows inexorably. Eventually, the shared asset becomes unmaintainable and must be abandoned.

However, careful research shows that Hardin’s Commons allegory is not applicable to every situation involving shared resources. That same research casts doubt on the validity of the assertion that development silos are necessary in any approach to technical debt management.

Certainly there are many examples of shared resources degrading along the lines outlined by Hardin, such as the collapse of the Northwest Atlantic cod fishery [Frank 2005], but many counterexamples exist. Research by the late political economist Elinor Ostrom uncovered numerous examples of complex social schemes for maintaining common resources efficiently and sustainably [Ostrom 2009] [Ostrom 1990]. Ostrom studied and reported on systems that successfully managed shared resources over long terms — in some cases, centuries. For this work, she received the Nobel Prize in Economics in 2009.

As Ostrom’s research demonstrated, the problem with Hardin’s allegory is that it applies only to shared resources that are open to use by all without regulation. The misapplication of the Tragedy of the Commons is clearly described in a World Bank Discussion Paper by Bromley and Cernea [Bromley 1989]:

For some time now, Hardin’s allegory of the “tragedy” has had remarkable currency among researchers and development practitioners. Not only has it become the dominant paradigm within which social scientists assess natural resource issues, but it appears explicitly and implicitly in the formulation of many programs and projects and in other beliefs and prejudices derived from it. Unfortunately, its power as a metaphor is not matched by its capacity for aiding our understanding of resource management regimes. By confusing an open access regime (a free-for-all) with a common property regime (in which group size and behavioral rules are specified) the metaphor denies the very possibility for resource users to act together and institute checks and balances, rules and sanctions, for their own interaction within a given environment.

Hardin himself later published an extension of the allegory that clarified the role of regulation [Hardin 1998], as had been observed much earlier by Lloyd [Lloyd 1833].

The real tragedy for technology managers would be their failure to learn from the past errors of social scientists and political economists, and to then repeat, in the context of technical debt management, this now well-understood confusion about the domain of applicability of Hardin’s allegory.

We can apply Ostrom’s result to the problem of managing technical debt if we identify the technical asset as the shared resource, and identify as the community exploiting the resource the stakeholders who employ, develop, maintain, cyber-defend, or extend that technical asset. Ostrom’s results tell us that sustainable exploitation is possible only if the community devises rules, customs, and sanctions that manage the technical debt. Kim and Wood [Kim 2011] provide an analysis that explains how regulation can avert depletion scenarios. Technology managers can apply these lessons to the problem of managing technical debt.

The Tragedy of the Commons is a distraction because technical debt isn’t an inevitable result of sharing assets when the organization adheres to a Principle of Sustainability. That principle is that sustainability is possible only if the community sharing the asset devises customs, rules, and sanctions that effectively control the level of technical debt. You just can’t have a free-for-all unregulated regime, as most organizations now do. Management and practitioners must collaborate to devise the customs, rules, and sanctions for managing the asset. And regular updating is probably necessary. Leadership in devising those customs, rules, and sanctions is a job for the policymaker.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.

Available: here; Retrieved: June 4, 2018

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

Other posts in this thread

Posted on

Organizational psychopathy: career advancement by surfing the debt tsunami

Last updated on July 24th, 2018 at 08:23 pm

During policy debates, some decision-makers and some advocates take positions that offer short-term advantages to the enterprise at the expense of incurring heavy burdens of new technical debt or allowing legacy technical debt to remain in place. Some of these decisions can be strategic, and they can benefit the enterprise. But organizational psychopathy can be the dominant contributing factor when the primary beneficiary of the strategy is the decision-maker or the advocate, and when he or she intends knowingly to move on to a new position or to employment elsewhere before the true cost of the technical debt becomes evident.

The aftermath of the 2004 Indian Ocean earthquake, 26 December 2004
The aftermath of the 2004 Indian Ocean earthquake and tsunami, 26 December 2004. Shown is what remained of Meulaboh, Sumatra, Indonesia, after it was hit by the tsunami. The photo was taken on January 10. At the lower left is a Landing Craft Air Cushion (LCAC) hovercraft vehicle, assigned to USS Bonhomme Richard, delivering supplies. LCACs are capable of transporting more supplies than helicopters in a single trip. The technical debt devastation left behind after an organizational psychopath moves on to further conquests can be just as overwhelming as the physical devastation left behind after a tsunami. Photo by U.S. Navy courtesy Wikimedia Commons.
Such decisions can be counterproductive for the enterprise in the long term. But the decision-maker or advocate nevertheless favors the decision, because he or she plans to take credit for the short-term benefits, and then move on to a new career position elsewhere to escape the technical debt problems created by the decision. In effect, the decision-maker or advocate plans to “surf the debt tsunami.”

People who adopt strategies of this kind might be following the pattern of organizational psychopathy [Babiak 2007] [Morse 2004]. Organizational psychopaths compulsively seek power and control over others. They use a vast array of tactics, but the tactic of greatest relevance to this discussion is the use of enterprise resources to advance the psychopath’s career. Technical debt provides a mechanism for borrowing future resources to enhance present performance, thus advancing the career of the psychopath. It’s especially attractive to the psychopath because the harmful consequences of technical debt can remain hidden until the psychopath has long ago moved on.

Psychopaths are better equipped than most to execute such strategies, because they can be exceedingly charming, intelligent, and charismatic. Because they are adept at deception, they are willing to conceal the truth about the technical debt they create, misrepresenting its costs and consequences, or concealing it altogether. Most important, organizational psychopaths seem to lack the internal regulators of conscience and compunction that limit the actions of non-psychopaths. For example, in a debate about a specific technical decision, the psychopath is willing to use any tools available to win the point, including using deception to destroy the career of anyone who challenges the psychopath’s position.

Babiak and Hare estimate that the incidence of psychopathy in senior positions in business is about 3-4% — between 1/30 and 1/25. However, I’m unaware of any studies of the strategic use of technical debt by these individuals. It’s reasonable to suppose that technical debt has been so employed, but the significance of this phenomenon is unknown. Serious investigation is in order.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

An accessible and authoritative overview of organizational psychopathy. Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.

Available: here; Retrieved: June 4, 2018

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

Other posts in this thread

Posted on

Unrealistic definition of done

Last updated on February 1st, 2018 at 07:27 am

Many an enterprise culture includes, perhaps tacitly, an unrealistic definition of done. When an enterprise culture assumes a definition of done for projects that excludes — or fails to adequately acknowledge — attributes related to sustainability of deliverables, technical debt expands inexorably. In most organizations, the definition of done for projects includes meeting the attributes that most internal customers understand and care about. These attributes might not include sustainability [Guo 2011]. Indeed, even among technologists, the definition of done might not enjoy precise consensus [Wake 2002].

The 2009 Ford Focus SES coupe (North America) engine bay
The 2009 Ford Focus SES coupe (North America) engine bay. Gone are the days when typical owners could learn how to maintain their own vehicles. Engines have become so complex that even experienced mechanics must be trained to maintain engines with which they’re unfamiliar. Since these vehicles are being offered for sale to consumers, clearly their manufacturers regard their designs as “done.” But is technical debt a factor in the growing complexity of modern motor vehicle engines? It’s probably present in their software, and it would be most surprising if we found no technical debt in the mechanical design. Photo (cc) Porsche997SBS courtesy Wikimedia.

Because attributes related to sustainability of deliverables are less well understood by internal customers — indeed, by nearly everyone — it is perhaps unsurprising that sustainability might not receive the attention it needs. Applying scarce resources to enhance attributes the customer doesn’t understand, and cares about less, will always be difficult.

To gain control of technical debt, we must redefine done to include addressing sustainability of deliverables. Although there may be many ways to accomplish this, none will be easy. Resolution will involve, inevitably, educating internal customers so that they understand enough about sustainability to enable them to justify paying for it.

The typical definition of done for most projects ensures only that the deliverables meet the requirements. Because requirements usually omit reference to retiring newly incurred non-strategic technical debt, projects are often declared complete with incremental technical debt still in place. A similar problem prevails with respect to legacy technical debt.

A more insidious form of this problem is intentional shifting of the definition of done. This happens when the organization has adopted a reasonable definition of done that allows for addressing sustainability, but under severe time pressure, the definition is “temporarily” amended to allow the team to declare the effort complete, even though sustainability issues remain unaddressed.

For most projects, three conditions conspire to create steadily increasing levels of non-strategic technical debt. First, for most tasks, the definition of done is that the deliverables meet the project objectives, or at least, they meet them well enough. Second, typical project objectives don’t restrict levels of newly incurred non-strategic technical debt, nor do they demand retirement of incidentally discovered legacy technical debt. Third, budget authority usually terminates upon acceptance of delivery. These three conditions, taken together, restrain engineering teams from immediately retiring any debt they incur and from retiring — or documenting or reporting — any legacy technical debt they encounter while fulfilling other requirements.

For example, for one kind of incremental technical debt — what Fowler calls [Fowler 2009] Inadvertent/Prudent (“Now we know how we should have done it”) — the realization that debt has been incurred often occurs after the task is “done.” If budget authority has terminated, there are no resources available — financial or human — to retire that form of technical debt.

Unless team members document the technical debt they create or encounter, after they move on to their next assignments, the enterprise is likely to lose track of the location and nature of that debt. A more realistic definition of done would enable the team to continue working post-delivery to retire, or at least document, any newly incurred non-strategic technical debt or incidentally encountered legacy technical debt. Moreover, strategic technical debt — technical debt incurred intentionally for strategic reasons — is also often left in place. Although it, too, must be addressed eventually, the widespread definition of done doesn’t address it.

Policymakers are well positioned to advocate for the culture transformation needed to redefine done.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

An accessible and authoritative overview of organizational psychopathy. Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.

Available: here; Retrieved: June 4, 2018

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

Other posts in this thread

Posted on

Team composition volatility

Last updated on February 1st, 2018 at 07:31 am

Team composition volatility can interfere with technical debt retirement. In many organizations, project team composition is rarely fixed from beginning to end. In most teams, people who have special knowledge cycle in and out as the work requires. Although these changes in team composition might not interfere with completing a team’s primary objectives, they can affect the team’s ability to retire technical debt that the team incurs over the life of the project. Changes in team composition can also limit the team’s ability to retire specified legacy technical debt that it encounters while working toward its primary objectives.

Now we know what we should have done.
“Now we know what we should have done.” This is one kind of incremental technical debt. When the composition of a development team changes over the course of project, recognizing how things should have been done can become more difficult.

Changes in team composition can increase the likelihood of incurring non-strategic incremental technical debt, and increase the likelihood of failing to retire all legacy debt specified in the team’s objectives.

Most product development, maintenance, and enhancement is carried out in groups we call teams. In this context, team is usually defined as, “a small group of interdependent individuals who share responsibility for outcomes.” [Hollenbeck 2012] However, as Hollenbeck et al. observe, teams vary widely in both skill differentiation and composition stability. My sense is that both factors can potentially influence a team’s ability to retire incremental technical debt. They also affect its ability to achieve its objectives with respect to retiring legacy technical debt.

For example, consider what Fowler calls the Inadvertent/Prudent class of technical debt — “Now we know how we should have done it.” [Fowler 2009] In a project of significant size, some might recognize that different approaches to all or parts of it would have been more effective than the ones that were chosen. The recognition might come several months, or even years, after the work affected was conceived or even completed.

But for the moment, consider only cases in which the recognition occurs during the project, or shortly after completion. In these cases, the people who performed that work might have moved on to other teams in need of their talents and abilities. The people who now realize “how we should have done it” might not be themselves capable of making the needed changes, even if they have the budget or time to do the work. Or worse, they might not have the knowledge needed to recognize that a different approach would have been more effective. In either case, recognized or not, the work performed by the people no longer on the team comprises incremental technical debt. Because of team composition volatility, recognizing or retiring that incremental technical debt can be difficult.

Team composition volatility can also interfere with retiring legacy technical debt. Some projects are specifically charged with retiring a class or classes of legacy technical debt. But others with different objectives might also be charged with retiring instances of specific kinds of legacy technical debt as they encounter them. When team members with special knowledge required for the team’s primary objectives are reassigned, some legacy technical debt can remain un-retired, if retiring that debt from the context in which it occurs requires their special knowledge, and if the reassignment occurs before they can complete the legacy debt retirement. This mechanism is more likely to occur when the legacy debt retirement objective is viewed as subordinate to other business objectives.

Keeping team membership stable has big advantages relative the technical debt management. Said differently, organizations that must shuffle people from team to team as a consequence of controlling costs by reducing headcount can pay big penalties in terms of increasing loads of technical debt.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

An accessible and authoritative overview of organizational psychopathy. Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

Cited in:

[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.

Available: here; Retrieved: June 4, 2018

Cited in:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

Cited in:

[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

Other posts in this thread

Show Buttons
Hide Buttons