Approaches to TD identification Community perception of “TD is important”
Quote Cunningham is ok but is this our preconceived definition or just motivation? (McConnell)
Maybe start with show of hands/ questions
Motivation for Arch unclear. Cunningham focused on code, but since then it has broadened (landscape picture). Part of approach is “what’s in/what’s out” Not so defensive. We *think* it might be architecture to motivate second question.
We asked them about defns and examples before likert to hear their opinions
Triangualted e.g arch questions
#6 - s/w involved, but not software only
Make point about not homogenous group (even though only 3 orgs) – lots of different projects
Average versus clusters of responses
Point about long lag time is good. Add to RQ2 discussion.
11 Ward’s problem is you need a lot of discipline to return and repay
Define “coding. (And process) What this means is that when people give an example, it tended to involve architecture
#11 as Ward notes, the idea is really that you cannot know upfront, so you MUST fix it later - and soon Protoytpe becomes product
1 – debt incurred (decision made) 2 – recognized 3 – ideal pay back time (should do it here) 4 – actual repayment based on pain 5 – decision to strategically manage debt
(instead of forgetting, lack of arch docs and rationale).
Must cut 6 minutes or so. Faster at beginning. Less digressions.
Two of us rated each one after we came to agreement.
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt