Bridging the software quality gap - umu.sethe software quality gap further. Using the terminology of...

Bridging the software quality gap

Markus Lindgren

Department of Computing Science, Ume̊a University

October 2012

Abstract

There is a gap in the understanding of software quality between develop-ers and non-technical stakeholders, the software quality gap, which leads todisagreements about the amount of time that should be used for quality im-provements. The technical debt metaphor reduces this gap some by describingsoftware quality in economic terms, enabling developers and non-technical stake-holders to communicate about the quality. However, the metaphor is vague andnot very concrete in explaining the gap. The purpose of this thesis is to con-cretize the technical debt metaphor using Domain-Driven Design, an approachin which communicating software characteristics is central, in order to reducethe software quality gap further.

Using the terminology of Domain-Driven Design, a new concept is defined:model debt, which measures and communicates the software quality of the do-main model. An application is built, the ModelDebtOMeter, which extracts thedomain model of a software system and visualizes it along with its correspondingmodel debt. The model debt of a legacy system is amortized and the results ofthe amortizations are presented to the non-technical stakeholders of the systemusing the ModelDebtOMeter, allowing the non-technical stakeholders to evaluatethe model debt concept.

The results show that the non-technical stakeholders think that model debtis an understandable concept which reduces, but not eliminates, the softwarequality gap.

Contents

1 Introduction 31.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Avanza Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 The quality barometer . . . . . . . . . . . . . . . . . . . . 51.3.2 This thesis and Avanza Bank . . . . . . . . . . . . . . . . 5

1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Technical debt 62.1 The debt confusion . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Other views on technical debt . . . . . . . . . . . . . . . . . . . . 72.3 Communication is the key . . . . . . . . . . . . . . . . . . . . . . 7

3 Domain-Driven Design 83.1 Focus on the domain instead of technology . . . . . . . . . . . . . 83.2 Knowledge crunching . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Model and implementation . . . . . . . . . . . . . . . . . . . . . 103.5 Ubiquitous language . . . . . . . . . . . . . . . . . . . . . . . . . 103.6 Isolate the domain . . . . . . . . . . . . . . . . . . . . . . . . . . 113.7 Bounded context . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.8 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.9 Agile acceptance testing . . . . . . . . . . . . . . . . . . . . . . . 12

4 Purpose 134.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Model debt 155.1 Business isolation debt . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Inefficient business debt . . . . . . . . . . . . . . . . . . . . . . . 165.3 Business behaviour debt . . . . . . . . . . . . . . . . . . . . . . . 175.4 Relation between the model debt types . . . . . . . . . . . . . . . 18

6 Method 196.1 Amortize model debt . . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1

7 Results 217.1 The ModelDebtOMeter . . . . . . . . . . . . . . . . . . . . . . . . 21

7.1.1 The importer . . . . . . . . . . . . . . . . . . . . . . . . . 217.1.2 The analyzer . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.2 Amortization of model debt . . . . . . . . . . . . . . . . . . . . . 237.2.1 Business isolation debt . . . . . . . . . . . . . . . . . . . . 237.2.2 Business behaviour debt . . . . . . . . . . . . . . . . . . . 247.2.3 Inefficient business debt . . . . . . . . . . . . . . . . . . . 25

7.3 Evaluation of the model debt concept . . . . . . . . . . . . . . . 257.3.1 Business isolation debt and business behaviour debt . . . 257.3.2 Inefficient business debt . . . . . . . . . . . . . . . . . . . 267.3.3 Model debt . . . . . . . . . . . . . . . . . . . . . . . . . . 267.3.4 ModelDebtOMeter . . . . . . . . . . . . . . . . . . . . . . 27

8 Discussion 288.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288.2 The model debt concept . . . . . . . . . . . . . . . . . . . . . . . 288.3 Model debt and software quality . . . . . . . . . . . . . . . . . . 298.4 The ModelDebtOMeter . . . . . . . . . . . . . . . . . . . . . . . . 298.5 Model debt and Domain-Driven Design . . . . . . . . . . . . . . 298.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

References 30

A Evaluation Form 32

B ModelDebtOMeter Screenshot 34

2

Chapter 1

Introduction

The product owner entered the room. The team was already sitting aroundthe table. It was time for another sprint planning meeting. The scrum masterspoke:

- What activities did you have in mind for this sprint?- Well, let’s see, first we have to add system support for modifying the layout

of our invoices. The marketing department wants to have the possibility tocustomize the advertisements depending on the size of the company, its currentengagement with us and so on. We have a couple of minor bugs that we need toget fixed. Then it would be great if we could start working on the next release.

- I see. We have a few activities that we didn’t have time to complete inthe previous sprint that we really need to get done. We have to restructure thebusiness rules engine a little. We realized in the last sprint that it’s just takingway too long to add new rules. We think it will be about five story points.

- But we won’t be adding new rules anytime soon, right?- That’s true, but I still think we need to restructure it. Besides, we worked

on the rules engine last sprint, so we have a really clear picture of what to do.The product owner thought for a while about what the scrum master had

said. He was really tired of these kinds of discussions. Restructuring this andrestructuring that. Why don’t we spend all of our time restructuring? Toobad developers can’t stop worrying about technical issues and instead focus onbusiness value. It doesn’t matter anyway. The management made themselvesvery clear this morning. They explicitly said that we had to start working onthe next release.

- Well, I’m still not convinced. I really think we need to get started on thenext release.

The scrum master was really tired of these kinds of discussions. The nextrelease, and then the next release, and then the next release. Why don’t we stopdesigning, testing and even thinking so that we can release quicker? The roadto hell, that’s what would happen. Too bad business people are so obsessedwith making new releases that they neglect software quality. The scrum masterwas about to give up the argument but thought that he better try the technicaldebt metaphor first.

- You know that ignoring to restructure the business rules engine will increaseour technical debt. Don’t you think we’re paying enough interest as it is?

The product owner had heard this before. Sure, technical debt certainly

3

added something to the usually so meaningless discussions about restructuringactivities that he had from time to time with the developers, but he still didn’tfeel confident with this new kind of invisible debt.

- I guess you’re right. But unfortunately there isn’t enough time to do itnow. It will have to wait to a future sprint.

The scrum master felt the frustration coming. He had experienced this toomany times: trying to explain the need for quality improvement to the productowner. The technical debt metaphor had made this task easier but now it almostseemed to make things worse. It didn’t explain software quality good enough.It wasn’t concrete enough. It didn’t bridge the software quality gap betweendevelopers and non-technical stakeholders.

