Technical Debt and Requirements
•
1 recomendación•1,246 vistas
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Technical Debt and Requirements
Similar a Technical Debt and Requirements (20)
Más de Neil Ernst
Más de Neil Ernst (11)
Último
Último (20)
Technical Debt and Requirements
- 1. Technical Debt and Requirements Neil Ernst University of British Columbia @neilernst • neil@neilernst.net • neilernst.net
- 2. Overview • Requirements represent product’s business value and quality goals. • “Technical debt is acquired when engineers take shortcuts that fall short of best practices.” -- Eric Allman, CACM 55(5) Short-cuts in requirements phase(s) a source of Technical Debt.
- 3. 2008 Firefox
- 6. Characteristics • Benefit = Time saved not doing requirements work.
- 7. Characteristics • Benefit = Time saved not doing requirements work. • Risk = Possibility that we miss intent, leading to “rework”.
- 8. Characteristics • Benefit = Time saved not doing requirements work. • Risk = Possibility that we miss intent, leading to “rework”. • Interest = Misunderstood req in V1 might lead to further misses in V2, if requirements build on top of one another.
- 9. Characteristics • Benefit = Time saved not doing requirements work. • Risk = Possibility that we miss intent, leading to “rework”. • Interest = Misunderstood req in V1 might lead to further misses in V2, if requirements build on top of one another. • Repayment = Reprioritize, re-analyse, process improvements.
- 10. Requirements Debt Design Debt Code Debt
- 11. Should have compiled ALL Requirements Debt Javascript to begin with Design Debt Code Debt
- 12. Should have compiled ALL Requirements Debt Javascript to begin with Rearchitect to support base Design Debt compilation Code Debt
- 13. Should have compiled ALL Requirements Debt Javascript to begin with Rearchitect to support base Design Debt compilation Code Debt Implement new code; test; deliver
- 14. Should have compiled ALL Requirements Debt Javascript to begin with Rearchitect to support base Design Debt compilation Code Debt Interest Implement new code; test; deliver
- 15. TD in Requirements • Technical debt incurred when we do not conduct “sufficient” requirements analysis: • we gamble that more elicitation or analysis will not help, • because that issue may not even be relevant! • If it is relevant, than we go back and fix it. • Key business decision: what is sufficient? • Can tools help.
- 16. Other Examples • “TBDs and maintenance” (MTD 10) • Risk analysis and mitigation (JPL) • Evolving user stories (SAP)
- 17. Optimizing decisions • At start of iteration question is “what is the best trajectory to pick”? • What is best set of ‘work items’ to prioritize? • RE-KOMBINE automatically calculates the optimal strategy for satisfying the given set of requirements. • Relations between requirements matter.
- 18. Surfacing requirements debt • Mine repositories for requirements data • Track usage data
- 20. Command Executions edit.Delete 5.4 M file.Save 4.3 M edit.Paste 3.8 M edit.Copy 2.4 M ContentAssist.proposals 1.4 M
- 21. Command Executions edit.Delete 5.4 M file.Save 4.3 M edit.Paste 3.8 M edit.Copy 2.4 M ContentAssist.proposals 1.4 M Command Executions window.previousView 9 navigate.Back 69 window.showViewMenu 89 window.previousPerspective 155 window.previousEditor 166 Data: Eclipse UPP, 200908, eclipse.ui, 3.5.0
- 22. Summary • Debt is incurred when we do not do sufficient requirements work. • Requirements capture value, and should be first-class citizens in software development. • Support dev in understanding how software is meeting business and quality goals. • Tracking historical tendency, we can improve our understanding of the problem space(s).
- 23. Research Directions 1. What is the relationship between process debt and requirements debt? 2. Analysis-paralysis vs. wearing blinders 3. Transitioning from ‘agile’ requirements to up-front design. 4. How do we track requirements debt? Neil Ernst: @neilernst • neilernst.net
Notas del editor
- 3 points\noutline\n\n
- And let’s be clear, planning happens in even the smallest project - but perhaps different artifacts or process.\nIn this talk I am going to introduce what I think is the analogue of a ‘code smell’ in requirements. I’ll begin with a working example, and then introduce how and where the TD metaphor fits with requirements. I’ll talk briefly about some work I have done on reducing TD in req., and some of the work we are currently looking at in terms of software planning and development. I’ll end with a few discussion questions for the group. \n\nI am going to briefly discuss what TD in Req is; then introduce an example that shows how this plays out in Firefox. I will then talk about how we might use tools to help us manage this type of debt. And I’ll finish with some future work and research questions. \n\n
- \n
- \n
- \n
- Context: Javascript in the browser. \nAug 2008 - TraceMonkey from Tamarin project of Adobe. Legacy code base. but good on performance. \nDesign choice: use tracing rather than total compilation. Only compile difficult pieces (http://hacks.mozilla.org/2010/03/improving-javascript-performance-with-jagermonkey/)\nProblem: truns out for a lot of pages that you have to switch back and forth a lot. So go back and add in a baseline JIT + tracing ability (JM).\ngoal of being clean and flexible and fast\n 578133 - (JaegerSpeed) [meta] JM: Make us fast!\n “as people finish these bugs, please post SunSpider comparisons, so we can check the expected win against the actual win, and make sure that we're on track to get where we need to be\n“This is a tracking bug for things that improve our perf, but only a tiny bit. Things linked directly from here should be considered low priority, unless someone discovers an easy way of doing them, or we find out they are more important than first believed.”- see AreWeFastYet.com\nNew problems: lots of code debt from multiple developers, Adobe contribution, etc. Hard to manoeuvre (this shows that the requirements and design debt are influencing the code debt and vice versa).\nThe narrative: FF working on new JIT compiler. One of the main goals is speed. But what features will help with speed requirement? Not sure yet. E.g. bug 582152: Sync earlier to avoid load stalls on doubles was originally in the tiny-perf bug 578225 but then linked into the main speed bug 578133 as it was realized how much it helped. \nTech debt in RE would suggest that focusing on small improvements over large ones would be a debt.\nSmall wins:\n23 bugs of which 5 are not fixed (22%)\nBig wins: \n67 bugs tracked of which 10 are not fixed (15%)\nThis seems like a sensible approach - most effort is focused on big wins. And no way to tell ahead of time? \nCould argue FF couldn’t knpw tracing wasn’t good in 2008. But 2 other teams did.\n
- Context: Javascript in the browser. \nAug 2008 - TraceMonkey from Tamarin project of Adobe. Legacy code base. but good on performance. \nDesign choice: use tracing rather than total compilation. Only compile difficult pieces (http://hacks.mozilla.org/2010/03/improving-javascript-performance-with-jagermonkey/)\nProblem: truns out for a lot of pages that you have to switch back and forth a lot. So go back and add in a baseline JIT + tracing ability (JM).\ngoal of being clean and flexible and fast\n 578133 - (JaegerSpeed) [meta] JM: Make us fast!\n “as people finish these bugs, please post SunSpider comparisons, so we can check the expected win against the actual win, and make sure that we're on track to get where we need to be\n“This is a tracking bug for things that improve our perf, but only a tiny bit. Things linked directly from here should be considered low priority, unless someone discovers an easy way of doing them, or we find out they are more important than first believed.”- see AreWeFastYet.com\nNew problems: lots of code debt from multiple developers, Adobe contribution, etc. Hard to manoeuvre (this shows that the requirements and design debt are influencing the code debt and vice versa).\nThe narrative: FF working on new JIT compiler. One of the main goals is speed. But what features will help with speed requirement? Not sure yet. E.g. bug 582152: Sync earlier to avoid load stalls on doubles was originally in the tiny-perf bug 578225 but then linked into the main speed bug 578133 as it was realized how much it helped. \nTech debt in RE would suggest that focusing on small improvements over large ones would be a debt.\nSmall wins:\n23 bugs of which 5 are not fixed (22%)\nBig wins: \n67 bugs tracked of which 10 are not fixed (15%)\nThis seems like a sensible approach - most effort is focused on big wins. And no way to tell ahead of time? \nCould argue FF couldn’t knpw tracing wasn’t good in 2008. But 2 other teams did.\n
- Context: Javascript in the browser. \nAug 2008 - TraceMonkey from Tamarin project of Adobe. Legacy code base. but good on performance. \nDesign choice: use tracing rather than total compilation. Only compile difficult pieces (http://hacks.mozilla.org/2010/03/improving-javascript-performance-with-jagermonkey/)\nProblem: truns out for a lot of pages that you have to switch back and forth a lot. So go back and add in a baseline JIT + tracing ability (JM).\ngoal of being clean and flexible and fast\n 578133 - (JaegerSpeed) [meta] JM: Make us fast!\n “as people finish these bugs, please post SunSpider comparisons, so we can check the expected win against the actual win, and make sure that we're on track to get where we need to be\n“This is a tracking bug for things that improve our perf, but only a tiny bit. Things linked directly from here should be considered low priority, unless someone discovers an easy way of doing them, or we find out they are more important than first believed.”- see AreWeFastYet.com\nNew problems: lots of code debt from multiple developers, Adobe contribution, etc. Hard to manoeuvre (this shows that the requirements and design debt are influencing the code debt and vice versa).\nThe narrative: FF working on new JIT compiler. One of the main goals is speed. But what features will help with speed requirement? Not sure yet. E.g. bug 582152: Sync earlier to avoid load stalls on doubles was originally in the tiny-perf bug 578225 but then linked into the main speed bug 578133 as it was realized how much it helped. \nTech debt in RE would suggest that focusing on small improvements over large ones would be a debt.\nSmall wins:\n23 bugs of which 5 are not fixed (22%)\nBig wins: \n67 bugs tracked of which 10 are not fixed (15%)\nThis seems like a sensible approach - most effort is focused on big wins. And no way to tell ahead of time? \nCould argue FF couldn’t knpw tracing wasn’t good in 2008. But 2 other teams did.\n
- Debt has these properties\nThe TD is not in the fact that we built the wrong thing. That is the cost. The debt is incurred when we take a short-cut. Interest is the fact that we now have to maintain these features, that we might have wasted time (which has value), and that we may have confused the stakeholders. “Compound” your mistake.\n\n
- Debt has these properties\nThe TD is not in the fact that we built the wrong thing. That is the cost. The debt is incurred when we take a short-cut. Interest is the fact that we now have to maintain these features, that we might have wasted time (which has value), and that we may have confused the stakeholders. “Compound” your mistake.\n\n
- Debt has these properties\nThe TD is not in the fact that we built the wrong thing. That is the cost. The debt is incurred when we take a short-cut. Interest is the fact that we now have to maintain these features, that we might have wasted time (which has value), and that we may have confused the stakeholders. “Compound” your mistake.\n\n
- Debt has these properties\nThe TD is not in the fact that we built the wrong thing. That is the cost. The debt is incurred when we take a short-cut. Interest is the fact that we now have to maintain these features, that we might have wasted time (which has value), and that we may have confused the stakeholders. “Compound” your mistake.\n\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- The size of the box indicates the amount of debt undertaken in terms of person-hours.\n
- You’ve all seen this curve before. Some of you pioneered it!\n\nWhat it says to me in the context of technical debt is that the tech debt is bending the slope of this curve. And, as we all know, if we can bend that curve downward earlier, we are much better off. \n\nAnd looking for a way to quantify these changes.\n
- You’ve all seen this curve before. Some of you pioneered it!\n\nWhat it says to me in the context of technical debt is that the tech debt is bending the slope of this curve. And, as we all know, if we can bend that curve downward earlier, we are much better off. \n\nAnd looking for a way to quantify these changes.\n
- I am focused primarily on the Intent box. Mischaracterizing intent.\n\nIntent - often the ‘requirements’. Product - what was achieved. Work - how things get done, not necessarily delivered. Emails, bug tickets, standups, etc. I’m propagating Phillippe’s attempt to de-formalize methodology titles. Although he is responsible for Rational Unified Process.\nSo is technical debt solely about one of these boxes? I.e., product quality over time? What about intent quality over time? Or is it rather about all of them? About shortcuts where we do a tradeoff for short-term gain for long-term pain. Hiring the good CV instead of demoing an employee, \n\n\nWe can even relate this to Highsmith’s extrinsic/intrinsic quality triangle (Value, Quality, Constraint): Value is Intent, Quality is Product, and People/Work is constraint. \n\nreal problem with Standish - cost/duration are only 2 legs of the triangle - want value as well\n
- (c) P. Kruchten\n
- The implementation is “fully known” however.\n\nso technical debt in requirements is when we take a short-cut on our route. Could be seen as process debt. Tech debt is also inverse - over-analysing the wrong thing and taking too long to get to market - the rumpus intersects our path. \n\nSEI - minimize rework - ie changed requirements. Release planning. Bridge gap with business/IT. Ozkaya’s phrase: delivery of working software that meets its business and quality goals. Tradeoff with overengineering can be resolved with business goal analysis \n\nMonitoring - how happy are customers? How used are the features, e.g. using clickmaps, web logs, API access.\n
- \n\nThis is a re-emphasis slide. I should make it clear what specifically TD removal might look like.\nBest practices. What could FF have done in 2008? Risk analysis a la Boehm; better req tracking; involve \noutside academics? \n\n80% of features not needed.\n\n
- - inf. sclerosis: “temporary workarounds for software deficiencies increasingly solidify into unchangeable constraints on evolution”. E.g. “it’s nice to see that you could change those equipment codes to make them more intelligible for us, but the Codes Committee just met and established the current codes as the company standard.” p24 We took the requirements as one thing, but then couldn’t refactor it after the sprint ended.\n- MTD 10 - the quote from the paper\n- From CAST: Are all the business rules that drive the software abstracted to effective-dated metadata? Can their metadata be configured non-destructively? Are there any business rules expressed as application code?\n- risk analysis - if there is little risk to a mistaken requirement, don’t spend too much time on it. NASA at forefront of best practices.\n “information sclerosis” (Boehm 86)\n Business rule metadata (CAST)\n\n
- Gas pedal. and my version of SRI. \nIt imposes some structure on your reasoning over the problem and then finds the best soln.\nCould argue it is too much overhead, but reality is that might be needed. \nAnother benefit - satisfaction of multiple requriements with one implementation. When requirements changes, in other words, the system might already be capable. \n
- You’ve all seen this curve before. Some of you pioneered it!\n\nWhat it says to me in the context of technical debt is that the tech debt is bending the slope of this curve. And, as we all know, if we can bend that curve downward earlier, we are much better off. \n\nAnd looking for a way to quantify these changes.\n
- This slide talks about my current work.\n\nOne of the things we’re looking at is how requirements are treated in practice. We look at a few projects with open repositories, like CONNECT, and try to see how they are doing requirements. That will let us experiment with some measures of requirements debt.\ne.g., feature requests or user stories\ne.g., this graph of what commands Eclipse people use.\n\nUsage data is a symptom of requirements debt. You priortizied a user story no one cared about, and wasted time. There is debt in poor requriements gathering (what else was missed?) and in features peple now have to maintain and worry about (sclerotic).\n
- \n
- \n
- \n
- Payback process\nInterest amount\nGold-plating vs under-estimating\n
- 1. Process debt is shortcuts in the process, e.g. no onsite customer. Requirements debt is related but more about shortcuts in analysis or modeling (if we think of elicitation as part of process). At any rate these debts compound each other. \n2. Do we have to actually commit code and release it to recognize debt in requirements? I don’t think so for req, just that you commit to that story. I.e. post exploration is only time you can see it. For code absolutely.\n4. Like buying a house - how do we do option valuations when we don’t have a good sense for the metric to track the underlying asset?\nMozilla case - as system grows, not only do we need to deal with the artifact debt, but also process debt - that we aren’t doing enough requirements gathering, or we aren’t looking in the right places, not understanding the stakeholders. Transitioning out of your niche. \n\nTrack it by measuring failed acceptance tests, or perhaps unsuccessful launches. Measure feature usage.\n