Placeholder Image

字幕列表 影片播放

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

Usually I title my talks because I wanna tell you what I'm gonna talk to you about

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

A2 初級 美國腔

GOTO 2014 - 不僅僅是代碼猴子 - Martin Fowler. (GOTO 2014 • Not Just Code Monkeys • Martin Fowler)

  • 86 7
    colin 發佈於 2021 年 01 月 14 日
影片單字