1.1 Approach

There is a gap in the understanding of software quality between developersand non-technical stakeholders, the software quality gap. The technical debtmetaphor reduces this gap some by introducing a shared language that enablesdevelopers and non-technical stakeholders to communicate about software qual-ity. However the metaphor is a very rough and uncut technique and it is notvery concrete in explaining the gap. What is needed is a better developed sharedlanguage that communicates software quality in a more precise manner.

One way to tackle this problem is to look closer at other approaches withinsoftware development in which communicating software characteristics is centralto see if they can be used to concretize the technical debt metaphor. This thesistakes this approach and does so by looking closer at Domain-Driven Design: anapproach in which it is central that developers and non-technical stakeholdersdesign a software system in close collaboration.

1.2 Related work

I have not found any attempt to explore the technical debt metaphor usingDomain-Driven Design. There are however ongoing attempts to explore themetaphor: “Therefore, we propose managing technical debt as a part of thefuture research agenda for the software engineering field.” [3]. The softwarequality gap is also recognized and described: “Software developers and corporatemanagers frequently disagree about important decisions regarding how to investscarce resources in development projects, especially in relation to internal qualityaspects that are crucial to system sustainability, but that are largely invisible tomanagement and customers... Engineers often advocate for such investments,but executives question their value and frequently decline to approve them, tothe long-term detriment of software projects.”. The approach to abandon thetechnical debt metaphor in favor of another technique is also recognized: “Isdebt a sound metaphor for managing expedients and remediative investments insoftware projects? If not, is there a closely related metaphor that is better‘”.

4

1.3 Avanza Bank

Avanza Bank is one of the biggest actors for trading shares and funds in Swe-den. All transactions are handled electronically and the business contains manycrucial software systems. Software quality is very important, not only for de-velopers but also for non-technical stakeholders, since IT is such a crucial partof the business. Avanza Bank has made previous efforts to communicate soft-ware quality between developers and non-technical stakeholders using a qualitybarometer.

1.3.1 The quality barometer

The quality barometer is an estimation of software quality made by developersin a dialogue with non-technical stakeholders. The estimation is presented usinga business-friendly scale which signals how the customers of Avanza Bank are af-fected by the software quality. The quality barometer has been used successfullyfor a couple of years at Avanza Bank.

1.3.2 This thesis and Avanza Bank

The problem with the quality barometer is that it is built upon estimations.It would be better if software quality could be based on more concrete factsbut still be explainable to non-technical stakeholders. This thesis takes oneapproach to see if this is possible.

1.4 Outline

Background information of technical debt and Domain-Driven Design are pre-sented in chapter 2 and 3. A more specified purpose is defined in chapter 4. Theconcepts given in the background information are used to define a new concept:model debt in chapter 5. Chapter 6 outlines the method used in this thesisand chapter 7 summarizes the results obtained after applying the method. Inchapter 8 the result are discussed and conclusions are drawn.

5

Chapter 2

Technical debt

In the last couple of years technical debt has become a new buzzword in the agilecommunity. As [3] puts is “The technical debt metaphor is gaining significanttraction in the agile development community...”.

Despite its boom in use lately, the technical debt metaphor is almost twodecades old. It was coined in 1992 by Ward Cunningham in an experience report[4]:

“Shipping first time code is like going into debt. A little debt speeds devel-opment so long as it is paid back promptly with a rewrite. [...] The dangeroccurs when the debt is not repaid. Every minute spent on not-quite-right codecounts as interest on that debt. Entire engineering organizations can be broughtto a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

2.1 The debt confusion

The original description of technical debt was not very precise and when themetaphor gained in popularity, people started to interpret it in different ways.This made Cunningham further clarify what he meant [5]:

“I thought borrowing money was a good idea, I thought that rushing softwareout the door to get some experience with it was a good idea, but that of course,you would eventually go back and as you learned things about that software youwould repay that loan by refactoring the program to reflect your experience asyou acquired it. I think that there were plenty of cases where people would rushsoftware out the door and learn things but never put that learning back into theprogram, and that by analogy was borrowing money thinking that you never hadto pay it back. [...] You know, if you want to be able to go into debt that wayby developing software that you don’t completely understand, you are wise tomake that software reflect your understanding as best as you can, so that whenit does come time to refactor, it’s clear what you were thinking when you wroteit, making it easier to refactor it into what your current thinking is now.”

The bottom line of what Cunningham is saying is that technical debt doesnot incur when you are developing software but after the software has beenreleased, when you learn things about it by getting feedback from reality.

This is the point of confusion where other people have expanded the original

6

“definition” of technical debt to also include debt that comes from poorly writtencode during development. The danger arises when you combine the expandeddefinition with Cunningham’s view that technical debt is something desirableto have after a release. This is something that Ward also recognizes:

“A lot of bloggers at least have explained the debt metaphor and confusedit, I think, with the idea that you could write code poorly with the intention ofdoing a good job later and thinking that that was the primary source of debt.I’m never in favor of writing code poorly, but I am in favor of writing code toreflect your current understanding of a problem even if that understanding ispartial.”

2.2 Other views on technical debt

Steve McConnell categorizes technical debt into unintentional debt, which isfoolish to incur, and intentional debt, which might be incurred for reasons suchas time to market, preservation of startup capital and delaying developmentexpense [10]. Part of the intentional debt would be equal to Cunningham’soriginal definition.

Martin Fowler further divided intentional and unintentional debt into reck-less and prudent debt [8].

Robert C. Martin comes close to Wards original definition by saying “Amess is not a technical debt” [9] but he also diverges from Ward by includingtechnical frameworks into the discussion.

2.3 Communication is the key

A clear definition of technical debt seem to be lacking. This is most likely aresult of the fact that most writing on the topic has been in blogs and that noresearch has been carried out in order to develop such a definition.

Given the vague definition of technical debt, it is fascinating how widespreadthe metaphor has become. I think that the reason for this is that the metaphoraddresses a very real and significant problem in the software industry which isscreaming for solutions: the software quality gap.

The power of the technical debt metaphor is not that it provides a goodway to measure software quality. The power of the technical debt metaphoris that it reduces the software quality gap some by describing software qualityto non-technical stakeholders in economic terms. This is something that [3]also recognizes: “Technical debt metaphor to date mostly has been used as acommunication device.”. The problem with the metaphor is that is doesn’treduce the software quality gap enough.

7

Chapter 3

Domain-Driven Design

