SPA Conference session: Code debt | |||
| One-line description: | How code gets bad, and what we can do about it | ||
| Session format: | Workshop (150 mins) [read about the different session types] | ||
| Abstract: | We’re all used to dealing with code that – all too obviously – has a history. Tangled code, of the sort that many of us have to deal with every day, didn’t get that way by itself: it’s a result of a sequence of design decisions made on the basis of mixed, conflicting and sometimes unclear information, assumptions and abilities. How do we convey to our teams why design matters? It’s not about the code working or being efficient or reliable, it is about the load that bad design puts on a project. This session introduces techniques for surfacing the issues caused by bad code and for improving the team’s ability to minimize and mange code debt. We aim to help participants move themselves and their teams to a higher level of design ability. | ||
| Audience background: | Software developers, designers, architects | ||
| Benefits of participating: | * Understand the cost of code debt * Identify the causes * Learn how to minimize and repay debt * Reflect on design decisions | ||
| Materials provided: | Links and example code for examination and discussion | ||
| Process: | The cost of debt Through a simple quick exercise we will demonstrate the impact of code debt on development. Recognizing debt Pairs will review published code from an open source project or other online source, and identify instances of code debt: areas in the code where intent is unclear, where structure is confusing, where assumptions seem to be made but are in conflict. Forensic accounting Participants will investigate the origin and causes of code debt by exploring the history of a simple codebase. Balancing the books There are two aspects to keeping debt under control: controlling expenditure (making good design decisions in the first place) and repayment (improving existing design through refactoring). We will outline some core design principals and suggest a way of introducing refactoring. Auditing We will introduce a process for reflecting on design decisions and evaluating possible alternatives. This is a long running process, but we will do a small piece of it a little hypothetically. | ||
| Detailed timetable: | 00:00 - 00:05 Introduction and goals 00:05 - 00:15 Exercise: The cost of debt 00:15 - 00:55 Practical 1: Recognizing Debt 00:55 - 01:15 Practical 2: Forensic Accounting 01:15 - 01:35 Practical 2: Forensic Accounting (continued) 01:35 - 01:55 Balancing the Books 01:55 - 02:25 Group activity: Auditing 02:25 - 02:30 Wrap | ||
| Outputs: | Summary of issues and causes on the wiki | ||
| History: | The session has grown out of workshops run by Peter and others with clients, and out of work on a design education program David has under way at Sibelius. | ||
| Presenters | |||
| 1. Peter Marks Digita |
2. David Harvey Sibelius Software |
3. | |