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...
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.