The term Domain-Driven Design (DDD) was coined by Eric Evans in his bookwith the same title [7]. This chapter is a summary of the parts of the bookrelevant to this thesis. As the subtitle of the book suggests DDD is aboutTackling Complexity in the Heart of Software. What is meant by this heart ofsoftware?

3.1 Focus on the domain instead of technology

A common view is that software development is about solving different technicalchallenges. The complexity lies in choosing a suitable technology for the task athand and in creating a design which makes the different technologies fit togethersmoothly. This focus is natural since many developers have a big interest intechnology.

DDD recognizes that the main complexity in software development is nottechnical. Instead the complexity lies in the area for which the software is beingdeveloped: the domain of the software. A software domain can be anythingfrom cargo shipping to accounting. This domain is what DDD calls the heartof the software. A domain expert is a person who has good knowledge of thedomain, e.g. in the domain of accounting an accountant is a domain expert.

When focus is changed from technology to the domain new problems arise.How should a complex domain be managed in a software system? FortunatelyDDD has a solution to this problem: knowledge crunching the minds of thedomain experts into a domain model.

3.2 Knowledge crunching

Why can’t we ask the domain experts for the domain model? Why is thisknowledge crunching thing necessary? The reason for this is that the knowledgeof the domain experts contains lots of common sense and developing softwarefrom common sense is impossible. The common sense have to be concretizedin order to make software development possible. This process is what Evanscalls knowledge crunching. Developers together with domain experts distillthe complex and unstructured knowledge of the domain experts into rigorousconcepts which form a domain model. This is an iterative process which never

8

completes. New ideas are constantly tested and many of them are rejected.Knowledge crunching increases the domain knowledge of the developers andgives domain experts better insight into how rigorous computer software haveto be.

When focus of software development lies on technology rather than on thedomain little knowledge crunching is done together with the domain experts.The communication between developers and non-technical stakeholders is aboutwhat the system should do and not about how the domain works. The domainexperts describe what they want and the developers implements it. As Evansputs it: “...if programmers are not interested in the domain they learn only whatthe application should do, not the principles behind it.”.

Typical things that will happen when knowledge crunching is carried outis that new concepts will appear. Concepts that the domain experts use intheir daily jargon but that the developers haven’t understood or thought wasimportant. To make this happen it is important that the developers carefullylisten to the language of the domain experts. Are they using terms that seemcomplex but still important? Do they look puzzled when you use your ownterms? Do they correct you? An example of this phenomenon is that developersoften use the word user to describe any person using the system. When talkingto domain experts one often discovers that this user is actually something morespecific, e.g. a customer or a person with a power of attorney.

3.3 Domain Model

Evans makes a good explanation of a model: “A model is a simplification. Itis an interpretation of reality that abstracts the aspects relevant to solving theproblem at hand and ignores extraneous detail.”. Important points are that amodel is a simplification: it is not meant to capture all aspects of reality andthat it is an interpretation of reality which means that it can be interpreted ina infinite number of ways. The goal of the knowledge crunching of the domainexperts minds is to end up with a domain model which contains abstractionsto solve the problem at hand in the most efficient way. To achieve this goalthe concepts of the domain model have to be very clear and exact. Stated inanother way, the concepts of the domain model need to have a high conceptualclarity.

A typical sign of an ineffective domain model is when developers start to talkabout corner cases. When there are many corner cases in a software system it isvery likely that the domain model, if present at all, contains poor abstractionsfor solving the problem at hand. In this case developers often blame the domainexperts for coming with tedious requirements, but the real problem is that thedevelopers don’t try to adapt the domain model to match the requirementsof the domain experts. Another sign of this problem is that the design feelsawkward in such a way that a seemingly easy problem takes a lot of work tosolve. A warning sign is when domain experts use a vocabulary that is notpresent in the implementation.

Creating a domain model is a highly creative process. To do it well it isnecessary to be able to think outside the frames of the existing model and notto be locked up in the present concepts. It is also important not to try to forcethe evolution of the domain model into a certain direction. According to Evans,

9

domain models are often not as obvious as one might think when first facedwith a problem.

3.4 Model and implementation

For a domain model to be useful it has to be used in the running softwaresystem. After all, the purpose of the domain model is to make the problemat hand easier to tackle by using the knowledge of the domain experts. If thedomain model isn’t present in the software that advantage is lost and the wholepurpose of DDD vanishes.

The domain model and implementation shape each other. If a knowledgecrunching session leads to a discovery of a new concept the implementation haveto be refactored to include that concept. In the same way, if a developer findsa limitation in a technical framework which make the implementation of thecurrent domain model impossible, that limitation has to be communicated tothe domain experts and the domain model has to be modified to reflect it.

To be able to make the gap between the domain model and the implementa-tion as small as possible it is necessary that the implementation language allowsyou to create concepts similar to those in the domain model. The object-orientedlanguages are such languages since they are based on a modeling paradigm: theobject-oriented modeling paradigm. Furthermore, the object-oriented paradigmoften feels natural to both developers and non-technical stakeholders. Thismakes object-oriented programming and DDD a good fit.

3.5 Ubiquitous language

It is not enough for the domain model to be present in the implementation. Ithas to be present in all activities which has anything to do with the domain suchas diagrams, in writing and in speech. The language of the domain model shouldbe the basis for all communication about the domain. It should be ubiquitous.No big surprise Evans calls it the ubiquitous language.

The reason for it to be ubiquitous is that translation makes communicationvery cumbersome. Developers communicate using a technical language whilenon-technical stakeholders communicate using their business language. The gapbetween the two languages is big and a significant translation effort has to bemade to be able to communicate at all. Even so, confusion and misunderstand-ings regularly occur. In the best case someone who knows both the jargon of thedomain experts and the technical language of the developers are able to makeinexact translations. In the worst case a developer or a domain expert stopslistening to the other part because they simply don’t understand each other.As Evans puts it: “...developers have to translate for domain experts. Domainexperts translate between developers and still other domain experts. Developersevent translate for each other. [...] This leads to unreliable software that doesn’tfit together.”.

Of course, domain experts and developers can use their own jargon at times,but not when talking about the domain.

10

3.6 Isolate the domain

To be able to tackle a new business requirement effectively it is necessary tohave a clear picture of the part of the software that the requirement will affectso that it is possible to reason about the relationship between that part and therequirement. A business problem usually has little to do with technology. Ifthe business logic of the software is tangled with technical infrastructure thenit is very hard to get that clear picture. Therefore it is necessary to dedicate anexplicit part of the software in which the business logic lives: the domain layer.The layering pattern will not be explained here. The important point is thatthe business logic lives in the domain layer and that the domain layer have nodependencies to other layers. The domain layer is a prerequisite to be able toapply DDD.

