 And for more information, do look at the Continuous Delivery Book by Jason Dave, which is an excellent description of how to do this. OK, for the final talk of my trio, well, I don't really have a title. Well, I sort of have a title, but I like to title talks in order to tell you what the talk's about. And I'm not entirely sure I want to begin by telling you what this talk's about. I'm going to let it kind of gradually work upon you. So as we've indicated, with the success of agile and the fact that it's become more common, there's also been a lot of frustration. You talk to old agile guys who were sort of working back in the late 90s and early zeros. And they'll often say, oh, agile's hopeless now. It's become meaningless term. There's all these frustrations. And I share some of these, but I also understand that's the consequence of agile being successful. And the good thing about agile success is it means that people like myself and other people who want to work in an agile fashion can do so with a lot more freedom than we could back in that time. And one of the examples of where this has helped us is we've moved away from a situation where you have to come up with some big requirement specification document and turn that all into code in one go. We now found we can actually break this stuff into chunks. And by breaking it up into chunks and delivering individual bits of functionality at a time, we get the ability to get a greater visibility. We're able to see where we are much better. We're able to change direction, steering our progress. And that is all good stuff. I mean, that has helped a great deal. But where I'm a little bit frustrated with where things go really comes down to this direction of this arrowhead here. There's still a notion in a lot of teams that the role of the programming and the development team is to receive information, receive requirements, even though they're in little chunks and then build them. We've both echoed this so far. I talked about this a little bit in the shift from two-star to three-star fluency. We need to change that relationship a bit. If I wanted to kind of give my sort of very simplified view of how this kind of stuff works, I think of three roles, users, analysts, and programmers. I say these are roles, not necessarily people. You can combine them. They're often separated, et cetera, et cetera. Users have needs, things that they want. But they can't express these things directly. They don't even, they couldn't tell you what they were. It's the old phrase, a user can tell you what they want, but they can't tell you what they need. And what you have to do is to give them things that help with their need. So the role of the analyst is to kind of look at those needs and then come up with statements of intentions about what the software should do. I'm trying to get away from the requirement word here, use intent instead. Typically express the stories or features or some things of that kind. And often the way this goes at the moment is that these intents are delivered to the programmer. The programmer creates the code, the code goes to the user. And we have, I said, this one-wide arrow of movement. The frustration is in that direction because when we look at many people who were involved from Agile from the beginning, they said, well, no, what we want is a system where the programmers are also involved in coming up with these intents. Because the thing about software developers is they know what software is capable of doing. They get deep into the domain. They understand what the software can do. They understand what possibilities are there. They can often come up with very good ideas. And it should be a collaborative process between the analyst role and the programmer role to come up with what are good stories and intents. And that is part of this freestyle shift. And it's part of where things really ought to be. I think of this as the case of conversational stories. The term conversational was actually one of the candidates for the word we used Agile in the end. But one of the suggestions was conversational. We think of it as a process where people are involved together collaboratively. But if we're to do this as software developers, if we're to actually come up with helping, with creating these, we need much more knowledge about how the domain works. We need to take on that understanding. And it's a frustration that I've seen with teams, even with fairly good teams, is that often the programmers themselves don't want to understand the domain. I remember chatting to a friend of mine who was doing some really interesting work in gene sequencing. And when he got into that project, he started cracking textbooks on gene sequencing and studying the domain. And he was very frustrated with other programmers on his team who weren't interested in understanding the domain. And I find that always very odd, because the reason I got into software in the beginning was because I thought understanding software would give me a way of understanding how the world works, how businesses work, how domains work. And when working in somewhere like health care, which I worked for a while, I really wanted to understand what was going on, how the doctors did their things, what the medical background was to the stuff I was supporting. To me, that was the fascinating stuff. The software is kind of boring. And I still had to have that in a way, even though I've gotten into this weird state of being a software guru. Actually, the writing of the software is not anywhere near as interesting as what the software does and how it enables people to do things. And so that means that we as programmers have to become, at least to somewhat, think about those things that the analysts do to understand domains. We have to understand how to study the domain, how to talk to users, how to get an idea of how to process and participate in that. We may not participate to a degree but a full-time analyst would if you have such an animal, but we can't ignore it either. We need to have some involvement in there. And often it's organizational pressures that prevent this, but often it's also our own intention. And it's things that we can change and push the shift. So if you wanna push on and overcome some of the frustrations that we, all the agile people are having with the current state of the agile world, start thinking about how can I be a more active role in understanding and working in the domain that I'm at? So knowledge is an important part. But also, if you really wanna have an impact upon the domain and take this shift to, I think, a better way and a more agile way of working, there's also responsibility. You have to become responsible for what's going on in the software. What do I mean by this? I'm gonna give a couple of examples. How many here have come across the concept of dark patterns? Anybody? Just one or two. So there's a website out there, darkpatterns.org. What it does is documents the way that software can manipulate its users to doing things that are not in the user's interests. So it might be the little statement on a web form that sort of implies something that's not there, that's not obvious. You think of a web interaction that says, you know, sign up for our particular subscription deal, get a first month at half price or three or something like that. And somewhere there's a little bit of text and perhaps a not very clearly worded bit of text in a checkbox that says, well actually what you're doing is signing up for a monthly subscription that automatically renews. And what's more, we don't tell you how to cancel it. It's really hard to figure out how to get that. That's a manipulative business process, right? That's trying to trick people into wrote the code to do that. And that programmer is every bit as liable and culpable for writing that code as whoever it was who gave them the specification. If we are to take an active role in thinking about our domains and working to improve the life of our users, we need to reject dark patterns. We are responsible for what we code. Even if those ideas are coming from elsewhere and we need to become advocates of our users to say, well if someone's saying pushing dark patterns at us, we have to push back. We are in a very privileged position as software developers. We have very comfortable jobs in nice air conditioned offices. Even in India, the software developers that I see working in India are much better off than a hell of a lot of people in this country. That's true in America as well. Software developers and on top of it, it's relatively easy to get jobs. People are crying out for software development talent. And if you're a talented software developer, you can find a place. And that means you have a responsibility to use that talent well. And if an organization is saying we need to introduce dark patterns as part of what we do, you need to reject that. And I think if necessary, you have to reject that to use a phrase I've used in another context by saying to yourself, I need to change my organization or change my organization. Because you do not want to be liable for dark patterns, either morally or legally. I personally think that any programmer who puts a dark pattern into their system is should be legally liable for the consequences of that and should be sued if necessary. Not gonna make me very popular amongst programmers, but that's my view. Another example of where we need to be user advocates is in the storage of data. Particularly with the growth of big data and things of that kind, there is this notion that says we must store every bit of data about what our users do. Every mouse click, every time they, you know, to make sure that we've got our little tracking devices and track all their movements. And we store all that stuff. But as we store it, it raises questions about what that means. Who gets to look at this information? What are they gonna use it for? Who can get hold of that information? Who we don't think so. And we've all seen the revelations about how intelligence organizations are hacking into computer systems to get hold of this kind of data. We know that criminal operations do and we've all seen stuff about criminal stuff hacking in and getting that data. But there's also a responsibility on us. We put the data there in the first place that allowed it to be got at. Are the measures we can do to protect that data? We should be responsible for making sure that data is properly encrypted. And also for questioning whether we need to store a lot of data. There's an attitude that comes under a German term. It's not easy to translate into English so I'm sticking it in the German called Darten-Speisenkite. And it says, be sparing about what data you store. Only store the stuff you need to. Question, particularly anything that's of personal identification value. And either be very careful with it or separate it or not store it at all. Because when you're hacked, and you probably will be, you've gotta think of what the consequences are of that data getting out when it does get hacked. And again, it's our responsibility as software developers. We're the people that understand what this data means and what it does. We understand how often easy it is to get at. We have to take a role in saying, we have to think about this. Because we are morally liable for that data if it gets into the wrong hands. And we ought to be legally liable as well. So again, we need to take a role in advocating Darten-Speisenkite. So I've presented this kind of map of users having needs, analysts coming up with intents, programmers coming up with code. But there's another element to this map that also impacts on our responsibilities as programmers. And that is, what impact does the user have on the world? What are our users doing that our software is helping them do a better job of? I must admit that at this point in my life, I'm a little bit ashamed of my generation. I'm ashamed of the fact that so many people of my generation that are bright and talented and have huge amounts of opportunity have done things like going into fancy Wall Street derivative trading and high frequency trading activities that I can't see have are actually making human race better off. I think we need to think about eyes of the software we're working on improving the world around us. We need to make a judgment about the impacts that our software has. Now, in doing this, it's important to stress that a lot of people, when they think, when I make this kind of argument, then say, well, you're saying that the only worthwhile software work is to be something to help feed starving people or something of that kind. And it's what we want to do is see more work through charity organizations and things of that kind. But that's not true. It was summed up to me really nicely. I gave a talk that touched on this and somebody came up to me afterwards and said, I don't work in a sort of socially responsible fielder at all, I just write printer driver software. And the guy behind him spoke up before I even had a chance to answer and said, but printer driver software is useful. I've had to buy a house recently. It was really helpful for me to be able to print out all the forms on my printer rather than have to go through a long complicated bureaucratic process. My life and the life of many people is made better by having printers. It's our day-to-day work that we should judge and say, is our day-to-day work, the stuff we're spending eight or plus hours a day, making people's lives better? And it doesn't necessarily mean it makes it in that kind of very visible NGO style thing. It can be as simple as it makes printers work better. I mean, my life has been hugely improved by all sorts of little things that go on out in the world, most of which were done for profit. It's perfectly okay to make money of providing stuff that's useful. This is a question I ask about my own work. I mean, I write about software development. Is that a socially useful activity? I personally believe that it is because I think if I make software developers more effective and more productive, they will make software that goes out and makes things better across the world. But we all have to ask these questions for ourselves. And what I'm not saying to you is, you're bad if you're involved in high-frequency trading, although you probably are, but I'm not gonna say that. That's not the point. The point is you need to step back and reflect and say, how does the code I'm working help my user affect the world? And is that a good effect that it has? And if it is, do more of it. And if it isn't, ask yourself again, is that the best use of my talents? The talents that I was lucky enough, privileged enough to be able to have and to be able to take on. Now, in this I've talked about the role of this, but I wanna finish by saying, well, there's another area as well. And that is, how do we, as software developers, and the code that we write, have an impact on the world? And there are two areas that I think are particularly important about this at the moment. Two topics where we, as software developers, are making a big impact that we need to think about. And this is, for us, overall as a profession, not necessarily within our daily work, but within our overall way of thinking. The first is, I think there is a real challenge at the moment about the future of the internet and the role of privacy on the internet. Again, I'm alluding to the things that we've seen through governments and the way in which they're using the internet as a mass monitoring and surveillance tool. I think we, as software developers, have an important role to play in educating people about what that means and why, certainly, I feel it is a very worrying theme. And we also have a role in trying to combat it. Many of my colleagues now are spending time doing some open source work to try and improve the privacy on the internet by trying to make email transmissions default encrypted, because if everything is encrypted, then it's harder for mass surveillance to focus on the things that they want to focus on, at least in an undirected way. At the moment, if you want to send encrypted emails, it's actually quite hard. The user experience is often the biggest part of the problem. You can do it, but it's a lot of work. That needs to be changed so it becomes straightforward. There are lots of ways that we, as software developers, I think can do things that help to do that and make the internet privacy and provide that. I think this is one of the great challenges that we have at this point in our time. The other one, but is also a big deal, is what I refer to as the alienating atmosphere, but hangs over the software development world and more broadly in the world against many historically discriminated groups. The most obvious example of this is what happens to many, many women online. It's not difficult to go out and look at the internet and see cases where a woman has spoken up about some kind of discrimination that she's run into or things that have become a problem for women in the software world and then get completely dumped on by really obnoxious comments, emails, tweets and things of that kind. That creates this alienating atmosphere that pushes women out of the software profession and I think is part of the factor of why there is such a worryingly small proportion of women in software development. And I use women as an example, but it's also true in lots of other places and lots of other ways. And there's also a similar, this unreasonably small level of black developers in the United States for instance. And I think it is our responsibility as programmers to push back against that atmosphere to say what are we doing that helps create that alienating atmosphere? How can we prevent it? How can we reverse it? There's a standard that was very eloquently expressed by all people and generally in the Australian Army who said the standard you walk past is the standard you accept. So if you see somebody else doing something that creates this alienating atmosphere and you don't act to prevent it, that's effectively accepting it and that should stop. I've talked about that in terms of the software development world, but it's also the broader world as well. There was a horrible campaign in Britain where a whole bunch of internet intermobbs descended upon a woman and made rape threats and death threats to her because she thought that one of the people on the British currency should be female. Now that I'm not saying is necessarily our profession's responsibility directly, but one of the things that happened was how do we prevent this kind of stuff? Well again, we're problem solvers. How do we prevent this kind of intermobb behavior occurring? What measures do we need to take in the forums that we create for discussion to discourage us and prevent that kind of alienation occurring? We have a responsibility to think about that and to solve those problems. And these are, as I said, for me, two that really line up. Now what all this boils down to is what is the title of my talk? The title of my talk really is saying we should change our attitude about how many of us think about what we do. A lot of us just think of ourselves as passive programmers. Somebody tells us what to do, we code it up. Or if we're a user experience people, we come up with a good user experience for it. I focus on programmers because that's me. But it's true across the profession. I think we should change that attitude. I think instead we should say to ourselves we are intelligent, well educated, fortunate people. We should have an impact on the world. We shouldn't be passive. We should say we can make an effort to make the world a better place. And we ought to go ahead and do that. We do that in our daily work by getting more familiar with the domain. We campaign against bad things, becoming advocate for our users. And we work in a more broader structure to say how can we make society better? That is a responsibility that comes on us because of our fortunate position in the world. And we should take that responsibility and push it forwards. And I realize that's way broader than just the agile world but it does have its heart in the agile thinking that people started at the beginning. And I ask you to say to yourself, how can I be that more active part in the world and change the way in which programmers interact with the world? Thank you.