Dealing with Technical Debt LUG 2016 Developer Day Ben Evans.

Slides:



Advertisements
Similar presentations
P5, M1, D1.
Advertisements

Sustainable Grading Ralph Westfall, Ph.D. April 2010
SYSTEM ANALYSIS & DESIGN (DCT 2013)
Debugging Introduction to Computing Science and Programming I.
Objects First With Java A Practical Introduction Using BlueJ Designing object-oriented programs How to write code in a way that is easily understandable,
“Chapter 9” Managing Object Design Done By: Alia Waled.
16-Jun-15 javadoc. 2 Javadoc placement javadoc comments begin with /** and end with */ In a javadoc comment, a * at the beginning of the line is not part.
March 30, Exploratory Testing Testing Approaches Analytical Information-driven Intuitive Exploratory Design the tests and test concurrently Learn.
Maintainability Sp.772 April 29th Important Criteria Easy to understand –New web masters –Old web masters –The user Easy to update –Bug fixes –New.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
CODING Research Data Management. Research Data Management Coding When writing software or analytical code it is important that others and your future.
Software maintenance Managing the processes of system change.
Software Reengineering 2003 년 12 월 2 일 최창익, 고광 원.
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
The Paperless Classroom with Google Docs Eric Curts - North Canton City Schools ericcurts.com - - gplus.to/ericcurts.
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
Presented by: Ben Palermo Nathan O’Grady.  How to Program by Coincidence  Accidents of Implementation ◦ It may just look like its working ◦ The boundary.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
1 Documenting Your Project. 2 Documenting your Project Insert Banner Comments in your code Comment - coding statement used by humans not the compiler.
1 CSC 221: Introduction to Programming Fall 2012 Functions & Modules  standard modules: math, random  Python documentation, help  user-defined functions,
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
Refactoring Improving the structure of existing code Refactoring1.
Proofreading & Editing. The Importance of Proofreading Before submitting or printing an academic research paper, essay, , memo, or any other written.
Refactoring1 Improving the structure of existing code.
Self-Documenting Code Chapter 32. Kinds of Comments  Repeat of code  Explanation of code  Marker in code  Summary of code  Description of code’s.
Automated Patch Generation Adapted from Tevfik Bultan’s Lecture.
Jodi’s Student Led Conference Science ~ What have I learned about this year? This year, I have learned about a lot of things, but some of the bigger.
Advanced S/w Eng - s/w productivity issues 1 Software Productivity Issues Why do software projects fail? Advanced Software Engineering COM360 University.
Mark Dixon 1 Tech – Final Report. Mark Dixon 2 Aims & Objectives Give guidance on: –Project Report –Demonstration.
Refactoring1 Improving the structure of existing code.
Platform & Engineering Services CERN IT Department CH-1211 Geneva 23 Switzerland t PES Development Workflow of the Configuration Management.
Refactoring: Improving the Design of Existing Code.
Software Maintenance1 Software Maintenance.
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
Wildfire Costing (WFCST) for Recorders A component of Wildfire One Fire Season 2016.
© Trustees of Indiana University Released under Creative Commons 3.0 unported license; license terms on last slide. Take Group Projects to the Next Level.
1 April 14, Starting New Open Source Software Projects William Cohen NCSU CSC 591W April 14, 2008.
Implementation Topics Describe –Characteristics of good implementations –Best practices to achieve them Understand role of comments Learn debugging techniques.
BSA 411 Week 4 Individual Assignment Process Analysis and System Concept Development Process Analysis and System Concept Development Submit a 3- to 4-page.
“When quality is critical"
Effective Time Management
IF-less programming in C#
BIS 221 Course Experience Tradition / snaptutorial.com
OpenSAF Developer Days 2008 OpenSAF Release Management Session 15-07
1. Welcome to Software Construction
Debugging Hardware/Software on Linux
Lessons from 15 years of NBD
While Loops BIS1523 – Lecture 12.
Refactoring and Code Smells
Problem Solving Techniques
Objects First with Java
Software Testing and Maintenance Modifying Code
Budgeting 101 Many Americans do not know how to manage their money to keep themselves out of debt, let alone to save money. Budgeting can help!
Software Testing and Maintenance Maintenance and Evolution Overview
MIS 3200 – Unit 5.2 ListItem controls and accumulation
Improving the structure of existing code
Refactoring and Code Smells
Debugging at Scale.
Turning in Assignments
Automated Patch Generation
Refactoring and Code Smells
Ian VanBuren Refactoring.
Redundant code repositories
Variables, Constants, Assign.
Lab 07 Creating Documents with Efficiency and Consistency
Chapter 9: Implementation
Refactoring and Code Smells
Introduction To Software Development Environment
Functions and Abstraction
Presentation transcript:

Dealing with Technical Debt LUG 2016 Developer Day Ben Evans

Defining Technical Debt ●Work that needs to be done to keep a codebase up to date ● Removal of old code ● Refactoring of existing code ● Commenting and documenting code ● Migrating to new standards (tabathon) ● Naming things ● Better grouping of related items ● etc.

Types of Debt ●Lack of design ●Lack of comments ●Lack of standards ●Old, unused code ● Search for “#if 0” ● Run git blame ●Build up of changes

Coding Guidelines ● ● “Do what it says on the tin” ● Naming: ● Keep them distinct: rq_reqmsg and rq_repmsg ● Use descriptive names: make_the_code_clearer, but do_not_let_things_get_out_of_hand ● Commenting ● Describe what a function does, input and outputs

Mantra: Code deleted is code debugged ●Taking 3 months to understand 3k lines ● Time well spent? ●Replacing it with and if statement and ‘memcpy’ ● Priceless ●Don’t get creative ● It’s always harder to debug than write

Random Example! #define md_op_data_fid(op_data, fl) \ (fl == MF_MDC_CANCEL_FID1 ? &op_data->op_fid1 : \ fl == MF_MDC_CANCEL_FID2 ? &op_data->op_fid2 : \ fl == MF_MDC_CANCEL_FID3 ? &op_data->op_fid3 : \ fl == MF_MDC_CANCEL_FID4 ? &op_data->op_fid4 : \ NULL) ●Yep, that‘s a case statement

Dealing with Debt ●Learn what the standards are ● Adapt your code, and the code around them to it ●Make small changes ● It might take awhile, but it works

Benefits ●Readable, Maintainable code ●Easier to add features ●Easier to get new developers involved ●Consistency ●Reducing bugs

Bigger Questions ●When do we retire code? ● 1.x based code that is no longer needed ●When to reorganize code? ● Moving “testing (DANGEROUS)” out of lctl ●When to redesign code? ● ptlrpc ●When to change the UI/UX? ● Changelogs, changelog management ●Should there be an OpenSFS effort for this?

More Questions ●Tabathon is working ● It’s slow ●Comment-athon? ●Design Doc-athon?

Things we can do ●Create a Jira label for tech debt ● Hunt through all the code for TODO: labels and replace them with jira tickets? ●Put design docs into /documentation ● Even if they’re old, they’re better than nothing ●Spend a little time making the code a better place ● Open a Jira ticket ● Assign it to yourself ● Submit a patch ●Code reviews