3.7 Bounded context

At most companies there is not one domain model at play, but multiple. Thefailure to recognize this fact and trying to apply one domain model across theentire company will come at a high price. Concepts from different models willbe mixed up causing confusion and bugs. Concepts will appear multiple timesmaking changes more difficult. The unified model will start to fragment. Atypical scenario is that a developer changes a concept without establishing thenew meaning to everyone else involved and thus failing to include it in theubiquitous language. This happens simply because it’s too time consuming tointegrate a change with everyone involved on a project.

One have to be aware of these models and define their relationships to eachother. To do that Evans introduced the concept of a bounded context: “Thebounded context is whatever set of conditions must apply in order to be ableto say that the terms in a model have a specific meaning.”. A model alwaysapplies in a context. The bounded contexts should be explicitly defined, bothin the domain model and in the implementation. It is natural that the boundedcontexts follow the organization of teams since people who work close togetheroften share the same concepts.

When multiple bounded contexts are in play new questions arise. How shouldthe different contexts relate to each other? Which contexts needs to integratewith each other and which can diverge? Is it possible to translate a concept fromone context to another? Evans presents a number of strategic design patternsfor dealing with these kinds of problems but this is out of the scope for thisthesis.

3.8 Scenarios

A scenario is a concrete example of something that happens in the domain andthat is important to the domain experts, together with its preconditions andpostconditions. Let’s look at an example:

Given a company.And a manager who works at the company.And an employee with a salary of 10000$ who works at the company.

11

When the manager fires the employee.Then the employee should have a salary of 0$.

In this example the preconditions follows the Given keyword, what happensin the domain follows the When keyword and the postconditions follows theThen keyword. Writing scenarios using these keywords is not required, but it isa common practice which comes from agile acceptance testing, a methodologydescribed in the next section.

Scenarios are created in collaboration between developers and domain ex-perts and are stated in the ubiquitous language of the domain model. In theexample above company, manager, employee, salary and fires are all part of theubiquitous language of that domain model.

The purpose of scenarios is to encourage knowledge crunching. Walkingthrough a concrete example forces you to think about the concepts of the domainmodel in a very concrete way. Evans doesn’t describe scenarios at any greaterdepth in [7] but talks about their role in DDD and in the agile developmentprocess in his whirlpool model [6].

Scenarios are not only important within DDD. They play the main role inagile acceptance testing.

3.9 Agile acceptance testing

Agile acceptance testing (AAT) is a methodology related to DDD. It recognizesthe need for an ubiquitous language but has a different focus than DDD. Itfocuses almost entirely on creating scenarios through collaboration and commu-nication between developers and non technical-stakeholders. Agile acceptancetesting is described by Gojko Adzic in [2].

Adzic describes a communication gap, which is similar to the software qual-ity gap but less specific since it includes all communication problems betweendevelopers and non-technical stakeholders, not just the ones related to softwarequality. The purpose of AAT is to reduce this gap by improving the communi-cation between developers and non technical stakeholders. This is achieved bywriting scenarios.

Apart from focusing more clearly on scenarios, AAT distinguishes itself fromDDD by recognizing the need to automate scenarios by implementing themas acceptance tests. Together the implemented scenarios form an executablespecification which contrary to an ordinary requirements specification alwaysstays up to date since it constantly executes and verifies that the system behavesas specified.

Although AAT recognizes the need for an ubiquitous language it does notrequire it to be present in the implementation. Adzic writes: “Developers thenimplement the domain code and the test automation part in parallel, with gluecode to connect them. This glue code allows us to effectively separate the speci-fication from implementation details.” [2, p. 111]. A relevant question is if thelanguage really is ubiquitous if it is not present in the implementation. Anyhow,this is something that clearly separates AAT from DDD.

12

Chapter 4

Purpose

It is clear from the background chapter of DDD that a weak domain modelwith a weak ubiquitous language will lead to a communication gap betweendevelopers and non-technical stakeholders. This gap is closely related to thesoftware quality gap described in the introduction. How can it be possible for anon-technical stakeholder to know about the quality of a software system whenthey fail to communicate its design with the developers? It is reasonable toassume that by concretizing and explaining this communication gap to non-technical stakeholders the software quality gap will also decrease. This is theapproach taken by this thesis and it is done by joining the concepts of DDDwith the technical debt metaphor.

4.1 Purpose

The purpose of this thesis is to use Domain-Driven Design to concretize thetechnical debt metaphor so that software quality for a non-technical stakeholderbecomes visible, measurable and understandable.

4.2 Research questions

To fulfill the purpose of this thesis the research questions below have to beanswered. It is assumed that the concretization of the technical debt metaphorwill lead to a new software quality concept.

• Which concepts from DDD should be used to concretize the technical debtmetaphor? How will they measure software quality?

• How should the domain model and the new software quality concept bepresented in order to make software quality visible? How can the domainmodel be extracted from an existing software system?

• Does the new software quality concept work in practice? Can it be appliedto a working software system? Does it measure software quality in areasonable way?

13

• In what way can the new software quality concept be tested to makesure that software quality becomes understandable for a non-technicalstakeholder?

14

Chapter 5

Model debt

The first research question will be answered in this chapter by introducing thenew concept of model debt. Model debt concretizes the technical debt metaphorby using concepts from DDD and adding measurability.

The strong focus on the domain which DDD requires has implications onsoftware quality. A strong focus on the domain makes the quality of the do-main model much more important. The role of the non-technical stakeholdersin software development also changes. They become more important since theyare the persons with the best knowledge in the domain for which software isgoing to be developed. The consequence of this thinking is that software qual-ity is something that not only concerns developers but also the non-technicalstakeholders. The quality of the domain model is more closely related to thenon-technical stakeholders and the business than to developers and software.This is the idea behind the concept of model debt and it explains why thenames and the explanations of the model debt parts are free of software terms.

Model debt applies to the domain model of a software system and consistsof three types:

• Business isolation debt. Indicates how well the business logic is isolatedfrom technical infrastructure and irrelevant business logic.

• Business behaviour debt. Indicates the amount of knowledge crunchingcarried out in the domain model.

• Inefficient business debt. Indicates how efficiently the current domainmodel solves problems in the domain.

