What went wrong with the IT-industry? - James Coplien

[Music] [Applause] so usually my Colusa invites me and says you know come and talk about something but this time he gave me an assignment and said don't you come and talk about you know why why we haven't are still failing so badly as an industry so ok that's what I'll talk about here today so I actually found someone who had had found something I had said many years ago and translated it into Swedish with a slightly different twist and it comes out like this so so if you go from state you know sick and that's the title of my talk that the way that we're gonna make progress as an industry is through insight not opinion and the main upshot I talk is that the reason we're here still after 50 years is we're an opinion driven industry so I'll work up to that I mean at some level the the reason that we're we're still here oh by the way there's an emergency um at the end of this you all need to change your passwords so when I'm done well you're all good and change your password so right now I need you to think up a new password if they have something to write it down with write it down not a real password I'm not gonna ask you to write down a real password but think of think up a password ok everyone got a password um I will come back to this so ok Michael gave me this assignment you know why is the IT industry broken the IT industry is more than 50 years old and still what we're unable to deliver what the user needs at the right time so that's what I was asked to come and apologize for and say you so and explain why and the answer is because it's complex and the complexity is essential complexity it isn't just because of the method we use it's not just because of we using the wrong tools it's essentially complex now the methods and the tools add to this and make it even more complex but even with the best tools if you look at the Canadian framework can even framework says that in complex things you cannot predict and so we deliver late we deliver the wrong thing so thank you very much that's the yeah [Applause] let's you get when you ask to give me an assignment right but let's explore this a bit this is I got to thinking about this and it's kind of interesting story here you know we're not alone in software so I mean we keep beating ourselves and say I mean look at Toyota their eyes building things on time look at look at manufacturing look at building well construction the construction industry sixty percent of products are late this is a survey found done in the UK there's a lot of pressure from growth if you're a weatherman what are the chances you get the rain forecast right for more than nine days out you're in wrong nineteen percent of the time in online departures how many of you fly a lot I mean how hard can that be I know I know I know you're just unlucky right um you know what some get it right we'll come back to this this is kind of interesting pregnancy's how many of you have been pregnant forty percent of predictions of when the mother will deliver our what more than one week earlier late so doctors which we hold to be at the apex of science and use of science can't get this right I mean we're still back in the Middle Ages and looking at goat entrails and stars in the heavens to figure this stuff out and by the way adding workers doesn't help software we're about 33% of the products are late so about half as much in the construction industry and the overrun is about 30% of the schedule this is from a survey that was done by version 1 by the way you can find numbers that would say anything you want them to if you look long enough on the web and version 1 is probably not that the first place I would go looking these are numbers from 2015-2016 I don't mean they're in this twenty thirty forty percent range by the way paid political announcement if you ever have any if you ever hear anyone is quote statistics like this from the Standish report it's all crap and I mean what it is there's a bunch of self-identifying failure self identifying companies who have signed up because your projects failed and they've contributed their data and the data that they're getting for these analyses are from failed projects so it's not typical data and there's a lot of critique of this has been published out of the similar Center by I can't remember his name now of the similar center and also so on there's nothing here as far as I know from the the standards report now we you know we have a lot of ceremonies and you know if I if I just do TDD or if I have a code review or find you scrum and there's all these things we believe and we have all of these rituals and things that we believe if I just do them right again it's just boudu and I mean we really know why we do this stuff and that's my whole point and we shouldn't be surprised that it doesn't work because the things that we're doing have absolutely no rational basis and I hope to show you this in the talk and you know how many of you call yourselves computer scientists and it's more of a kind of an American thing so you know or you say you're you someone asks you what are you doing I'm an I'm an ETA right I'm in computer science it's not a science there is something called computer science but when's the last time you had to solve the halting problem or the the girl completeness theorem able to do a program I mean no one no one does science its food ooh it's a black art it's least in art so I'm speaking of Voodoo don't got that password in mind so how are your passwords kind of look like this I mean you have an uppercase letter and a lowercase letter and you have a bunch of digits I'm a special character how many of you thought up a password that was like that why my mother made me do it who is the American comedian the devil made me buy this dress yes okay Flip Wilson but why else I mean even there's this relative minority of sites that really enforce things at this level some of them are really gonna tour Coney in but the rest of us kind of believe that it's it's safe if I do this it's going to be hard to guess ha you can't guess I have this special character here how often do you change your password every every yeah preferably never so you change it what you're in for let's say you're forced to change it every month so why so at the point change it does have happen to be at the day after someone starts cracking your password it could be any time in the past 30 days I mean why once a month I mean by that philosophy it should be you should change your password every day or every hour I mean it's just total lunacy if you think about it so I just ran across a paper that's a new publication of the National Institute for Standards and Technology in the United States which were the ones who many years ago established those nasty standards that you're your vendors are requiring you to use in putting in all the special characters and numbers and so forth and they were put together by a guy named Bill burr who was at at NIST and today he's saying never mind because he was asked to put together these password standards and he said okay great I'll do it can you give me the password data and show me how many of these passwords that were out there were easily cracked and they said no we're not gonna give you our password data you just have to work alone so with nothing empirical touching none of the data none of the real stuff he just sat in this office and made it up and always saying well never mind so let's say let's say you're a great cracker and you have a high-end UNIX machine and you're a really good hacker how long does it take you to crack this password how long do you think it's actually quite a bit longer it's actually probably longer than that so it's about three days that's a pretty good password I mean putting putting these numbers in the capital letter and the ampersand in it and so you know there's some value in putting all these things in there like the old days where we might have a password like this correct horse battery staple how long do you think it takes to crack this one now this guy is thinking this is this is called a system to approach to problem-solving all the rest of you use system one so system one is based on the intuition I mean it must be hard because it has all these funny character centers I can't understand it and therefore machine can't understand it but if you look at this these are just you know configurations of 128 combinations at each one you add makes it 128 times harder more or less you you gain a little bit back from context but why did you all say no it's just this is going to be easier well there's a lot of these things so by the way if you if you think that your password is super or secure go to this website and see if you've been pawned or owned chances are 9 out of 10 that you'll show up there that there's someone else who knows your password and can very easily get into your account so you just check this out so why do we believe these things we believe because what kind of makes sense you know it's hard for a human to understand if I put in these special characters and therefore it's hard for a machine and it's clever oh wow it's clever it was done by a real guy at the National Institute of Standards and Technology I mean it must be true and it's so clever to put in all these funny characters and the standards tell me - all right I changed my password on LinkedIn or got a particularly draconian site recently I can't remember where it was I think it was Google everyone else is doing it or my server service provider requires it my service provider requires it now we trust them right because that good man these things become part of very very broad movements and they become tired of the social culture they calm part of the infrastructure and we start getting a culture that believes things now I used to do some anthropology work and I was working with an anthropology and anthropologists from Australia actually was a student of Christopher Alexander's but not only does anthropology work and are on an anthropological paper and I said that cultures will introduce practices into their culture because they solve some problem and he said that's total crap he said these practices come up in culture just just because they come up so how many here from Denmark so why do the dings put little flags and what front you know this right you walk in Copenhagen you walk down you you'll see some dog and there's a tiny Danish flag in it all over Copenhagen why do they do this what cultural problem it's just what it means to be from that part of Copenhagen in Denmark and so maybe the problem it solves is establishing a cultural identity but it doesn't really solve a problem that's crap so there's a lot of things we believe and I mean so there's some of my favorite whipping boys like test-driven development we believe test-driven development it has been soundly and academically shown not to work in papers by Sydney Alto and Abrahamson and the host of other papers it destroys your architecture and its whole goal was to create your architecture so we have Dana David Hina Maya Hansen who says test-first fundamentalism is like abstinence only sex education an unrealistic ineffective morality campaign for self-loathing and shaming we're a really sick Bunch but we believe and here's some good you know American Puritan belief and you know very very self-deprecating it must if it if it hurts it must be there it must be right because we believe that there's pain and suffering and effort involved in success and so if there's if I'm not you know looking at the golden trails right or doing the magic guru sir I don't deserve to have good software so I have to go through this little voodoo ceremony called TDD it's total crap there's no evidence that it works I have yet to find any published evidence that it works and a lot of published evidence that it doesn't how about unit tests how many of you believe the testing pyramid and you know better than to raise your hand now right I mean this I published a couple of white papers you can find them on the web but I mean even the software engineering research by oh who's this by capers Jones shows that so here's this little itty-bitty thing called system test and system test has a much higher efficiency than unit tests but yet mic books it of the you know at the top of the pyramid is this little thing you do in the end and there's nothing here about testing usability and so now if you look at the talks bye-bye Brown and myself and a lot of others you see that what they do is they trim this so it's not a lot smaller than it was so I mean this is this is but what we believe now here I think we believe because I mean when I gave a talk on this at the testing conference in Stockholm why does the dog lick its genitals because it can why do you unit test because you can maybe you can't system test maybe you can't bring everything together and do the full integration so it's people people believe in what they can control not in what works and this has gotten us into a very very sorry situation now that's not to say we couldn't do it right and that's important to remember because the setup that Michael gave me for the talk is that I mean there's something really fundamentally wrong there's something fundamental about software development that's different and it makes it impossible to get this quality it's simply not true there are some who get it right and just the reason we're getting it wrong is we fall back on our instincts rather than using our heads now where do you pick up for things like this where did you learn unit testing where did you learn TDD where did you learn the latest framework how many of these things do you learn a through cafe so I would challenge food cafe to evolve into something where the speakers are giving more grounded talks instead of saying my experience is I was given a card to speak your formula and rule number two is say my experience is rather than this is the way it is I am only allowed to give you OSINT opinion not no facts now fair enough I understand the sentiment causing me what Michael wants is dialogue and I hope you come back at me and tell me I'm I'm full of crap that's fine I love this kind of dialogue but there's something about an industry where there's this political correctness that you know where we're just convenient or expedient rather than you know what has dutifully been proven to work there's a lot more how many of you believe in the Tuchman cycle forming norming storming performing Tuchman himself in his first paper says there was no empirical validation of this and the second paper he said these can happen in any order and he pleaded people to do some research to validate how it works how often their self hierarchy of need this pyramid it starts at basic needs and goes to self-actualization that was made for recovering alcoholics and man's law protested for years and years and years saying this is not a model of career development this is for recovering alcoholics and he finally just gave up maybe there's no difference empowerment Lulu the agile people are talking about empowered teams empowerment my management is abdication and there's research out of Rutgers University for large companies like DuPont and AT&T the chosen empowerment programs cause teams to become decoupled from each other to star for information and to not be able to get their job done empowerment is a way of cutting them loose in the ocean say bye you're not my problem you're empowered certification I won't even go there software requirements change how many of you are agile people so when's the last time you had a requirement change did the requirements change or did your understanding of it change it's a big difference so lots of our requirements change but the whole story here is that requirements are changing all the time no they're not it's just that honey I don't really think so I mean it may be that the end user themselves don't understand what the requirement is and that they have to come to grips with this now we have all kinds of tools for dealing with that you know prototypes storyboards use cases all kinds of things to get the the client in touch with their reality to get the end-user to think soberly about what it is I would really want before I actually build the real thing but it's not that the real requirement change is just that their perception of the requirement changes this is this is um this is not substantial but it's a whole foundation that a lot of people put in front of the agile decks about why we're doing agile requirements change no they don't they did once in a while all of these things are examples of a psychological model called the dunning-kruger effect and it's kind of I mean how many haven't seen the Sorcerer's Apprentice Disney film you know where he gets his he gets his hat and he gets a little bit of understanding but it's not enough to really be a master and so I mean how many of you understand how to Dede works is tgd a testing technique okay good right answer most people would say yes fact is it doesn't work so that you understand it works is a little puzzling but never mind that's another thing for beers afterwards but you know people know a little bit and their says cause and effect or direct relationship you know bugs come from units bugs come from methods and so if the method works then the whole thing must work and it just simply is not true and so we have an understanding of the system that says the system is just a sum of its parts and maybe we're about here and maybe we're 75 percent confident that TDD works but it's just because we're so ignorant once you get over this curve the more you learn the less you know until you start to get into this and this area is called being a domain expert okay now most people are domain expert in something you really are and I mean you have to dig inside yourself to find it what you are domain expert and I'd encourage you to do that and to leverage it but most of you are not working in that area or you're working in a lot of other areas and making pronouncements and decisions that don't rely on your expertise and you just did it for her passwords right I mean you all probably would have said with 75% confidence I believe this is a good password that's because you don't know enough you have ignorant and that leads to overconfidence and it's impossible for you to recognize a skill that it takes to make a good password and even to assess how much you know to assess how ignorant you are by the way who is a tuck this is different in Japan this is a Western thing so the anthropological literature shows this is different in Japan because the Japanese have Han say and cause n mind and they are always exploring and looking to be better whereas Americans you give them a test they get an A it's good enough a 90 is good enough why should I get in 94 it's still with me a 98 is still in a if a 90 is an A I'm good the Japanese want that hundred that's why I work in Japan so individuals may recognize and acknowledge this if you have some training but training with respect to real expertise to systems thinking to the real domain knowledge so we assume more than we do there's something else which is a cousin of this called the illusion of explanatory depth that comes from a psychologist in Adam Weitz and he's published quite a bit on this the classic that they I was trying to think of a better example for this group but you know if I asked you you know how your how a refrigerator works this is the example from their research and most you would kind of say yes now if I went into depth about okay well a compressor it's going to compress the freon where does the freon decompress and why isn't the whole thing at the same level of pressure how can I have different tubes have different levels of pressure in it but yet it's a closed system this is flowing how does that work so I really start pressing you on how our refrigerator works seeing it well I really don't understand do you know what agile is how many of you are out here on ads all oh you are somewhere on this line now you act on this line every day understanding what agile is requires some unbelievable counter cultural insight and most people haven't gotten to it yet they have the superficial so-called system one view of it they haven't gotten into the really deep stuff so when we teach scrum our two-day course is to take people viscerally through exercises who hands-on and to really come in to grips with why we need self-organization why we need the feedback and it may not be for the reasons you're thinking of at the top of your head so it comes down to the need for for deep context now people have believed things for years and these things have have gone across entire societies I mean originally we believe the the totally Ptolemy's model of the universe with epicycles for the planets we believed in witches and in witchcraft there's the Flat Earth Society and there's agile software development oh look at this it's a it's the same thing but hey we just want to believe it's a religion and it has its ceremonies and its rituals this little things of Voodoo and this is going to solve the great problem of getting us out of complexity and putting us on a par with the sciences of course not and this is this is why software is in so much trouble is that it has not yet come to grips with the sciences now my wife's father was a was a poet he was a great writer how do you think he became a great writer by by great penmanship I have on the right pen oh you have to have JIRA you have to have that tool right and we all think it's about the the ceremonies or the processes or the frameworks or the tools or the programming language it's not it's about I mean if you're doing work in medical so I think what a lot of your big sponsors here are in the medical industry right no no but some of them are I mean it pays to know the medical business I mean one of my clients is making a system that will analyze the doctors handwriting you're going to a doctor's office and the doctor will write something it analyzes a doctor's handwriting and makes a diagnosis for the patient which statistically is better than what the doctor can come up with so they're gonna make a lot of money in supporting medical institutions and whales so there are these things that we believe is an entire culture and the entire software culture right now is caught onto this fad called agile and you know scrum is kind of its handmaiden and well it's not me having a discussion with this guy from India right now who says well 99% of the teams in India I doing scrum I said yeah I've been to India I haven't seen a scrum team yet Abraham Lincoln said that calling a mule and ass doesn't make it one calling your team an agile team doesn't make it one now like I said some get it right so I'm get it right so let's come back to airline departures Hawaiian airline says an eighty seven point three on-time departure record this goes all the way down to Frontier Airlines just to sixty five point two so I mean there are some who know how to get it right what do they know that the other ones don't know by the way just this and this is another talk where is the number one rated airline on here top a CSI rated airline in 2015 is JetBlue well hmm that's interesting well we'll come back to that here's a couple of projects in Finland one is outside of Tampa Bay and the other one is on the west end of Helsinki and look I can't turn off the sound one of these titles means project manager and the other means director now one of these projects Oh what kind of a sound [Music] yeah cut it up the source there we go one of these projects came in six months ahead of schedule the project manager found an old bomb shelter where they could lower some mining equipment and coming from the other end and the other one was started at six hundred million euro is currently at one point two billion euro more than a year over schedule and there is no anticipated opening date for it just by looking at these videos which one do you think is six months ahead of schedule domain knowledge in Japanese this is called going down to the gamba being on the factory for being in the midst of the complexity the transition from vision to realization if you're out there with a shovel having opening ceremonies and the guy playing the trumpet and wearing the suit and tie in your office he was fired in November and replaced by another guy in a suit and tie and like I say there's still this thing has become a national parody if you do searches on the web you will find folk songs called the the lawn see mental whether it's making there's just a really bitter parody people are so fed up with this it has to do with being involved now this is a project we're studying if you want to understand agile these people are doing some some really cool stuff it takes deep context domain knowledge truly building on tacit knowledge and making tacit knowledge explicit in your domain my software development software development is like learning the pen you don't become a great poet with great handwriting you come by learning the language the culture history mythology human psychology you learn but you learn about building tunnels not a lot of the building tunnels but by learning how people come into stations how the rain comes into stations this is the big problem with the stations in Helsinki right now tunnels are done civil engineering part yeah no problem the stations don't work the whole focus of Nonaka sensei who was the godfather of scrum is about knowledge management with the safety model it starts with the knowledge it's not the process and the backlogs and all of this its valuing knowledge and keeping a treasure of knowledge and we tend to believe methodology and makes up for a lack of this and it's just wrong so this is a slide from the naka sensei that he gave at the scrum gathering in Tokyo it's been about three years ago now or he traces the history of scrum that started with his paper in Harvard Business Review called the new new product development game and then there was another one later both of these are about capturing knowledge and then look what's next the organizational patterns which were a way of capturing knowledge about how you build a product and then there's some things here we work through the book the agile manifesto and now he and and the other author have a book that kind of ties all of this together into the place of knowledge management in scrum it's about the knowledge domain knowledge and I mean the XP people try to tell us we don't need this all you need to do is hire a gradual consultant and they'll bring in the right process and the right process will make it work no so deep domain knowledge so the last kind of part of this talk is and this is I'm going to read directly because because Watson here has put these words so well I can't have said it better and he has just published an article this just came out last that's month he's from Amazon and he just ended up at Amazon and was reflecting on why is he there what's happening in their career in the careers of consultants today and he says why the 40% of software projects fail even after we've been doing going at this for problem for 50 years he says the most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain in one skull so this isn't about t-shaped individuals this is about individuals who understand the business Richard Gabriel the founder of a company called lucid they meld they made Lisp tools and so how many of you have used lucid Emacs for example that was a long ago left over from that company dick Gabriel was the creator co-creator of C loss and scheme he said that his programmers could could understand and work with a business spreadsheet much more adeptly than an auditor could because they were invested in the business and understood the business this isn't about understanding coupling and cohesion or polymorphism or any of those those that's not learning how to write you learn that in kindergarten this is about understanding how do surgeons do work what customer market segment I'm going to be able to reach with this kind of product it's understanding the business domain not the technical stuff programming skill in the absence of business domain knowledge is becoming increasingly worthless so if you're a general purpose software engineer whatever in the hell that means what's a software engineer I'm an electrical engineer I know what an engineer is I haven't seen any of it in software engineering so after a voodoo yeah software art maybe software engineering now engineering is rooted in science what is the science of your discipline of mining of medicine of Finance so Watson who's at Amazon is looking at the teams in Amazon and saying this is what matters is really knowing the market most of the time is spent thinking and communicating about a virtually endless number of micro problems that seemingly emerge out of nowhere and constitute the real territory between the technology and the business problem part of traversing this landscape of micro problems is inventing communicating and internalizing a plethora of named and unnamed abstractions it's the only way to break down the complexity so you can grapple with it what do you taught us computer scientists reduce complexity get rid of coupling if you let's say you got rid of all the coupling it wouldn't be a system anymore it'd just be a bunch of disembodied objects coupling is what makes it a system but you believe that coupling is evil no it's not accidental complexity accidental coupling is a bad thing and people fail to distinguish you want to keep the the essential coupling that's part how do you know what to keep and how to throw away deep domain knowledge why didn't you account for that in your estimate you didn't account for it because the software development process is exploratory by nature it's not a science you can't go from first principles it's like art well sardis will you know erase a painting and redo parts of it again and again and again software should be the same way fred brooks said build one to throw away I have a friend named Dave Thomas how many of you know Tate Dave big Dave small talk Dave so yes he's filthy rich and he started up a lot of companies as a venture capitalist and one of his companies they built a prototype and throw it away they learn from the prototype then they build the product and throw it away then they build the deliverable and ship release one and ship release two and shipper lease three and throw it away every third release they are throwing things away do you think they have any problems with technical depth I mean the code is just typing it's just writing you're not paid to type you're paid to think thinking is allowed and you don't have to rethink these things you carry over your knowledge and you just you read through the system in a matter of a few days or weeks the nature of the beast is that software requirements rarely change what changes is our awareness of them and our grasp of their implications so all the agile people are looking in the wrong place they're putting the blame on changing requirements out there no it's your job to understand those requirements by working with the people in that domain and taking them by the hand and understanding how the domain works you're not going to find this in your C++ book or your c-sharp book it's just not going to be there you're on a software development team that's send you to software development conferences and tutorials and so forth all the time how many of you are in banking when's the last time they've been to a banking conference how many of you are on machine manufacturing when's the last you been to a machine manufacturing conference oh no you're a software specialist specialization is for insects this book published called thinking fast thinking slow I'll be referring to system 1 and system 2 thinking system 1 is thinking in terms of stereotypes simple intuitive stuff I want a messy password so it's hard to crack system 2 is understanding the causes and the feedback loops and the dynamics systems thinking so there's only two options here that I see for us to get us out of this to lift those who have not yet attained this level of excellence I think I missed the slide in here I did have a slide in four or is it coming up about skat in Denmark the tax system for gambling tax they use scrum and use cases that came in sixty percent under budget and 40 percent under schedule and they credited scrum and use cases why use cases it gets them into the domain knowledge this was systematic in Aarhus we know how to do this it's a matter of letting go of the technology and working with the business so we need to give up the things we believe like coupling and cohesion and then polymorphism and micro services oh my gosh that's so stupid and ground ourselves in a system of profound knowledge like Deming calls it a new system to or develop deep context I see these are our two ways out and the way we the way we advance in our careers and the way we train and the way we attend functions like this are usually ethical to that so some concrete things you can do last slide what's a user story there's a user story convey deep context you deliver user stories so how many of you are doing scum so you notice it's called a product backlog it's a list of product increments it is not a list of requirements it's a list of product increments that the product owner has put there to solve some end user it's not a requirements list there's no user stories on a product backlog there are definitions of product increments now you may go through user stories and understanding what that product increment should be that's fine you probably want to use use cases if you have a lot of them no user stories on your product backlog by acne think ahead and plan scrum is all about planning how many of you believe believe in deferring decisions to the last responsible moment this is a total misinterpretation by the extreme programming people of a principle from lean that comes from a paper by Ballard on what's called negative iteration in lean you pull decisions forward yes there is a last responsible moment and you want to encounter it as early as possible deferring it is kiss of death they got it exactly wrong you never defer decisions you pull decisions as far forward as possible so you can start working and the system can give you feedback and now you increase your domain knowledge the system isn't going to come up and bite you in the bottom one you just want to decide you need the information you have to work for it pull those decisions forward get rid of architects who don't code I mean either get them into coding so they're in there at that interface a complex interface between the product and the code or put them on an RV tower somewhere where they're completely disconnected from the rest of the product and they can't do any damage which is the real reason I think some companies title them as architects because it really can't do anything from there the developers do what they're going to do anyhow right get rid of coders without an HCI background if you've got no GoM's law or Fitts law and don't know the basics of UX design you have no right being an object-oriented coder object orientation when invented by Alan Kay was all about reflecting the end-users mental model in the machine and the interface between that code and user is the interface so the coder in the HCI person should be the same person or they'd better be a pair of programming all the time otherwise you don't understand object-oriented programming fire managers who manage production so how many of you are scrum people again and how many of you have a manager who's managing production we have some say in the future ordering or the financial targets or any part of the business you have managers should deal with something other than personnel that's not scrum fire them this is the product owners business not the managers business it's a product owner who has the domain knowledge not that the manager and focus more on improving your business skills than software skills great penmanship doesn't make a great writer so whatever your business that you're in learn to love that business to become a domain expert in that business I mean the software stuff we can teach 14 year olds we are teaching this to 14 year olds you are teaching this to 14 year olds huh look even better great seven year olds I met this 48 wonderful 14 year old kid loves to always hear I'm going I want to get in touch with him again that's the easy stuff the hard stuff is the domain knowledge now it's not that much harder it's just that we ignore it and I think it's out of a sense of insecurity that we feel our brains are only so big and we're proud of our CS backgrounds or accomplishments or mastery or our degrees and we tend to view the other stuff as a secondary and it being shown the watch so thank you very much [Applause]

Channel: FooCafe

Views: 44,426

Keywords: Learning, Sharing, Software Development, Agile

Id: gPP7Bleg214

Length: 47min 30sec (2850 seconds)

Published: Tue Nov 28 2017