Usually I title my talks because I wanna
tell you what I'm gonna talk to you about but here I wanna kind of go in a
little bit of a journey with you that's not gonna necessarily....
I don't wanna tell you where we are going so as a result there's no clear title,
but the journey begins with one of my big frustrations with
agile software development I mean, the agile revolution
has had a big impact and it's been remarkable and
very gratifying to see the impact it's had But there have been frustrations And there's one particularly
big frustation that gets at me Now, one of the benefits of agile it's in the days before agile thinking we had this notion that if you wanted to
build software you have to come up with everything you wanted done put it together in some great document
and sling it over and build software. And we know how well that worked. and it's very good but the agile world
next splitted things up breaks things down into independent
little units of capability often called stories and then build
those stories one at the time and by building the stories one at the
time we get a lot of benefits: we're able to get
feedback as to where we all going, we're able to see our progress and in particular we're able to steer,
we're able to change direction as we learn and that's of course a vital part of what
this whole thing is about but there's still a problem here and the problem is that arrow there.
The notion that the stories are given from some kind of Business
Analyst kind of role handing then to developers to code up but the development team ends up being a
passive recipient of stories and I come across this great deal
in different places both in Thoughtworks and outside where developers basically see
themselves as we're an engine to turn some stories, maybe some rough
tests, into actual code. We build whatever we're told to build, we
don't really get involved in thinking about what it's will to
the building. And this is very much against the
idea that was at the heart of pretty much all of the agile founders. If you get a bunch of people from
Snowbird together and you say What do you think, that, you know, that developers should be just building
what they were told to build? They will be horrified! And... when we were coming up
with names to agile... hmm... Kent suggested because at the time we didn't have
the term agile software. We needed to come up with
what word we use. We ended up picking agile, but one
of the suggestions that Kent came up with, was the word conversational, because he
thought that the essence of this approach was these conversations
between the development team and the business people about all aspects
of software development including what should be built. And the idea here is that developers and analysts should collaborate together to decide what stories should be built,
instead of the analyst feeding stuff, or the business, feeding
stuff to developers, it should be just too, I think. And a little example of this. I think illustrates it quite nicely.
There's a story and this isn't gonna story from Amazon
where one of the developers thought that would be a really good idea to, when people are working in the
shopping cart, to put 'you might like to buy so and so'.
You know, by analyzing what they've bought By analyzing all the data that they have,
some suggested items that you might wanna add. And the businessperson involved
said 'no, no, we don't do that because... ...we don't want to distract people while
they're shopping in shopping carts, right? Because, you know, what is the most
important thing for Americans? Shopping, exactly, so you know,
'focus on the shopping cart!' Now, this being Amazon, the developer said "no i think he's wrong" and so he actually
built a version of the shopping cart with the suggested things in there
and ran A/B tests. And was able to prove,
by looking at the numbers, that it increased revenue.
And being Amazon, that you know, businesspeople said "well, yeah, we can't
argue with the numbers", so they carried on doing that. And now is
that notion of collaboration. As software developers we are familiar with the software world
and what software can do which means we can come up with ideas. There's no rule that says all the stories
need to be developed by the business. It's true I think that they should
prioritize them And they should have the final sign
what gets built in what order but the ideas that you come up with,
are often based on collaboration. I remember a story of,
an early ThoughtWorks project, where we're doing some stuff with the database and they did a little demo early on in the
process, and that was just showing all we've got this information in the database.
And they were showing the customer and the customer looks at the data and said: "Hang on, if you've got this data there, could you answer these questions for me?" And they had a conversation and
the developer was thinking SQL queries, and the business person was
thinking business process and they figured out:
yes they could do this. And he said, well I've never asked this,
but actually if we could build this, which seems to be trivial, that actually justifies the entire
cost of the project right there. I never even thought of coming up
with that requirement only in the conversation did it come
together. And so, conversational stories, the idea that we should work together
and collaborate to come up with what we build is a fundamental part I think of what
agile ought to be about. And that's, of course, the whole notion of
things like monitoring and AB tests. We begin to explore what should be built
by actually watching what people do. That's, I think,
a really big step forwards. But in order to do that,
it's important that developers get a better knowledge of
what the domain is about. Because that knowledge is vital
to be able to do this. And this is one of the areas
where, I think, we've been a bit disappointing
as a community. In that we haven't put enough effort into trying to know about the
domain we work with. I remember talking to a friend of mine who
was a project lead on a team doing some really interesting scientific work
around genetic modeling and he was very disappointed that most
of the programmers on this team weren't interested in finding out more
about the genetics. They weren't interested in the science,
they just wanted to be told what was built. To be really effective as a software developer,
I think you need to understand that domain, get to find out how it clicks
and how it works, become knowledgeable in that domain, and then, you can really influence what would be
the most useful software to build in that domain. You'll never gonna know as much
as the expert in that domain. When I worked in health care,
you know, no one's gonna ask me to become a doctor just because I've done some
computer work in the area but that knowledge I did have
was very valuable in collaborating over
what to do in terms of the software. And in fact, when people
come to me for career advice and they say, "should I learn
Scala or JavaScript or Clojure..." I say well it's less important
about learning about languages, they come and go... Learn the domain that you are working in. and they are not really that different
when it comes down to it. That is a very useful skill, and even if you end up moving to some
completely different domain later on, the knowledge of how to learn domains
and how to work with them is gonna be something that's
gonna be really valuable for you. And as well as knowledge, I think that also brings in another thing,
which is responsibility within that domain. And here, I wanna bring up a topic
that you might have heard of. something called "Dark Patterns". "Dark Patterns" is a website that it's really about help people
use the user interface. encourage users to do things that are
actually not in their best interest Simple example of this: imagine again with shopping cart, we are
buying some electronics items, you know a new camera or whatever. And the people who run the web site
say, "oh, he's bought a new camera" Well, I know what I'll do, I'm gonna
put insurance for that new camera and I'll put it into the shopping cart,
automatically. The user didn't ask for it, They weren't offered a popup that says "do you want insurance?" So user says: "why would I buy insurance
on something I can afford to replace?" "This is just a money spinner for the
retailer, isn't it? No." No? What instead they do?
Just pop it in a shopping cart anyway. Now of course I might notice that
shocking item in the shopping cart and remove it, that's perfectly okay,
they make that possible. But they've put a thing in the shopping cart without asking me deliberately. Now that is manipulating
a user to doing something that's not probably in
their best interest. Similar thing is, if you
have something where, "hey, sign up for free!" And then I have this recurring
30 dollar-a-month billing thing and they make it really really
hard for you to cancel. You know, you got this form and that form and you know, half of the time
you hit the button submit button for the cancellation,
you get a 500 error... I mean, that is often bad, and
sometimes is done deliberately. Those things are dark patterns,
and I think, we as programmers, have got to make explicit
the active rejecting this. We need to be advocates for our users. And my point here is: If you write code for that dark pattern, if you wrote the code that slips the
insurance into the shopping cart without the user asking for it. You are every bit as responsible as the person who asked you to do it. We are responsible for
the software we write, both good and bad
of what goes in there. Now I'm not necessarily saying,
you know, if somebody asks you
to do something like that you should automatically quit your job,
otherwise you're a bad person. You know, I know everybody has to
balance a lot of things in their lives and all the rest of it, but you are responsible for the
decision to write that code and you have to balance that
responsibility across everything else. Too many developers take the
point of view which is... ...it doesn't matter what I code,
I just follow orders. I just code what I'm asked to do. I don't think that is good enough. I think it is important that we,
as developers, say what we do is something that
we're responsible for. We have to take that responsibility on. So, dark patterns surfing
an obvious case of where we have to think about
ourselves differently, and say: we need to be advocates for our users. But I think even goes further than that. I mean, so far I've talked about a
relatively small world of users and analysts,
some programmers... developing software,
coming up with things... But, of course,
that software and our users are making an impact upon the world. And we're also,
in part degree at least, responsible for that impact. We have to say what impact is our software
having on the world around us. And that can affect, again, what we choose and where
we choose to work. In my younger days I spent
a bunch of time working in healthcare and I had the chance and did some
consulting work in the City of London, in the financial industry. And I was quite keen to do that, because
financial industry is quite interesting. You know, this weird
financial products intellectually interesting thing to work at. But having worked there for a while, I realized I didn't wanna work
in that kind of place. Because I didn't really feel that what
they were doing was giving value to the world. You could tell it from the way
they treated their customers. As far as they're concerned
that customers were a little bit more than just people
to be taken advantage of, you know, what thing we sell them in order
to get some commission for us. There's never any thinking in their heads as to easy actually gonna be good for
them. Very different when I worked
in the health care area where the doctors and nurses I talked to were very much concerned of what was
in the patient's best interests all the time. So that led to a reaction
from me that said: "No, I don't think I want
to spend my talent... ...supporting an industry and activities I
don't think it's beneficial in the world." Now we're in a privileged position
in software development. Now we have comfortable... We can fairly easily get
comfortable jobs You know, without any danger involved. We're not going down mines or
packing meat or anything like that. We're not likely to be,
do physical harm to ourselves. If it might be a little bit of our side. Which is actually not
something to trivialize but... ...it's a hell lot better
than chopping your arm off. Well, I mean, that's what happens in
a lot of meat-packing areas, particularly in the States. You know, we get well paid
for what we do. And I think we have a certain degree of
responsibilities, say: Where are we gonna apply our talents? Because, in the end, we are
responsible for using our talents to, hopefully, make the world
somewhat of a better place. Now I'm not necessarily saying
everybody should stop what they're doing and go build hospitals in India
or something of that kind. But we should say:
"Is what we are doing useful?" I got barely on this talk once, and somebody came up to
me afterwards and said: "you know, it's very tackling what you're saying,
but, you know... .. I'm not doing sort of any
particularly socially useful work... ...I just build, right, printer software." Before I could even answer,
the guy behind them said: "yes, but printer software is useful.
I just had to buy a house... ...it was really useful for me to be able to print
out all the forms for that house, on my printer... ... that saved me a lot of trouble,
it made the whole process a lot easier." You know, something as
humble as printer software, is valuable stuff, right? It's an useful thing that
makes people's lives better. On the other hand, if you're
writing a software that says "I'm gonna say that we've run out of ink
when we've still got a quarter ink left." That's a dark pattern by the way,
then that would be about fake. But the point is you have to
say, you don't have to be... ...contributing to a charitable
cause or something like that... ... to be making the world a better place. But I think it is important for everybody
just to reflect on, you know, how is the software I'm writing
having an effect on the world? Is it good or is it not? And we all make individual decisions about what things we would support,
and what things we shouldn't. But what is common across all of us, is we have the responsibility, We fought, we take the responsibility for the choices that we make,
overall in our careers. Well, the last area that
I want to talk, to say, bring up this responsibility thing, is... ... the very big picture. What impact is all of our software, and our programming and our profession having upon the world, in aggregate. And there are two areas where
I'm really concerned about this and where I think we, as a profession, need to work much much harder
to improve things. The first of these is
the alienating atmosphere that exists and pushes many people away both from our profession
and from using software. The most obvious example
of this is the fact that, all you gotta do is look around
this room and say to yourself: "Hmm, there aren't many women here rather." That is not a good sign. I mean, we, when I got
into the software industry, one of the things that appealed to me
about the software industry was the notion that it was
a meritocratic world, right? It didn't matter the fact that
I come from a working class family in an industrial area of Britain,
you know, and I wasn't, you know, I had a fairly good
education, but, you know, wasn't brought up with
the refinements that you know, somebody
more up-class would have. What matter is:
"can I produce good code?" You know, that meritocratic
quality is a nice thing and it will be a good thing to see
it more broadly in the world and less emphasis on inherited
wealth and class and status and more emphasis on what
kind of good work you can do. But any statement that
the software industry is a meritocracy,
is rather undermined when fifty percent of the population is
so severely underrepresented. On top of that, that means that there's a lot of really good talent that we're not getting into our profession, which is a terrible waste both for our profession, and especially,
for the people who, otherwise would have a good, would have been
able to take part in what we do. And it's particularly compounded
by the fact that a lot of the people that are pushed away from our
industry, are people in groups that have suffered hundreds
of years of discrimination. And that's true for women, it's true for Afroamericans
in United States It's true for a lot of lower
cast people in India... It varies depending on where
you are in the world, as to what groups tend
to be pushed away, but it's common. And we have to fight against that. I mean, you can't not look at what
goes on in the web at the moment without seeing many cases of
where groups are pushed away and alienated,
and we have to fight against it. And it's something we all are
responsible for doing. The fact that we ourselves, individually,
might not be acting like jerks, doesn't mean that we can
just ignore the problem. This is phrased by an Australian general made famous through a Youtube video, says: "The behavior you walk past
is the behavior you accept." And I think that is very true. If we allow people to be folks on the Internet,
and push away various groups, we're, in the end, complicit. So we have to figure out how to stop that. And that's not just within the professional world. That actions also in our software. One of the big problems that people face is harassment, for instance on Twitter. And it troubles me, that the engineers
and the data scientists at Twitter haven't found ways to try
and reduce that harassment. I mean, we can come up with all sorts
of clever ways of targeting advertising Why can't we use at least
some of that brain power... ...to figure out ways of
preventing online harassment? We should do that. That's my first issue We need to do something about the
alienating atmosphere around in our industry The second issue is privacy on the Internet and the fact that we need to act to ensure that we have a free Internet where we people can collaborate without fear of persecution by governments, or tax by criminal groups, etc. etc. I'm not gonna say much more about that now, because is a whole talk that I'm
gonna give with Eric later on in the "Defending the free Internet" section and please come along to that if
you want to hear us going a lot more detail about why
privacy is important all of us whether we think we have
nothing to hide or not and what we can do about to fix it. So, let's come back to this question: What's the title of this presentation? How do I sum all this up? Well, basically all I've been saying
in this last 20 minutes it's... we won't, we don't think that we as developers should be just
code monkeys bashing out code. We should be a profession, just as doctors are a profession or lawyers are a profession and we should look for that kind of status in what we do and we should also
take on the responsibilities that that status implies. That means we must engage with the world, reject this stereotype of software developers being people who live in basements and they just fed pizza under
the door every so often, and say: "No, we can engage with the world, we can help steer the world
in a better direction." I mean, our software does that anyway, but often does it without the developers
playing an active role in that. I think the developers
should play an active role in that we all bright people,
we are well educated, hopefully have a sensible view
of the way the world should be and potentially can act as leaders
as to help the world can be run better. But in order to do that, we need to take the responsibility
to step up and do that. And my request to you all, is to think about ways
in which you can do that. Small or large, individual or combined with others. But taking that responsibility and acting as leaders in the world. Thank you.
"We are responsible for the software we write." I think it's important that an influential figure like Martin Fowler focuses on the ethics of engineering. Also see: Software Engineering Code of Ethics and Professional Practice