These concepts will be described in further detail in the rest of this chapter.The descriptions will introduce some new concepts:

Model block - An object in the domain model.

Criteria - The criteria which a model has to fulfill in order to be free of debt.

Measurement - Description of how the debt is measured.

Interest - The interest payed if the debt is not amortized.

15

5.1 Business isolation debt

Keeping the business logic isolated is a necessity. If the business logic is tan-gled with technical infrastructure or if different parts of the business are mixedtogether it is very difficult, if not impossible to understand how the businessworks. A low business isolation debt is a prerequisite to be able to amortizebusiness behaviour debt.

Criteria

All model blocks belong to one layer and one bounded context. Model blocksin the domain layer don’t have associations to model blocks in other layers.

Measurement

Business isolation debt is measured by the number of model blocks which don’tmeet the criteria above. If a model block belongs to a bounded context but notto a layer or vice versa, half of the model block meets the criteria. If a modelblock has an association to another model block with business isolation debt,half of the model block meets the criteria.

Interest

A low business isolation debt is a prerequisite for amortizing business behaviourdebt and inefficient business debt. Without an isolated business it is not possibleto walk through scenarios with the domain experts since it is not known wherethe domain is and it is hard or impossible to reason about the efficiency of thedomain model. Choosing not to amortize business isolation debt means thatyou’re stuck with a technical model which is not possible to communicate tonon-technical stakeholders.

Business isolation debt means that the bounded contexts of the domainmodel are not explicitly defined. This leads to, as described in the background,a fragmented and confusing domain model

5.2 Inefficient business debt

To concretize the technical debt metaphor further we use the approach describedin [3]: “One way to understand technical debt is as a way to characterize thegap between the current state of a software system and some hypothesized “ideal”state...”. Using concepts of DDD these states will be two models:

The current model - The current model in use and the model for which youwant to know the model debt.

The desired model - The domain model which the non-technical stakeholderswant, but which doesn’t yet exist.

An interesting property of inefficient business debt is that there is no debtwithout a desired model. This means that if all stakeholders are willing to speakthe ubiquitous language of the existing model then there is no model debt in

16

the system. In reality this will seldom be the case since this means that non-technical stakeholders have to learn the vague technical language that is mostlikely present in the system.

When the domain experts are aware of flaws in the current model which don’tget corrected the model contains inefficient business debt. Note the similaritiesbetween inefficient business debt and Cunningham’s definition of technical debt.

Criteria

The current model equals the desired model, i.e. the models don’t differ in anyof the following ways:

• A model block in the current model belongs to another layer in the desiredmodel.

• A model block in the current model belongs to another bounded contextin the desired model.

• A model block in the current model doesn’t exist in the desired model. Inother words it is redundant.

• A model block which exists in the desired model is missing in the currentmodel.

Measurement

Inefficient business debt is measured by the number of model blocks which differsbetween the current model and the desired model in any of the ways describedin the criteria above.

Interest

The greater the gap between the current model and the desired model, thegreater the communication gap between developers and non-technical stake-holders. This gap leads to misunderstandings and many of them will in turnlead to bugs. A big communication gap also indicates that little knowledgecrunching has been applied to the current model. This means that the con-cepts in the model most likely are technical in nature and not the most efficientconcepts to solve problems in the domain. Software development becomes in-efficient. It is difficult to know what the non-technical stakeholders want andeven if that is understood it takes a long time to implement it since the currentmodel is inefficient.

5.3 Business behaviour debt

To make inefficient business debt useful the desired model has to be known.How can that be achieved in practice? Looking back at DDD we find an answer:knowledge crunch scenarios together with domain experts using the ubiquitouslanguage of the current domain model. Doing that will reveal weaknesses inthe current model which the domain experts will want to replace with modifiedconcepts in a new desired model. Another way to put it is that if you don’t

17

have an executable specification covering the entire domain model then youdon’t know how far away the current model is from the desired model. Thecurrent model contains inefficient business debt which you can’t see. Therefore,a low business behaviour debt is a prerequisite to be able to amortize inefficientbusiness debt.

Criteria

All behaviour of the domain model is exercised by an executable specification.

Measurement

Business behaviour debt is measured by the number of behaviours which areexercised by an executable specification.

Interest

If the business behaviour debt is high it is very likely that the software doesnot work as expected, i.e. it contains bugs. This is because the developerswill have implemented the business behaviour without communicating it to thenon-technical stakeholders, causing misunderstandings and in turn bugs. An-other advantage of keeping the business behaviour debt low is that you gainadvantages from the executable specification, e.g. when you make a change tothe software system you can be certain that the domain model still work asexpected.

The process of amortizing business behaviour debt reveals the desired model.Therefore, a high business behaviour debt makes it impossible to amortize inef-ficient business debt. This means that you are stuck with an inefficient domainmodel.

5.4 Relation between the model debt types

To get anywhere you have to start to isolate the domain model from technicalinfrastructure and unrelated business logic, i.e. you have to amortize businessisolation debt. Doing so will reveal where the domain model is and it is possibleto discuss it with non-technical stakeholders. It is possible to walk throughscenarios with them and to implement them as an executable specification, i.e.amortizing the business behaviour debt. Doing so will reveal weaknesses in thedomain model such as vague or technical concepts, or in other words it willreveal the inefficient business debt. The last step is to amortize this debt sothat the efficiency of the domain model increases, making software developmentfaster and less error prone.

18

Chapter 6

Method

To answer the remaining research questions I will:

• Build an application, the ModelDebtOMeter, which shows the model debtof a software system.

• Amortize the model debt of an existing legacy system at Avanza Bank.

• Let the non-technical stakeholders of the legacy system evaluate modeldebt to find out if they think that it is an understandable concept.

The last two steps will be explained in more detail below.

6.1 Amortize model debt

First, a legacy system at Avanza Bank suitable for quality improvement has tobe identified. This system will from now on be referred to as the legacy system.

The first type of model debt that will be amortized will most likely be busi-ness isolation debt since this is a prerequisite for amortizing inefficient businessdebt and business behaviour debt.

With the business isolation debt reduced it is technically possible to write anexecutable specification and it is also possible to do knowledge crunching of thedomain model together with the domain experts. This knowledge crunching ofthe current model will be done one step at at time, slowly revealing the desiredmodel:

1. Write a scenario using the ubiquitous language of the existing model to-gether with the domain experts.

2. Find out which problems the domain experts see with the existing model,i.e. reveal the inefficient business debt.

