I think my talk will be a little bit different compared to the other talks because I'm not talking about one particular research project. The content of my talk is based on a special issue that a couple of colleagues of mine and I published last year which was on value and waste in software engineering. So in this talk I'm going to present some of the research presented in papers and I also try to explain why we should care why it matters. I think I will stay rather at a high level but I include a URL here so if you're interested in the details of of the work that I'm going to present you can go to the URL and all the papers - they should not be behind a pay wall so you should be able to read and go into the actual technical inquiries of the actual research. If you can't remember the URL I also included it in the footnote if you want to refer to it. Okay but what's the big picture - what's the maybe motivation for my talk. So well we have value and waste but in practice it may be challenging to really think about value and think about waste and think about how we can reduce waste or how we can increase value if we don't really have a conceptualization of these terms of these ideas. So this is what I want to do - to think about well how can we conceptualize waste how we can reconceptualize value and then use these more concrete definitions to actually proactively address value and waste in development. So to start off so one paper that actually did not appear in this special issue but I think it is still relevant is a paper that presents some research that looks into what actually is waste and for each of the findings I present also at the bottom the source of the evidence, so if you wonder well what is the space on what I'm going to talk about and there is a brief summary in the blue boxes at the bottom of each slide. So there was one study that looked into, well, what is waste and it came up with a definition of waste in software engineering and also nine categories of waste including their cause. So why do we even have the types of waste and I will refer to some of these types later on. But well you may wonder okay what's the point of of knowing this. Well, if we know these points or if you know these types of waste we can actually talk about them in our team we can actively address them and maybe consider them in our planning in our projects in how we design and develop software. So let's have a look at the first waste-related issue here. So code reviews, I think a lot of things have been written about code reviews a lot of blogs out there a lot of people have opinions about code reviews and I think there will be some more talks also in the context of this series of talks about code reviews. So we do actually know a lot already about code reviews, so what I would like to highlight in the context of waste is that bad code reviews can be a source of waste and to address this or to mitigate or to reduce waste in the context of code reviews, well, we can actually look at what makes a bad code review. And there is a lot of empirical evidence out there about what is classified as a bad code review and well this study, it identified so-called review smells, for example lack of review or "looks good to me" which means reviewers don't really review the code in the first place or they just reviewed superficially which could then lead to the waste of rework, that we need to later need to go back and rework what we have done in the design of the code. Review buddies is another review smell which means that we just ask our friends to review our code, maybe just the people who work on the same parts of the code so there is not really a knowledge sharing going on or code review doesn't really help knowledge sharing with a team. There are some other reviews like ping pong which then leads to in efficient communication when the reviewer and the author of code just go back and forth to discuss the code. Or sleeping, which is a interesting smell, which means that the reviews are not even replying so it's another source of waste because we have to wait so the developer who wrote the code needs to wait until the review comes back and the two remaining smells would be, well, we have large change sets so for example the amount of changes in the code that we have to review is very large or we've simply missed the context of the change just made to the code that we're going to review which then could lead to to to a very high cognitive load and again in the end probably a waste of time in the long term. Now again the question is why does this matter? Well, if we are aware of these types of smells we can actually plan our review activities - we can communicate expectations for code reviews and we can even use these anti-patterns or smells of reviews to train new reviewers in our organization. 
Okay let's stay at the code level another form of waste I think is technical debt, and again a lot has been written about technical debt but one question that often or actually I think always comes up is, well, what do we actually fix? How do we fix it and who should fix it? 
Well, this contribution to this special issue we published found that not all types of technical are actually fixed the same way and some types of technical debt are fixed by those who introduce them and some types are fixed by other people and some types of technical that maybe are never fixed okay what can we do with this well if we know that some types are less likely to be self-fixed. So for example design debt we probably need to come up with dedicated activities or maybe dedicated maybe time in our development to fix these types of technical debt. For other types of debt, for example code debt or defect debt it's often the developer who introduces it then also fixes it. So for these ones we may actually not plan fixing initiatives or fixing activities. Also, well, what can we draw from this is that when it comes to types of technical debt that are not self-fixed we probably need to assign them to people - to dedicated people - and this research argues well design debt for example we probably should assign it to more senior people because those who introduce design debt if they are junior ones they're also often not really interested in fixing it in the first place. 
Okay so these were two examples and the last the third and last example is a little bit different and it looks at what value but it looks at value from a different perspective. It's not about value in terms of money or value in terms of features or value in terms of time we save but it's value in terms of human values and the question is well how can we integrate human values in software because as a responsible professionals or as software developers we should not only make sure that we build software that is useful for our clients or customers but we also should build systems that support or at least do not violate human values. Now there are lots of literature out there on human values and taxonomies, definitions, but it might be quite difficult for a software engineer or software developer to understand, well, how do I translate human values into something that we can represent in code? And this is where this contribution comes in - this paper at the bottom - because what this paper tried to do is, well, it looked at how human values are discussed amongst developers of software projects and then it tried to come up with conceptualized descriptions of these human values so that they are more actionable or operational - can be operationalized by by software engineers. So just to give an example for two human values - I mean, there are more - I just put two examples here, dignity and inclusiveness. So they could be conceptualized into for example a dignity into maintaining honor and respect for users and once we have that contextualized description of that human value we can then go one step further and define actual requirements. So for example based on this description we could think of, hey, what what kind of user information do we keep in our app, how is it shared, how can users unsubscribe, do users have ownership, for example about their information, so then this high level, maybe abstract, concept "dignity" which maps to human value becomes something much more concrete. And the same for inclusiveness: so what the research found is we can translate inclusiveness into facilitate different origins languages cultures and knowledge and then based on that we can go one step further to come up with complete requirements or constraints for our software. 
Okay so that's all I wanted to talk about, just to summarize, we do already know a lot about value and waste and in this talk I just wanted to give you some examples and, well, what are the takeaways? Well we know a lot about review smells so why don't we use that knowledge in order to plan our reviews, in order to train maybe novice developers or in order to also communicate the expectations about reviews within our organization? When it comes to technical debt, well, we can use our empirically grounded knowledge on technical debt to decide how to fix it and we can decide what kind of activities we focus on. So for example if for whatever reason we would like to have - we would like to spend a day or two on fixing technical debt, it's probably better spent on fixing design that then on fixing code debt because code debt tends to be fixed well fixed by developers. And the last but not least, when it comes to human values, well, we now have a contextualized description of human values and we can use that to identify more concrete product requirements and in the end to build a responsible software. 
Yeah, so if you have any questions feel free to email me or if you want to know more feel free to email or just leave a question with Mike, and, yeah, that's all I had for today.