Reducing Technical Debt

  • 2,708 views
Uploaded on

Technical debt is a metaphor for the gap between the current state of …

Technical debt is a metaphor for the gap between the current state of
a software system and its hypothesized ‘ideal’ state. One of the significant and
under-investigated elements of technical debt is documentation debt, which
may occur when code is created without supporting internal documentation,
such as code comments. Studies have shown that outdated or lacking
documentation is a considerable contributor to increased costs of software
systems maintenance. The importance of comments is often overlooked by
software developers, resulting in a notably slower growth rate of comments
compared to the growth rate of code in software projects. This research aims to
explore and better understand developers’ reluctance to document code, and
accordingly to propose efficient ways of using persuasive technology to
encourage programmers to document their code. The results may assist software
practitioners and project managers to control and reduce documentation debt.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Thanks for your comment, Chris! I agree with you that source code should be written in such a way to support maintainability with as few comments as possible. However, in practice real software systems are not well written and the existence of comments increases considerably the ease of maintenance tasks. This was shown in several previous researches which are referenced in our paper here: http://www.slideshare.net/makabee/reducing-technical-debt-proof
    Are you sure you want to
    Your message goes here
  • Allow me to offer this challenge: show us an example of documentation that is *more useful* to a code maintainer than the code itself?

    As examples of well documented software I think of the Java Api and the .Net framework. This documentation is excellent for a consumer-developer using the API. But as soon as one tries to modify the code - for instance, contributing to the mono project or the OpenJdk - it isn't anything like detailed enough. One ends up reading the code. I do not believe, unless you can show me counter-examples, that it is possible to write documentation that is both sufficiently detailed for a code-modifier, whilst being less flawed or more readable, than the code itself.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
2,708
On Slideshare
0
From Embeds
0
Number of Embeds
14

Actions

Shares
Downloads
2
Comments
2
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Software Architecture Lab. Reducing Technical Debt: Using Persuasive Technology for Encouraging Software Developers to Document Code Y U L I A S H M E R L I N , I N F O R M A T I O N S Y S T E M S D E P A R T M E N T , U N I V E R S I T Y O F H A I F A , I S R A E L D O R O N K L I G E R , E C O N O M I C S D E P A R T M E N T , U N I V E R S I T Y O F H A I F A , I S R A E L H A Y I M M A K A B E E , Y A H O O ! R E S E A R C H L A B S , H A I F A , I S R A E L
  • 2. Software Architecture Lab. 2 Documentation Debt  Technical debt is a metaphor for the gap between the current state of a software system and its hypothesized ‘ideal’ state.  Documentation debt may occur when code is created without sufficient supporting internal documentation, such as code comments.  The growth rate of comments is smaller than the growth rate of code in software projects.
  • 3. Software Architecture Lab. 3 Causes of Documentation Debt  The importance of comments is often overlooked by software developers.  Some developers perceive writing internal documentation as a secondary task, as opposed to writing the code itself.  Some development approaches promote the idea that good code should be self-explanatory, and thus comments are not always necessary.
  • 4. Software Architecture Lab. 4 Documentation Debt Consequences  Outdated or lacking documentation increases the costs of software systems maintenance.  Previous research shows that 40%- 60% of the maintenance time is spent on studying the software prior to modification because of the lack of appropriate documentation.
  • 5. Software Architecture Lab. 5 Research Goals  Explore and better understand developers’ reluctance to document code.  Propose efficient ways using persuasive technology to encourage programmers to document their code.
  • 6. Software Architecture Lab. 6 Persuasive Technology  Persuasive technology is an interactive computer technology designed with the goal of reinforcing, changing or shaping people’s attitudes or behavior.  Shaping purposes: create a behavior pattern for a specific situation which did not exist prior to using the system.
  • 7. Software Architecture Lab. 7 Fogg Behavior Model  Fogg Behavior Model has three factors:  Motivation  Ability  Triggers  Behavior activation threshold: For the trigger to evoke the desired behavior, a person has to be above that threshold, in high enough level of motivation and ability.
  • 8. Software Architecture Lab. 8 Research Plan We plan two studies: 1. A think-aloud protocol for examining program maintenance tasks performance. 2. A series of experiments to assess triggers for documentation.
  • 9. Software Architecture Lab. 9 Think-Aloud Sessions  Each subject will perform a maintenance task, namely, add functionality, on a code written and documented by another person.  We will observe:  To what extent the subject relies on the code documentation during this process.  What are the important features in code comments that help understand existing code.
  • 10. Software Architecture Lab. 10 Assess Triggers for Documentation  Goal: Check if the use of a documentation- triggering tool improves documentation.  While exploring also the effect of interventions on the other Fogg factors (motivation and ability).  Quantitative results: will be calculated using documentation metrics.  Qualitative results: we plan to collect qualitative data via questionnaires.
  • 11. Software Architecture Lab. 11 Planned Experiments  Pilot experiments with undergraduate students.  Experiment with software practitioners:  During a full-day workshop.  1st stage: participants implement coding task.  2nd stage: participants extend code written by others.  Participants are divided into two groups:  Both groups are aware that their code will be extended by someone else.  One group expects that the quality of their documentation will be judged.
  • 12. Software Architecture Lab. 12 Conclusions  We intend to:  Identify the factors affecting documentation.  Devise means for increasing compliance with documentation requirements.  Create a utility, using persuasive technology principles, for encouraging and motivating developers to document their code.  Our results may assist software practitioners to control and reduce documentation debt.