3. Implement the scenario as part of an executable specification and makethe scenario pass, i.e. amortize the business behaviour debt.

19

6.2 Evaluation

In order to find out if the non-technical stakeholders of the legacy system thinksthat model debt is an understandable concept they will be invited to a sessionwhere I will:

• Explain the model debt concept using the descriptions given in chapter 5.

• Show how the model debt has changed over time in the legacy systemusing the ModelDebtOMeter.

• Evaluate the model debt concept by letting the non-technical stakeholdersfill in the evaluation form found in appendix A.

20

Chapter 7

Results

The results of this thesis consist of three parts:

• The ModelDebtOMeter, an application which shows the model debt of asoftware system.

• The result of the amortizations of model debt in the legacy system atAvanza Bank.

• The result of the evaluation of the understandability of the model debtconcept.

Each of these results are described in more detail below.

7.1 The ModelDebtOMeter

The ModelDebtOMeter is a Java application which shows the model debt of asoftware system. The application consists of two parts: the importer and theanalyzer.

7.1.1 The importer

The importer has the responsibility to import the domain model of an existingsoftware system. To achieve this it needs to be fed with the following parameters:

• The naming convention used for the domain layer.

• The naming convention used for the bounded contexts.

• The location of the executable specification (if there is any).

• The import date, i.e. the date at which the domain model to be importedwas in use.

The importer uses Java reflection to obtain information about the classes ofthe domain layer of the software system. More specifically it obtains:

• Class names.

21

• Public methods (behaviour).

• References (through constructors and methods).

• The result of running the behaviour specification.

To be able to obtain this information and to run the behaviour specification,the classes of the domain model have to be available on the class path. This isachieved by a script which:

1. Fetches the source code of the software system at the given import date.

2. Uses Maven to compile the source code and package it into jar-files.

3. Invokes the importer with the jar-files on the class path.

Since the importer uses an import date, it is possible to import the samedomain model multiple times, each with a different import date. This makesit possible for the analyzer to compare and analyze different versions of thedomain model.

The information obtained from the class path is arranged into Java-objectsand stored in a neo4j graph database.

7.1.2 The analyzer

The analyzer has the responsibility to visualize the imported domain modelstogether with their model debt. Upon startup the analyzer loads all the im-ported domain models from the neo4j graph database and displays them in amenu. When a user selects one of these domain models from the menu it willbe visualized in a screen similar to the one shown in appendix B.

The grey box named isolated business contains all model blocks which belongto the domain layer and which are free of business isolation debt. These arethe model blocks of interest for business behaviour debt and inefficient businessdebt. Outside the isolated business are model blocks for which it is not knownwhich layer or bounded context (or both) they belong to, i.e. they containbusiness isolation debt.

To the right of the domain model the model debt of the domain model isshown by displaying the measurements of the three model debt types. Clickingon one debt type will show more detailed information about that debt type:

Business isolation debt - Displays the model blocks which contain businessisolation debt in red. Associations from the domain layer to other layersare also displayed in red since they cause business isolation debt.

Business behaviour debt - Shows all behaviours of the model blocks in thedomain layer and displays the behaviours with business behaviour debt inred.

Inefficient business debt - Displays the model blocks which are present inthe current domain model but is missing in the most recent domain modelin red. Model blocks which are present in the most recent domain modelbut are missing in the current model are also listed in red. All of thesemodel blocks contain inefficient business debt.

22

7.2 Amortization of model debt

In discussion with my supervisor we found a legacy system suitable for qualityimprovement. It is a software system which is relatively independent of othersystems, making it easy to modify without affecting too many other systems.This section describes the results of amortizing the model debt of the legacysystem as measured by the ModelDebtOMeter. During the amortizations of themodel debt, interest that was payed on the debt before the amortizations weremade was discovered. This interest is also presented.

7.2.1 Business isolation debt

The first obvious problem of the legacy system was that its business logic wastangled with technical infrastructure and unrelated business logic. In otherwords, the business isolation debt was high.

Measuring the model debt with the ModelDebtOMeter before the amortiza-tion yielded the following result:

Business isolation debt 99 of 99 (99%)Business behaviour debt 0 of 0 (0%)Inefficient business debt 0

The fact that 99 of 99 doesn’t give 100% is not a bug. For one model block,half of its business isolation debt had already been amortized. The reason whythe business behaviour debt measures to 0 of 0 is because the model blocksof the domain layer are not known and therefore the behaviours of the modelblocks of the domain layer are not known.

The business isolation debt was amortized by moving the legacy system intoits own bounded context, separating it from unrelated business logic, and byidentifying the model blocks belonging to the domain layer and moving theminto that layer. Measuring the model debt with the ModelDebtOMeter after theamortization yielded the following result:


The business isolation debt has been reduced significantly. Note that thetotal number of model blocks have also been reduced by 37 (from 99 to 62).The reason for this is that unrelated business logic that used to be tangled withthe business logic of the legacy system has been moved into its own boundedcontext. The business isolation debt has not been completely amortized becausesome dependencies from the domain layer were located outside of the legacysystem and it was simply too much work to refactor them into a domain partand a technical infrastructure part.

Interest

Before the amortization, the business logic of the legacy system was tangledwith unrelated business logic. This led to the fact that when the business logic

23

of the legacy system failed, the business logic of the unrelated business alsofailed, making it impossible for the users of the systems built upon that logic tokeep working as normal. When the unrelated business logic was separated fromthe legacy system into its own bounded context, the problem disappeared. Inother words, when the business isolation debt was amortized, the interest payedon the debt decreased.

7.2.2 Business behaviour debt

With the business isolation debt reduced, business behaviour debt was the nextcandidate for amortization. In discussion with the non-technical stakeholders wedecided to amortize the business behaviour debt of 2 of the total 24 behavioursof the domain model. These two behaviours were chosen because they belong tomodel blocks which are relatively independent of the rest of the domain model ofthe legacy system, making it easier to write an executable specification, and alsobecause the non-technical stakeholders had experienced problems with them.

For each of the two behaviours I prepared a few basic scenarios and invitedthe non-technical stakeholders of the legacy system to a session with the purposeto knowledge crunch the scenarios, come up with new ones, and find out whatmain problems the non-technical stakeholders experienced in the current domainmodel.

The result of the session was 7 scenarios which all of them were imple-mented as an executable specification. Measuring the model debt with theModelDebtOMeter after the amortization yielded the following result:


