26.19M lines of code 831 analyzed projects 13,233 days of Technical Debt
  • Interview of Ward Cunningham, about technical debt

     Talking about technical debt without interviewing the father of the concept would be a bit pretentious. Ward Cunningham has kindly agreed to answer questions from TechDebt’s readers about the debt metaphor: What is debt, what’s not? Is it relevant trying to measure it? Must agile teams fight it at all costs?

    Gartner estimates the worldwide technical debt to something about $500 billions. What’s your opinion on how to measure technical debt in a way that everybody can understand? Have you heard about the SQALE method?

    I have read the SQALE paper. Although I am pleased that more attention is given to code quality and the processes by which it can be improved, I fear that there is a deep misunderstanding of programming as a human activity. Specifically, we must ask, what does it mean to READ a program and what does it mean to BORROW in this context.

    I fear that SQALE has fallen into the fallacy of the Conduit Metaphor. See http://en.wikipedia.org/wiki/Conduit_metaphor which includes a reference to Reddy’s landmark paper on the source of this confusion. The fallacy is to think that the value of an idea is in the text (the conduit) when the value of an idea is actually distributed between the text and the people who can read it.

    When a TEAM works toward GOALS by constructing a body of CODE, we can assess their productivity as the ratio of the TEAM’s attention to GOALS vs. CODE. We can say that the CODE is of high quality when productivity remains high in the presence of change in TEAM and GOALS.

     

    In your opinion, could a benchmark analysis of technical debt be useful to better manage your Technical Debt? For example, PHP Open Source projects have an average comment rate of 23%. So, if I code for a PHP project, i would try to be above this average metric.

    Most textual artifacts are at least tangential to the GOALS mentioned above. For example, when the TEAM recognizes the need for comments and provide them, are they increasing or decreasing the technical debt? Keep in mind that future readers will be required to read both the code and the comments and make some judgement as to the comments’ veracity. Perhaps the TEAM is BORROWING from future readers when they choose to document a confusion rather than removing it.

     

    Is lack of skill on a technology should be considered as a technical debt? For example, a junior COBOL developer would generate certainly more debt into code because he doesn’t know all COBOL best practices, compared to experienced programmers.

    Alan Kay took the opposite position when he chose to study children using computers. His belief was that the current crop of experienced programmers were hopelessly accommodated to limitations in software systems that were no longer present. Let me give one example, a pet peeve of mine:

    A best practice from the days of punch cards was to define a series of variables to be held constant through a run. These definitions were placed in the front of the deck where they would be easily found when siting at a card punch station editing the deck by hand. This once best practice has turned into a systemic disfunction that I will attempt to explain:

    Specifically, today’s interactive computers will direct the programmer’s attention to the very statement where a program fails. However, the conditions of the failure, and the means of correction, often lead through numerous definitions distributed across numerous configuration files which were all conceived of as helping the downstream programmer. Instead this indirection become a modern programming puzzle that wastes the GOAL focused programmer’s attention every day.

     

    In your opinion, why Agile is a good way to manage/reduce technical debts of software projects? If developers have extra time, should they try to reduce technical debt by creating & running a dedicated sprint, instead of adding another user story to the delivery? Actually, what’s the best time to kill technical debt?

    Remember, when rapid delivery of a product is important, as it often is in the marketplace, considered accumulation of DEBT is a good thing. In a healthy agile project, where the TEAM is fully aware of the business case for accumulation, and the TEAM has made provisions for paying back DEBT with some efficiency, then the repayment can proceed as just one more activity of software development.

    ON-SITE CUSTOMER and PAIR-PROGRAMMING are the practices that lead to awareness. TDD, REFACTORING and CLEAN-CODE enable efficient repayment.

     

    Can a technical debt be “shared” by several applications? For example, how to measure the technical debt of a web service which can be used from different applications into an IT system? Should we count once or aggregate?

    DEBT is a strategy that an organization takes in meeting its obligations to others. It would be prudent, before building on a web service, to understand the providing organization’s strategy toward all manor of DEBT.

    For example, a service provider that claims 99.999% reliability (five nines) but that will withdraw service on failure to pay credit card bills (another service with nowhere near five nines of reliability) is clearly misrepresenting the reliability you will observe in their service.

    I would say that DEBT is localized within a TEAM, its GOALS and the CODE offered by a TEAM to meet those GOALS. However, any mechanism that attempts to measure TEAM commitments, GOALS alignment and CODE quality across organizational boundaries would be valuable in our increasingly dependent world.

     

    More information about Ward’s work at http://c2.com

     

    Posted by
    Michael MULLER (See other posts)

    +10 years experienced Marketing & Communication Manager, specialized in Technology & Innovating companies. Marketing Manager at Tocea. Executive editor at http://dsisionnel.com, a french IT magazine. Creator of http://d8p.it, a cool url shortener. Dad of 2 kids.


Leave a Reply