The business behaviour debt decreased from 100% to 92% since two be-haviours were covered by an executable specification. The number of modelblocks of the business isolation debt increased from 62 to 63 because new func-tionality had been developed in the legacy system between the two measure-ments.

Interest

Of the 7 scenarios, 2 failed when implemented as an executable specification.The legacy system simply did not work the way the non-technical stakeholdersexpected. It was not serious defects but still defects that could potentiallymake the legacy system produce incorrect results. This is a clear example ofbugs which are not known because too little knowledge crunching of the domainmodel has been carried out.

The executable specification prevented a serious bug from reaching the pro-duction environment. A few weeks after the executable specification was createda refactoring of common code made the legacy system behave incorrectly. Thiswas caught by the executable specification and the bug was taken care of beforeit could cause any damage. The interest payed on the business behaviour debtbefore the amortization was made include the damage that the bug would havecaused.

24

7.2.3 Inefficient business debt

When knowledge crunching the scenarios of the legacy system problems withits current domain model were discovered:

• There was one redundant concept. The concept was used heavily in thelegacy system but it was very technical in nature and did not have anycounterpart in the business domain. The non-technical stakeholders pre-ferred to use another concept.

• There was one missing date-concept. In the legacy system there were threedifferent date concepts, hidden deep in the model as technical details.These dates did not make sense to the domain experts. Instead theypreferred to use another date-concept which was missing in the currentdomain model.

• There were two missing event-concepts. The legacy system acted upondifferent events in the business domain but these events were not explicitlymodeled in the current domain model but instead represented as technicaldetails.

Measuring the model debt with the ModelDebtOMeter after the amortizationyielded the following result:


The inefficient business debt is 4 since there are 4 inefficiencies in the currentdomain model (1 redundant concept and 3 missing concepts). In the desireddomain model the redundant concept would be removed and the three missingconcepts would be added.

Interest

The redundant concept has been the cause of many misunderstandings betweenthe developers and non-technical stakeholders of the legacy system. The useof technical concepts instead of the three missing concepts has led to a systemwhich is not understandable by non-technical stakeholders. This in turn has ledto a legacy system which behaves incorrect at a regular basis.

7.3 Evaluation of the model debt concept

The model debt concept was evaluated by five non-technical stakeholders. Theresult of the evaluation, i.e. the average result of the quantifiable questions anda summary of the written comments, is described in the rest of this section.

7.3.1 Business isolation debt and business behaviour debt

The questions related to business isolation debt and business behaviour debtyielded the following average results:

25

I think that business isolation debt is a clear concept that is easy to un-derstand.

Agree � � � � � Disagree

I think that business behaviour debt is a clear concept that is easy tounderstand.


The non-technical stakeholders thought that both concepts were clear andeasy to understand. To make them even clearer they suggested that:

• More and better examples are presented.

• They are translated into Swedish.

7.3.2 Inefficient business debt

The question related to inefficient business debt yielded the following averageresult:

I think that inefficient business debt is a clear concept that is easy tounderstand.


The non-technical stakeholders did not agree nor disagree to the statement.To make inefficient business debt clearer they suggested that:

• The concept of a desired domain model is made clearer.

• It is better explained how inefficient model debt is measured.

• More and better examples are presented.

7.3.3 Model debt

The questions related to the model debt concept as a whole yielded the followingaverage results:

I think that the relationship between the different parts of model debt(business isolation debt, business behaviour debt, inefficient business debt)is clear and easy to understand.


I think that model debt highlights relevant aspects of software quality.


26

The non-technical stakeholders thought that model debt highlighted relevantaspects of software quality and that the relationship between the different partsof model debt was clear and easy to understand. To make the relationshipclearer they suggested that:

• More and better examples are presented. Especially the relationship be-tween business behaviour debt and inefficient business debt needs moreclarification.

• Instead of having inefficient business debt as one part of the model debtconcept, build the model debt concept around inefficient business debt.

• The model debt concepts are translated into Swedish.

7.3.4 ModelDebtOMeter

The questions related to the ModelDebtOMeter yielded the following averageresult:

I think that we should use the ModelDebtOMeter to work with softwarequality at Avanza Bank.


The non-technical stakeholders think that the ModelDebtOMeter should beused to work with software quality at Avanza Bank. They motivate this opinionby saying that the ModelDebtOMeter makes software quality understandablealso for non-technical stakeholders, making software quality a common concernfor both developers and non-technical stakeholders, resulting in a more efficientdevelopment process.

In comparison with the quality barometer the non-technical stakeholdersthink that:

• The ModelDebtOMeter is a more complete software quality model.

• The ModelDebtOMeter explains and motivates why a value has been cho-sen for a software system in the quality barometer.

• The ModelDebtOMeter feels more abstract and less business focused.

• It feels like working with the ModelDebtOMeter will require more time.

The non-technical stakeholders think that the ModelDebtOMeter is a goodcomplement to the quality barometer.

27

Chapter 8

Discussion

The purpose of this thesis is to use Domain-Driven Design to concretize thetechnical debt metaphor so that software quality for a non-technical stakeholderbecomes visible, measurable and understandable. The ModelDebtOMeter hasmade software quality visible by extracting and showing the domain model of asoftware system. The model debt concept has not only concretized the technicaldebt metaphor but also added measurability. The concept has been tested ina working software system and the results show that it behaves reasonably inpractice. The interesting question is if model debt and the ModelDebtOMeter

has made software quality understandable for non-technical stakeholders.

8.1 Examples

Looking at the results of the evaluation, model debt as a whole is an understand-able concept. Business isolation debt and business behaviour debt was easy tounderstand even though the non-technical stakeholders thought that they wouldunderstand it better with more and better examples. Inefficient business debtwas harder to understand but here the non-technical stakeholder also thoughtthat the understandability would increase with more and better examples. Therelationship between the different parts of model debt was also easy to un-derstand but, no surprise, to make it more understandable, the non-technicalstakeholders wanted more and better examples. How should this demand formore and better examples be interpreted?

I think that this is an effect of the method used in this thesis. The model debtconcepts were not introduced to the non-technical stakeholders until the evalua-tion was carried out giving them no more than a hour to digest the concepts. Itwas a difficult task to explain the model debt concept and the ModelDebtOMeterin such a short amount of time. More and better examples would most likelyincrease the understandability but I wonder how much? Perhaps a better ap-proach would be to modify the method?

8.2 The model debt concept

The inefficient model debt was not as easy to understand as the rest of the partsof the model debt concept. In particular the non-technical stakeholders thought

28

that it was difficult to understand the concept of a desired domain model andthe way that inefficient business debt is measured. They also thought thatthe relation between business behaviour debt and inefficient business debt wasunclear. One of the non-technical stakeholders suggested that the model debtconcept should be rearranged and centered around inefficient business debt.

I definitely think that there is room for improvement of the model debtconcept. The reactions of the non-technical stakeholders clearly shows thatsome part of the concept is not quite right. Perhaps the model debt conceptshould be rearranged?

8.3 Model debt and software quality

The non-technical stakeholders strongly agree that model debt highlights rele-vant aspects of software quality. When comparing the ModelDebtOMeter to thequality barometer the non-technical stakeholders think that the former is a morecomplete software quality model but at the same time they think that it feelsmore abstract. This reveals something about the non-technical stakeholdersview on software quality.

I think that the non-technical stakeholders want software quality to be some-thing easy. They don’t want to be involved in the real complexities that existon any software project. At the same time they realize that they need someinvolvement to be able to understand software quality at any depth. Clearly,the challenge is to strike a balance between making software quality easy toexplain and preserving its key complexities.

This discussion highlights an important aspect about communicating soft-ware quality to non-technical stakeholders: the simplification of software quality.The model debt concept focuses on the quality of the domain model. There aremany other important aspects of software quality such as performance and thequality of the technical infrastructure that are not included in the concept. Idon’t think that it is possible to bridge the software quality gap without exclud-ing some parts of software quality while focusing on others.

8.4 The ModelDebtOMeter

During the evaluation, the ModelDebtOMeter was used to explain the modeldebt concept to the non-technical stakeholders by showing how the conceptapplied to the legacy system. Therefore, the understandability of the modeldebt concept is related to the quality of the ModelDebtOMeter. Not much efforthas been put into making the ModelDebtOMeter easy to understand for non-technical stakeholders.

I think that the software quality gap could be reduced further by improvingthe ModelDebtOMeter. It is likely that this could also reduce the need of moreand better examples.

8.5 Model debt and Domain-Driven Design

Eric Evans describes DDD as a set of driving principles used when developingsoftware [1]:

29

• Speak a ubiquitous language within an explicitly bounded context.

• Explore models in a creative collaboration of domain practitioners andsoftware practitioners.

• Focus on the core domain (the part of the domain model which mattersmost to the business).

Of these three driving principles the model debt concept captures the firsttwo of them. The third one is not dealt with at all. It didn’t make sense toinclude the concept of core domain before knowing if the approach taken by thisthesis was at all successful. For the same reason, DDD-concepts which describethe domain model at a more detailed level such as entity, value object, factory,repository, service and aggregate are not included in the model debt concept.

Given the successful results I think that the model debt concept could benefitfrom the inclusion of more DDD-concepts.

8.6 Conclusion

Model debt reduces the software quality gap between developers and non-technical stakeholders. I think that the gap could be reduced further by:

• Involving the non-technical stakeholders more in the model debt con-cept. This can be achieved by amortizing model debt while continu-ously discussing the results with the non-technical stakeholders using theModelDebtOMeter.

• Rearranging the model debt concept so that it becomes easier to under-stand.

• Including the DDD-concept of core domain into the model debt concept.Doing so would make it possible not only to communicate the size of themodel debt but also to communicate which parts of the debt that shouldbe amortized.

• Including DDD-concepts which describe the domain model at a more de-tailed level. This would make it possible to have much richer discussionsabout the quality of the domain model together with the non-technicalstakeholders.

• Improving the ModelDebtOMeter.

30

References

[1] Gojko Adzic. Eric Evans: Domain driven design redefined. http://gojko.net/2010/06/11/eric-evans-domain-driven-design-redefined/.

[2] Gojko Adzic. Bridging the Communication Gap. Neuri, 2009.

[3] Nanette Brown, Yuanfang Cai, Yuepu Guo, Rick Kazman, Miryung Kim,Philippe Kruchten, Erin Lim, Alan MacCormack, Robert Nord, IpekOzkaya, Raghvinder Sangwan, Carolyn Seaman, Kevin Sullivan, and NicoZazworka. Managing technical debt in software-reliant systems. FoSER ’10Proceedings of the FSE/SDP workshop on Future of software engineeringresearch Pages 47-52, 2010.

[4] W. Cunningham. The WyCash Portfolio Management System. http:

//c2.com/doc/oopsla92.html.

[5] W. Cunningham. Ward Explains Debt Metaphor. http://c2.com/cgi/

wiki?WardExplainsDebtMetaphor.

[6] Eric Evans. Model Exploration Whirlpool. http://domainlanguage.

com/ddd/whirlpool/Domain\_Language\_Model\_Exploration\

_Whirlpool\_v2010-06-19.pdf.

[7] Eric Evans. Domain-Driven Design. Addison-Wesley, 2003.

[8] M. Fowler. TechnicalDebtQuadrant. http://martinfowler.com/bliki/

TechnicalDebtQuadrant.html.

[9] Robert C. Martin. A Mess is not a Technical Debt.http://blog.objectmentor.com/articles/2009/09/22/

a-mess-is-not-a-technical-debt.

[10] S. McConnell. Technical Debt. http://blogs.construx.com/blogs/

stevemcc/archive/2007/11/01/technical-debt-2.aspx.

31

Appendix A

Evaluation Form

1. I think that business isolation debt is a clear concept that is easy to un-derstand.


What can make the concept clearer?

2. I think that business behaviour debt is a clear concept that is easy tounderstand.



3. I think that inefficient business debt is a clear concept that is easy tounderstand.



4. I think that the relationship between the different parts of model debt(business isolation debt, business behaviour debt, inefficient business debt)is clear and easy to understand.


What can make the relationship clearer?

32

5. I think that model debt highlights relevant aspects of software quality.


Which aspects of software quality is missing?

6. Compare the software quality of the legacy system as estimated by thequality barometer with the software quality as estimated by theModelDebtOMeter. What are the pros and cons of using theModelDebtOMeter?

7. I think that we should use the ModelDebtOMeter to work with softwarequality at Avanza Bank.


Motivate:

33

Appendix B

ModelDebtOMeter Screenshot

The ModelDebtOMeter showing the domain model of the legacy system atAvanza Bank and its model debt after all amortizations have been performed.All model blocks have been renamed to ModelBlock

34

Bridging the software quality gap - umu.sethe software quality gap further. Using the terminology of...

Documents

Transcript of Bridging the software quality gap - umu.sethe software quality gap further. Using the terminology of...