Lessons From the Fifty-Year Quest to Turn Programmers into Software Engineers

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
you [Music] hi my name is Andrew bagel I'm a researcher in the ability research group at MSR and today we have a nice guest Adam Barr who used to work at Microsoft even as short as two years ago I met Adam a long time ago actually when he was in engineering excellence and we were he gave me a lot of advice about how to work with new employees at Microsoft and especially how I used to do studies to figure out how they adapted to life here and I've had lots of great advice about his observations of that process before that he was also part of Windows and he's been working at Microsoft for in some capacity over the last twenty three or so years so he's got lots to say and today he's going to talk about a book he wrote called the problem with software why smart engineers write bad code and lessons that he has sort of picked up over the what he what we all perceive as the last big push in software engineering over the last 50 years and where we've come to and where we should be going and next as well so thank you Adam please take it away thank you thank you for having me thank you for coming out so as he said I'm at a bar and I wrote this book this is my career more or less that I started out of college a small company called dendrite which you probably even heard of that I came to Microsoft in early 1990 I worked on the first two versions of NT I worked on an interactive television project which went nowhere eventually like most of Microsoft's interactive television projects I worked on Digital Studio a nonlinear video editor at a company and Montreal they were acquired that's where I grew up worked on Windows 2000 also known as NT 5 there's actually a break in there right there I actually wrote two books once called proudly serving my corporate masters which is about the first 10 years and then one was called find the bug about debugging and reading code which you're welcome to peruse after the talk then I came back I was a p.m. on PowerShell this result dev I was a p.m. on PowerShell I worked in during excellence for about five years we give out these nice engineering Excellence Awards no other logo apparently I survived on the Internet then I went to office worked on 2013-2016 and the next version for a while once office started going monthly shipping the year stopped really mattering as much and now I work at a company called cross lake which is a consultancy that does due diligence for acquisitions so if you're planning on buying a software company and you want to kick the tire it's just let me know I can help you out so the term software engineering was originally about fifty years ago actually I want the subtitle to look something like the 50 year quest to turn software programmers into software engineers but MIT press said that was too long so I just made it why smart engineers write bad code but the term this this city on the left here is garmisch germany so in 1968 NATO the North Atlantic Treaty Organization decided that they were concerned about the quality of software used for military purposes so they convened this software engineering conference and it was the first time that the term software engineering really was used commonly so they got a bunch of academics and a bunch of industry people together they met they agreed yes there's a problem with software we need to work on it we need to make real software engineers sounds great everyone away happy they came back a year later in Rome and had the second NATO software engineering conference and they got into a big argument with the industry people saying the academics were had their heads in the cloud and the academics and the industry people just wanted to shove software at the door and didn't care about methods and that was the end of the two-year attempt of a NATO software engineering conference and that gap the academic industry gap has continued and grown in the last 50 years that is the problem with software that I mentioned in the book but there's a lot of other good stuff too so one example is language choice so this is the the Tower of Babel meant to symbolize the variety of human spoken languages you probably recognize this image because in a hallway near your office is they have completed jigsaw puzzle with this image on it but it's symbolizing the variety of languages if we look at computer languages where they came from so the first few languages came from academia so basic was two guys at Dartmouth Pascal was a guy in Switzerland the DTH and Al Gore was actually a committee of computer sciences who got together to create the language then he moved into this phase where research labs tended to invent languages but that wasn't their main purpose they had something else in mind and they needed a better language so Simula was a Norwegian lab which was actually trying to do simulations like traffic simulations and invented Simula which was the first object-oriented C C++ came out of Bell Labs again they were trying to write better switching software they weren't trying to create a language but they needed a better language and small talk Xerox PARC was doing research on graphical UI's and decided they needed a better language to write graphical UI's so they camp with small talk again it wasn't the goal to sell small talk it was a means to an end and now you have really companies creating languages so the first two that really this atom was objective-c and Eiffel which were the two big object-oriented languages that were hyped now okay I'm not saying I was very language but he was the first to put that DNA well but the guy who wrote it Meyer and by the way I I said hold questions but you can it's really terrible at the key thing was you had a company iPhone that was selling Eiffel the language and he was hyping laboratory and software because he wanted to sell eiffel and Brad Cox came up with objective-c and had a company selling objective-c that was the goal so he was also hyping objective-c and he talked about how we're gonna stitch together objects like integrated circuits on their motherboard and in Bertrand Meyer came in with eiffel and said oh yeah forget about don't think about your actions think about your data it'll change the world you know the which is the fundamental object Orion a hype and they were the first to really like I said that was the goal of the company so they tended to overhype because they were trying to sell software and basically everything else is like that - right see shark and go you know any java we're all companies doing this to sell the language or to sell a platform based on the language right so their motivations were a little suspect and theirs in academic research about these languages they're not backed by some explanation of why this language is better in this situation and that language is better in some other situation people are free to just make outrageous claims about the quality their language and how it's awesome for everything because it's drifted away from academia so what's what's caused this drift this is a diagram from Fred Brooks's book it's in the book the mythical man-month it's not in the essay the mythical man-month so Fred Brooks is si is famous the mythical man-month are saying if you add people to a software project that's late you make it later but this is something else he said it was very insightful like most of his book so at the top left you have what he called the program which is what you work on in school what academics can handle a professor on a couple grad students it's just a program maybe three or four people work on it it lasts for some short period of time and it goes away it fulfills its purpose and fred brooks said these things get complicated in two dimensions one is you have a programming system where you have a software that stitched together by multiple teams work and they have API isn't have to integrate it and not everybody can fit in the room and it gets more complicated going down as well when you have a programming product something that's sold is maintained it lives for years and years the people working on it now or not the people who originally worked on it and it's much more complicated to work with documentation and testing and maintaining it and he said it gets three times more complicated in both dimensions so a programming systems product which is what company like Microsoft is working on is nine times as complicated as a program but actually Edgar Dykstra an academic and and perennial source of good quotes actually claims it's a hundred times more complicated so he said it nice if I could Ellis trait the various techniques with small demonstration programs this is in some book he's writing about software and could conclude with and when faced with a program a thousand times as large you could pose it in the same way this would be self-defeating as one of my central themes will be that a two things that differ in some respect by a factor already a hundred or more are utterly incomparable so he's saying this top left quadrant in the bottom right quadrant although both software are really very different and then Harlan L is another this is an IBM guy actually very well known IBM for a long time leading software teams has the same message its characteristic the problems to be solved by advanced practitioners require sustained efforts over months or years for many people tens or hundreds so this is the many years and the many people right it's both of the complications this kind of math problem solving requires a radically different kind of precision in scope than required for individual problem solvers now this is 1980 right this was understood by people at the end of the 1980s but instead of kind of listening to this wisdom people went searching for silver bullets this is the lone ranger who's famous for shooting his enemies with silver bullets just kind of a signature move but silver bullets are if you want to kill a werewolf since we live in the northwest might come in handy you need a silver bullet apparently and Fred Brooks wrote an essay called no silver bullet in which he explained that we hear cries for a silver bullet to make software costs drop as much as hardware costs but we've seen how silver bullet on horizon there's no single development in technology or management which gives even one order of magnitude improvement in productivity reliability and simplicity and then a key point is at the end not only are there no silver bullets now in view the very nature of software makes it unlikely there will be any and there's an important point but despite that the history of software engineering these last 50 years have been a search or silver bullets people claiming that they have some technique that's gonna make software simple and make all the problems go away or at least be minimized so starting with structured programming which is way back in the late 60s and early 70s which is basically although it's interesting every book about structured programming makes great claims about how it's awesome and then sort of confesses later that they're not really sure what structured programming really is but it's gotta be really important because everyone's talk about it but basically structured programming is not having go twos in your code like that's what it boils down to don't write assembly language in a higher-level language and that was a big thing everything's gonna be saved by structured programming then we had formal testing was gonna save the world this is what our early 70s people started talking about testing four dozen the entire collection of object-oriented programming which led to design patterns which led to unit tests which led to TDD that whole thing was individually and collectively gonna save the planet agile of course is hype to the sky now we've got functional programming you probably heard DevOps again is gonna solve all the problems you can tell when you read a book about these stuff and the prefix just makes these wat the preface might be makes wild claims and doesn't really have much content that it's you're in the Silver Bullet territory and it started way back in the day this is a picture of mainframe with tape reels to symbolize way back in the day the structured programming actually has an academic theory a formal proof that you can write a program without go to I won't read this quote because that's basically what it says now the code that results if you formally apply this is actually really ugly and you would not want to write it it's probably better to have go twos then what this thing produces but it actually at least was an academic saying you know I'm gonna show that structured programming works I'm not just going to claim it and then formal testing off so you had both Dykstra the academic and Harlan Mills the practitioner saying you can find bugs the formal testing but you can't prove that your software doesn't have any bugs note the dates these is before Microsoft was founded and yet Microsoft embarked starting in I don't know in 1985 or something on a 15-year mission to show that you could in fact prove software correct with formal testing which didn't go all so well but the problem was Microsoft ignored the history here unfortunately and many other companies did too I'm not picking on Microsoft I just happened to know a lot about it but that was kind of it where the really trying to figure these silver bullets out with any kind of research ended there was some research people used to study programmers in 70s people actually studied commenting styling you could read these papers it's quite interesting you know commenting style do variable names matter there's actually a theory that it was better to have like random variable names rather than ones that made sense because it's forced you to pay more attention when reading the code I mean maybe it's crazy idea but people actually studied it a little a bit experiments indenting does indenting matter believe it or not go-to people tried to study does is code clearer which go to a nada there certain cases where it's better to have go to that kind of thing again note the dates are all kind of in the seventies but in Fred Brooks point out this kind of died out so he wrote an update to mythical man-month in the mid nineties and he said he was surprised how few of the things that he asserted were critiqued proven or disproven he wasn't claiming everything was right he was just surprised that nobody really studied it in any kind of empirical way by ongoing research and experience and so you get comments like this talk about Hungarian notation this is in the book showstopper which documents the first product cycle of Windows NT coding style Wars are a waste of valuable resources although the confusion caused by Hungarian probably wastes more time so this is an unidentified Windows NT three for one developer in 1992 it's not me even though I was it identified one of the NT developer in 1992 but I did buy into this at the time few years out of college because auntie didn't use Hungarian so it must be be right my current project was sort of my the thing that was driving my thinking about software and then you get to this does anyone know what TV show this is from mr. Silicon Valley and this is a Richard breaking up with his girlfriend and why is he breaking up with her his house versus space is right she used this TAS uses space and sorry he uses tab so of course I mean obviously that's a huge issue and Harlan Mills has a quote about this long before Silicon Valley he's not he's not commenting on Silicon Valley there was no mathematical rigor to inhibit these discussions some became quite vehement this scene actually ended with Richards Richard throwing themselves down the stairs although it's not really clear why he does that so what happened we had this studies people are studying go to is an indenting and commenting style in the 70s and then now or suddenly nobody's paying attention stuff anymore well here's a hint from a quote from Gerald Weinberg another longtime observer of computer science who I encourage you to read so he's writing ninety ninety eight he's talking to some programmers in the mid nineties you say he's interesting the coincidence that all of them had to learn to program before they studied throwing at me formally in school that's a major change brought about by the personal computer I had not even seen a computer before I went to work for IBM in 1956 yes there actually were computers in 1956 but it's not a coincidence this is the important thing that happened the personal computer is the cause of this throwing everything away and of course a lot of the blame rests with these two guys Paul Allen rest in peace and Bill Gates this is them at Lakeside in the early 70s learned to program teach themselves to program and basic on some terminal all connected to a mainframe they did just a little earlier than most people most people didn't quite do this in the early 70s Mike the late 70s when the PCs all the PCs came out with basic but this is what happened they everyone taught themselves the program once they had access to a computer they didn't need any instruction you need to take a class to get access to a computer leaders had a giant basic programming party right about the same time Edgar Dykstra is frantically trying to get people to stop programming basic it's practically impossible to teach good programmers to students good programming to students that have had prior exposure to basic ask potential programmers they are immensely mutilated beyond hopes of generation so I just a survey who learned to program in basic yeah so you can disagree but I think it took me a while certain to overcome my sense it because I know how to program basic which didn't even have functions with names and parameters when I was learning it I was a mentally mutilated might be overstating it but I was slightly damaged now Dykstra like I said Dykstra just you know generates great quotes constantly or did but actually that point he really had a point this article it's called how do we tell truths that might hurt he's basically saying don't program in basic there are better languages out there and if you learn basic first they're gonna hurt yourselves unfortunately its 1975 the Year Microsoft founded what was Microsoft found to do produce a basic interpreter what irony the result do you have a bunch of self-taught programmers out there right like I was self-taught and a bunch of people at Microsoft now are self-taught you may have gone a major in computer science in school but you didn't learn to program there right you you tie yourself to program in high school you kept doing that whatever worked for you whatever crazy debugging system and variable naming and all that and then you kept going at that for a while probably Microsoft until eventually you might realize oh wow this isn't quite working for these programming system products like this bottom right quadrant I'm doing top left quadrant stuff trying to get paid to do bottom right stuff I have to adapt my my approach but really a lot of people are self-taught and Harlan Mills again writing long before Microsoft was found there literally for Microsoft is founded when there maybe would have been time to fix this problem but nobody paid attention our present programming courses are patterned long-nosed of course in french dictionary in such of course we started the dictionary and learn what the meaning of french words are in english that corresponds to learning what pl/1 or Fortran statements do today to just learn the syntax of the language I think completion of such a course in French dictionary we then invite exhort the graduates to go forth and write French poetry which corresponds to writing code I think I can stop explaining the analogy at this point of course results that some people can write French poetry and some not but the skills critical to writing poetry were not learned in the course they just took in French dictionary so many self-taught programmers happened to be naturally clever people and can write software but they're not taught that in college they just haven't had that that skill and they taught themselves they read a basic manual like I did which has the syntax but doesn't really explain anything about why you should be doing this stuff and Harlan ELLs again types and if the precision scope are not gained in university education it is difficult to acquire them later no matter how well motivated or adapt a person might be at individual intuitive approaches to problem solving so you may be great in the top left box but it doesn't mean you're going to be good at the bottom right box the programming systems product so you may not know things you'd like to know like what's the right programming language to use people just tend to use the same programming language they used for the previous problem they saw what to look for in code reviews what's look for hiring right notoriously interviews for software developers are kind of random how reliable your software is is your software about to fail use your software obsolete so the vast majority of software for example that runs the internet and is the first piece of software to contact a potentially malicious network packet is written in C because it's going to be something into guts of Unix Linux or Windows and that's like exactly the worst language for that kind of thing because it's so exploitable by design but it wasn't meant to be connected to the Internet so when you talk to a civil engineer they can look at a bridge and say this bridge is about to collapse and they can say well if you do this stuff you might fix it up in a last while longer or maybe it's hopeless it's gonna collapse no matter what that's what engineers can do when you look at something like the the office source code base which you know I happen to be work with for a while now I'm not making any claims about the office codebase being obsolete or not but it will be very hard to answer the question is the office codebase obsolete or not I know a lot of work has been done to improve it but is it actually being fixed up or is it just you're painting a bridge which is gonna collapse anyway it's very hard to make these kind of statements cuz there's not a lot of theory behind software and programmers are just contempt to use their own experience as a guide right whatever they learned about anything in software they're like well works for me people are throwing money at me this is great I've got a career I don't like to think too deeply about whether I'm doing the right thing so Fred Brooks another thing he said which I think is sort of symptomatic of programmers so about nine years after there's no silver bullet I say he wrote a follow-up essay for a second version of his book and he's talking about people attacking the no silver bullet essay said they mostly attacked the central argument that there's no magical solution and his opinion that there cannot be one so they agree with his arguments in no silver bullet but then they go out and say there is a silver bullet for the software beast which is the author the person complaining has invented so the base is saying everybody else is an idiot but I know the answer I can solve a software problem which is sort of the ultimate thing a software engineer would say this is Icarus the Greek legend so Icarus was was stuck on an island imprisoned sort of a long story but anyway his father built made wings out of feathers and patched them with wax and yet they attempted to fly away from the island they were imprisoned on at some point I'm not sure this actually really happened but but he got interested it's not any flew too close to the Sun and the wax melted the wings fell off and he drowned in the sea poor guy and he's asserted the picture of hubris right people thinking they can do more than actually can this is a quote from Alexis Ohanian who founded reddit but it for the purpose of this he's also married to Serena Williams right arguably the greatest female tennis player in history so he found a rat he's got a very special website thinks he's a genius and then he actually observed Serena Williams training to be great at tennis he says I thought it was the hardest working person on the planet I thought we we software were the hardest working industry that's what we tell ourselves it's all malarkey I've had this front-row seat over the last three years to greatness it's a humbling experiencing what it takes to actually be that great so he is sort of realizing he's not quite as often as he thought he was just as he could crank out a website and Gerald Weinberg once again pops in saying the essential personality factor in programming is a small dose of humility and he goes on to explain without that you'll be go for the classic pattern of Greek drama like Icarus that successfully suffer confidence who are willing to blind self-destruction and the idea that a programmer can learn a few simple techniques self-taught in high school think you're an expert and then be crushed by the irresistible power at the computer or at least maybe that's a little dramatic but you know have more bugs than they expect kind of thing and you might think wow that's great but can't we just go back to the simple days of writing code and the top-left quadrant and what he used to actually like writing writing programs and the answer's no sorry you work with Microsoft you're getting paid to write the programming systems products not the fun stuff so deal with it one problem though is how fast it's all happened so Harlan Mills noted this in 76 that it's all happened in one generation in the past 25 years got this whole new industry that's has a critical role in business in government had it been spreaded over 125 years five generations instead of just one you might have a different history imagine the opportunity for early industrial development with five human generations of curriculum development education feedback for the expansion of useful methodologies and pruning of less useful topics right now you might think well okay but it's been 40 years more so maybe we've had that except remember we kind of threw everything away about five years after he said this because of the personal computer revolution people sort of ignored all the wisdom from the 60s and 70s so we kind of started over we're about 35 years into attempt to to relearn everything about software development and it's still basically one generation you still have people floating around Microsoft who learned to program in basic on some janky computer and that's where their formative experiences came from it's like a four ville right was running Boeing if he was still around but aviation is developed over a long period of time and all the pioneers have aged out Orville might be sitting there saying yeah I know about those those newfangled jet engines and you know maybe we should stick to balsa wood or whatever if that's not happening in a VA shion's but it essentially is happening in the software industry the people are still around the early people who taught themselves are still around and if you learned to program up in the top left it's hard to adapt to understand what's necessary for the bottom right Marx that's actually done a pretty good job I have to say now I'm a software could sell them I go look at companies all over the place and Mars actually pretty good in their techniques it took a long time a lot of painful learning but actually they have a pretty good handle on writing these programming systems products at this point although a lot of mistakes were made if you wanted some fancy so this is actually randomly I got I saw something Microsoft redid their procurement site the internal procurement site so I was just looking for a diagram of a complicated software component software system and came up with this but there's a bunch of p0 right there all stitched together with API then it's got a bunch of different modules clearly it's in the bottom right quadrant and this is complicated it's not just a simple program and this is just an internal procurement section for Microsoft right it's not the world's most complicated software and so but you have to do all the hard things you have to you have to worry about documentation and write unit tests and do static analysis and all this stuff and think about API design it's a lot of work it seems more fun to write small software but that's the way it is these days in aviation they're where the hero is this is Charles Lindbergh first person to fly solo across the Atlantic a lot of hero pilots and the hero pilots did awesome stuff and inspired people but eventually they either from being a little too heroic or just from aging out they were no longer on the scene but you still have a lot of hero and Microsoft went through a phase they celebrated hero programmers which I think they've mostly gotten over but there was a lot of that that the person in the corner cranking out code was was revered and that's just not what you need for real software development I know I think I want to talk about is performance so this is Donald Knuth probably most famous quote Donald P with another longtime writer about software there's no doubt that the Grail efficiency leads to abuse growl efficiency meaning worried about performance over other stuff programs waste enormous amounts of time thinking about or worrying about the speed of non-critical parts of their programs and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered we should forget about small efficiencies say about 97 percent at a time premature optimization is the root of all evil not that bad is the famous quote from Knuth now if you're back in the old days you're programming this thing which is an early trs-80 model one so this had 4k of memory that 4096 bytes not for Meg or 4 gig or whatever 4k it had a basic in ROM that so the basic was around but for cab to hold the language I mean I mean the program and the data the thing that you could have 26 numeric variables a through Z 2 strings a dollar sign and B dollar sign and one array a four array I guess but people actually wrote software this thing you know miraculously okay in that environment you're worried about performance right it's like you know it's there's not a lot of room but you're also writing urine up in the top-left quadrant right probably there weren't a lot of large software government projects going on in this thing I was single people writing some piece of software for themselves so fine do whatever you want when one person is writing on when one person is working on piece of software you can use almost any language almost any technique because you'll know what you mean when you read it especially if you're not using it for a long time but people still like to focus on performance because it's measurable in particularly you can measure performance if you're in a top-left quadrant right any small piece of software can be tuned and made faster it feels like you're doing something useful because you can measure it measuring maintainability and it's my API easily consumable by somebody else involves dealing with with other people basically not not really what programmers want to do but but when you're working on this stuff that's what you got to worry about so it's much easier to focus on performance you can get this gratification oh look I've made it faster and you have to deal with other people but unfortunately when you worked in a large software company you have to deal with other people and other people reading your code is much more important than you geek and out on some ran the performance tweak that makes it harder to read and even today I hear people say okay what's wrong with today's young programmers kids today and they'll probably complain about perform so probably say well they're all smart and everything but they write this C sharp code to manipulate a string and they don't realize what's going on underneath oh my god and I'm like that is the greatest thing like that they don't to worry about that they also don't get exploited by random script kiddies on the internet too which is a nice thing so the fact that you don't do worry about this you have languages take care of these basics and memory allocation is a huge advancement in software and not some horrible thing that people are ignoring performance doctors talk about this he's talking about goat cheese but he's saying why goat cheese are bad but it's the second part is important we're trying to shorten the conceptual gap between the static program and the dynamic process that is you read a program spread out in text space you want to figure out what's going on in memory of the process so you need to worry about readability not performance and focus on whether people can understand the thing when they read it performance and readability are opposed to each other this is the spy versus spy guys from Mad Magazine which may be slightly old reference here but now I know people PI of some idea in mind where okay there was an algorithm and I made it I managed to make it easier to read and faster and simpler and it's all like performance and readability were marching together hand in hand but that almost never happened they generally are opposed you start with something nice and clean and then you say oh it's too slow I better start hacking away at it I'm gonna add an extra parameter I'm gonna make the code more complicated to handle some special case I'll add some side access to the data whatever and it just gets a takes away from readability also point out you could change the word readability to managed code and the word performance to native code and you would have a graphic summary of a battle that raged inside Microsoft for most of the decade of the 2000s between the dotnet API and the windows native API over what is the story we tell developers and the story developers heard was I'll go right iOS applications instead so this really causes problems obviously you could guess which side I'm on I think most who's been at this point in favor of of managed code but people are making claims about performance and readability being able to be improved together that I don't believe we're true they tend to be opposite to each other so I'll just clean up canoes quote instead of saying premature optimization is the root of all these I'll just say optimization is the root of all evil hey it's me this year now this does not mean you never optimize right this is a take-off on the quote money is the root of all evil so that doesn't mean you never use money you should we should get rid of money it just means that money causes problems and you have to be careful about it so same thing I'm not saying never optimize I'm just saying be careful because when you have problems with your software a lot of times it's because somebody was was over optimizing of course people always have excuses to optimize right start out you're working on some mini computer with small amounts of memory then the PC comes along it's got small amounts of memory the next generation has these small devices they have way more memory then these other things but still ah gee it's kind of a handheld I better start optimizing here but just don't do it my father tells a story of someone explained how do you identify a tree in Oregon and the answer is you just pointed and say it's a Douglas fir now you'll be occasionally wrong but really not enough to to matter same thing with authorization when someone says should I optimize something just say no okay she'll be wrong but again not enough to matter and if someone wants to add a cache or something just just like don't do it i'ma get encash is a great fun they're nice little top-left things you can do when you can tweak them and oh it's so much fun to write a cache but you know it's just gonna collect bugs along with the data and well now things are moving to the cloud this is good because it it clears away some of the grunge in code because you have to deal with the problems right you can't just throw it over to user and they have to worry about all the bugs so it's nice it inspires people to write maintainable code because they feel the pain more but it's also there's some good techniques here you know not I'm not throwing up we're here claiming that containerized micro-services are a silver bullet for software development even though of course some people are saying that but it does when you start connecting services that can scale independently this is sort of the modern way to write software in particular you can they can they can work independently they're connected by api's which are not these ugly binary api's that are hard to debug you can actually you can log them you can replay them it's very nice you know it's worried about memory allocation I mean another aspect of this sort of performance versus readability of people who write code that obsessively checks for memory allocation failures and you wanted to put the actual logic is seven ifs down over here and the barely fits in your editor that's not a thing about managed code people could just write code that pretends that memory never runs out I mean I know they don't really do it they actually catch the exception right and we do something when memory runs out but reality is people just put that memory never runs out which is great because memory never does run out and if it does and it's a service who cares it gets restarted so you can write cleaner code I mean a different senior memory allocations failing and you cascading up a failure versus throw an exception which isn't handled is there is no difference just restart to think so eventually we will all be writing software like this this is my claim like even some game will be written like this to be reliable and scalable even though you might say oh but it won't perform well but it's worth it to make more maintainable code and you can actually get to some notion of I want to make this thing twice as strong I want to make it twice as reliable because you could actually handle it with programming techniques which are harder but that's what we need to move to the quote from Lord of the Rings shortcuts make long delays but you can't skimp on this stuff you have to do the like I said you got to write the test and you got to do the code reviews and all that stuff there's the same advice we're giving and engineering excellence ten years ago inside Microsoft and if you're a manager then please give your employees time to do this right don't look at some schedule and say I don't know I think I could do it in half the time right because you're thinking of the old way the grungy way of writing code you're not thinking about modern software development where things just take a lot longer and there's a lot more to do so Harlan Mills again this is 40 years ago so the next generation of programmers will be much more competent than the first ones they'll have to be just as it was easier to get into college in the good old days it was also easier to get by as a programmer in the good old days for this new generation of programmer will need to be capable of a level of precision and productivity never dreamed up before now he's writing in 78 and I think the next generation which is my generation basically did do that we were better programmers we had better tools they're better techniques we wrote better code than they did in the 70s but it has to happen again people always tend to write software that's just about as complicated as a human being can handle right so if you're writing in assembly language in 1967 or something then maybe getting a sort to work is like barely something you can handle and now many years later getting something like Windows to work is again sort of at the limit of human ability and we'll be doing more complicated self in the future and people have to like do more stuff that's free more productive and hopefully we can get academia back working with industry again so there's actually be some scientific backing to all this stuff I do encourage people to work with the ACM and I Triple E Computer Society which are industry trade groups and I don't mean just people in research I know research people in building 99 go to a lot of conferences and and and present a lot of conferences but I really encourage everyday product group people at Microsoft to also get involved there's a lot of wisdom there you can get there's also a lot of wisdom to share like I said Microsoft actually does a pretty good job of software development and a lot of companies could learn from Microsoft if you were out there talking about it which we tend not to do we excuse me I mean you I don't work for Microsoft anymore if you want something to read besides obviously you know my book I do think these three this is basically Harland mills his book Fred Brooks his book and Jerry Weinberg's book are great even though they're all old a lot of wisdom still applies because it's the same problems people had back in the day Dykstra has some good books too but his books tend to mix together something insightful about programming with a proof that a sort algorithm is faster than another sort algorithm or something so they're kind of a mix but these are all good these are all about technique and process and and management and finally if you feel any residual guilt because you're working for Microsoft and Microsoft was founded to create a basic interpreter and go pollute the world with mentally mutilated programmers I used to work in engineering excellence interesting Axel's to shut down a little bit after I left I think that's a coincidence but I I wish Microsoft would study itself more there's a lot to learn we found that people tended to not be interested in advice from other groups of Microsoft because they could easily understand well that we're windows in their office and more completely different so I'll just ignore that advice whereas they take something like agile which wasn't really relevant to Microsoft in most cases but they'd like oh this is great so I encourage Microsoft to study to look inward a bit like I said there's a lot of wisdom at Microsoft that could be shared and try to make up to the world for creating a generation of basic self-taught basic programmers and that's that's my presentation of happy to take questions you can contact me on Twitter and you can also get ahold of me I post occasionally on Twitter but it's the easiest way it holds me and I I'll answer questions but first I want to actually give away a copy of the book there's other stuff is done the other book but if someone wants to win a copy so the question is I have a trivia question that you have to answer so that's a little old-school so Dykstra has talked the the was ragged on basic and saying that mentally mutilates people he also criticized for other languages that were current at the time and the question is can you name three of them three of the languages that Dijkstra was also criticizing yes in the back they're close two out of three still no not peskow what's up yeah one well okay what are the three tran peel one and Kowal yes that's right foreign feel in a couple so he did actually he liked algal algos likes a pretty good language it's really the the ancestor of most procedural languages C C sharp all kind of come from a level it's the first one with what seems obvious now but if statements with blocks of code after them which was kind of a big idea then really the first language didn't require go twos to write decent code yeah so he Dijkstra was on he didn't like COBOL Fortran PL one and an APL APL which is I mean it's sort of a programming language it's sort of a cross between a programming language and I and a cry for help but was actually was a serious language at IBM you came up with God knows why and and you know he of course I mean make fun of APL is sort of easy but but the text Ross was pointing out that there were other problems PL wons not bad actually I'm not sure why I didn't like peel one probably cuz he wasn't involved in creating it and yet some beef with IBM but yes he was against most of them except Algol and of course C was being germinate at the time but he didn't know it probably so there were a better languages coming along so there we go Erica my former manager in fact ninja excellence you have a you have won a copy of the problem of software thank you okay so I'm having to take questions if anybody has questions on that and like I said I have copies of the this book any other two books while I'm here if you want to improve your bug your code reading or figure out what happened in Microsoft in 90s you're welcome to come up and peruse those yes question in the back there I guess you know yeah it's very sweatshirt yeah yeah so you mentioned the quadrants a couple of times and so my question is sort of about technical interviews because in universities when we do interviews we tend to ask questions about that top-left quadrant right and it seems like to be successful you're talking about the bottom right quadrant so what should we do about this should we do doing interviews differently we're looking for the wrong or something else well that's a very good question so I think that so in that in a whiteboard interview you're stuck in the top-left quadrant right I mean that's all you have right you you can't whiteboard out anything that's at all complicated you know even something like an API design you can talk about our API API design maybe testing kind of get a little bit into the other ones but you do what ask people coding questions and and they're gonna be small of necessity I think what you could ask them though it's about experience part of what the book talks about is is I wish academia would focus more on these bottom right quadrant pieces of code in particular there's tons of open source out there now so you could just have a class where you were hacking on the Linux kernel or the Windows kernel is I don't know if the state of open sourcing Windows is but or anything there's so much open open-source software out there then you could have you could have people modified and read large bodies of code and try to make modifications and understand different styles so I'm hoping people will come out of college having done that and then you could ask them about you know tell me about a time you had to consume a large body of code tell me about how you'd approach this talk about something you liked or disliked and in somebody else's code so you could match more experiential questions about it because you could bring up some giant source code listing and interview and ask people to figure out what's going on but that's that's a little probably too too strict but hopefully they would have experiences coming out of college that they could talk about I once did a I was in an accident I actually had the ability to ask HR to look through interview feedback to see if people are touching on the the ten competencies in Microsoft had at the time one of which was technical axel and the others were communication and cross team and all those other things and like 100% of every single interview had asked a coding question and of the other nine competencies on average two or three were covered at any point during the during the day and the other six or seven was completely ignored during the interviews and these were theoretically the ten important things that Microsoft was looking for so I think in coding it's good to ask you don't it does not have to be about the coding question you can ask about tell me about a time you did this or worked on a team or how to design an API or consume an API and hopefully people have experiences they can talk about yes so you talked about Microsoft and sort of best practices and I just think it's similar to many companies which is code reviews and testing and design and documentation are there any good modern books on this stuff I mean how well the question is how well no and it like you're talking about why they make mistakes but how do we give our hammers to do a better job well there's there's um I mean a lot of books tend to be a problem a lot of books is they talk about something useful right but then they they present it as it solves all problems right so you wanted with sort of overhyped books that have a core that's useful but then they they overstate the the solution so book on unit testing will present unit testing is a the answer to all problems when I mean there's reasons you know there's things you can do with unit testing and things you can't do with unit testing I don't know a book you know I actually recommend what I prefer peel read is there's a book called making software which is about a bunch of empirical software studies that people actually studying software teams and saying we observed them and they did this and they did that and this work that's published by O'Reilly that one's pretty good empirical studies have sort of sort of died out unfortunately people actually studying programmers sort of anthropologically there's still a few conferences there's a but but that's a pretty good one making software but yeah I don't I don't know a book it's sort of in an OBS kind of way lays out what to do code complete a code complete to Steve McConnell's book which is you're 30 years old it's pretty good it's also backed by research like he'll actually say though the right length for a method in number of lines of code is X because somebody study it not just because I feel that way unfortunately his studies are all kind of old because people stopped kind of stopped doing that yes so you mentioned that you believe today's generation writes better software than previous generation core writes the software better any thoughts what we could do today to prepare for the next generation and I'm asking because I'm also working in a team that well yeah it's there I mean I mean that one of the points is that but if you come out of college and you haven't learned this stuff and you've been successful in college and you got a job Microsoft let's say interviewing with skills you tie yourself in in high school you're you're kind of already thinking that you know more than you probably do and it's hard to change so I I think I wish Microsoft would would go to universities and say this is a curriculum we want I think when Microsoft has done that they focused more on specific skills like hey you you should all be using Windows and c-sharp and visual studio with your classes that's not what I'm talking about I'm trying to get them to say you need to work with larger code bases need to you know teach debugging and teach code reading like all this stuff that the actual skills we care about without without coming across is would you just do our job for us like we're tired of training people we want people who are perfect when they come out of school it's not gonna be like that but I wish there'd be more closing this this gap between academia and industry like I said appeal show up I mean you know if someone comes in and thinks they're you know they're God's gift to programming it's it's it takes a while to disabuse some of that knowledge unfortunately I mean it's something good interview for you could you could try to bias against you know lack of humility excessive hubris during an interview III would think about that if they if they think they're you know a genius at age 22 they're they're probably not and when we come out to college like we go into college and take the C s classes knowing that everyone says you don't learn the right skills for industry in college like we're told that straight up front so a lot of us do come into an industry and we expect when we know and we do learn a lot and we talk to each other about all the different things aren't learning so there are those kind of people but they're also especially with like the newer generations especially as colleges are trying to improve their CS classes they're not going to get everything right there's only so much you can teach people like not in the field I guess I just want to say we are training that's actually great to hear and there are things you do get people who come - who learned to program in college right they show up they're not the high school computer club graduates right no it's great I mean I knew one person like that in college it was like what you didn't have a trs-80 or whatever I mean you know what are you doing here and I'm and I mean we did not treat that person well also I you know like looking back we were we were obnoxious about it but but you feel like hey you know I like I like playing games on my game system I want to be a programmer then there and they're just come in kind of which is great and I think people like that because they are exposed to it at least a more formal environment they're not reading a basic manual at least they have some instruction and some guidance tend to be more open to the idea of wow I have things to learn they probably still get this mistreatment of the hardcore geeks looking down at them so I'm glad you made it through and are here but it is something else you can work out just try to make it more welcoming to everybody yes so I have a question about the viewpoint you take over there so for one thing that's them assuming is but it feels like generationally we've gone 50 years even for a software engineering and it feels like what exactly are we looking for with such a silver bullet is it too purple I ability bugs like I feel like the goalpost keeps moving cos if honestly if you did try to program windows in the Senate language and like today's Windows you wouldn't get very far right so something was achieving with all those extra like tools and languages that we've created that has improved the world right so everybody knows that they have been achieve all the silver bullets have value in some cases right the phone with that thing does have value you know structure programming is better like DevOps is useful in some cases it's it's not people don't have the ability to discern like when I should use this language so they just write everything in Perl for example you know which pearls a great language for box top left box and it's an absolutely abysmal language I worked on a team some of whose members are sitting in this room today that maintained large pearled code bases in Isha's to giant hassle but you know it kind of grows like organically so I think that the reason people search our Silver Bullet is because they realize that software is hard and they don't at some point they realize well I don't know everything and it kind of you know any port in the storm kind of thing like oh wow maybe DevOps will solve my problems like that they'll be nice so they you know they follow these you know charismatic sort of solutions optimization you can point to the tree you say it's about this ruin you're probably right so in terms of software development though so are you saying that I guess we're in the process of developing software using to thinking about education like what kind of guidance would you give to making the judgment call whether or not to spend those time and resources like implementing code that would only actually really be used in education to know that educators and really have been very often edge cases I've gotta talk about pre-optimized basically saying well this might run slow I better optimize it now right I mean so in those edge cases I mean my apply space would be would be don't do it I mean I mean write the code cleanly make sure it's understandable focus on that maintainability and then if it gets deployed and it's slow worry about that you know essentially that's my answer like it's so hard to know if it's actually going to be slow and if that code is going to be on the critical path that messing it up just in case is is not a good approach so my advice really being don't optimize it right as cleanly as you can and worry about it later that's you know almost always the right answer and when you're you're old school manager says oh no we should you know we need optimize it now then well I don't know that's it that's a tough that's a tough question the existence of old-school people in the upper echelons of Microsoft not everybody but floating around the upper echelons of software companies it's an issue because they have they have the wrong instincts in some ways because they're too old-school yes in the back oh sorry got a second question computer world is that there's this there are two camps there's an academic camp and there's an industry camp and you talk about that separation is part of the problem so right here at Microsoft we have like we have the research this workplace but we also have all the other programmers working online or software engineers working on like future work in paints what would you recommend like the things Microsoft can do to make me pretty psyched out do you think that needs to be British do you think well I think I think I think Microsoft there's enough software being done at Microsoft that research you know and even said thing about how you used to study software developers another like oh he used to okay you know I mean I think Marcus I wish research or somebody at Microsoft agree search would turn around and look at Microsoft really try to synthesize some wisdom about when is what language is appropriate for what situation yeah when should we get rid of software and you know how do we analyze the lifespan of a piece of software because there's really a ton of software inside Microsoft that you could look at without having to go outside and look at open-source so so I I I wish Microsoft would do more that I mean engineering excellence went away Wow five years ago or something probably for good reasons but it did we did lose a little bit and the engineering excellence wasn't really doing that as much as it should have been either but I I wish Microsoft would would think about doing that kind of study going back to your first question for optimization one of the best pieces of advice I got given by one P old-school programmers who had changed their life do not optimize anything right these simplest code easiest to maintain we have profilers that will tell us exactly where we need optimized but we will spend far more time reading this code and maintaining it that we ever will writing at this one time make it easy to deal with in the future how many users you have possess establish a product or not because I agree with you if you write new product you just do and then you equate that one person objected to me he said in Microsoft Word we basically because it's one of the mostly used software we hit every problems that could be an optimization was hit because it's used by so many people it will be hit so more later but that probably the only example I usually talk to my my mind so the feature that my team we had in the design phase we try to think of different educators and we didn't think too much about Italy we didn't look seriously at the code because like we put it in but because we thought it was an edge kids mm-hmm but then recently we got a lot of hot bugs because turns out these edge cases just like you said they're just so many users who use them but you will hit that educators at some point those educators their edge cases for a reason they have preference and then there are some edge cases which we didn't even think of yes I am the study I will tree first you do Ranger look folks it depends on the size of your project how many just you tried together the morganson you see when you can it also depends on your experience based on your past experience sometimes it's personal experience you build your hands on something and you try to activate one since the senior engineers just have this intuition like their videos been cooking for a while and so they have a sense of body this is probably what's gonna happen if we don't deal with it now and therefore this is what we should focus on not this thing yes it comes from your past experience and sometimes our strong it does yeah you don't cancel iteration like that is always correcting like the focus it's not so I mean yeah yes you you do get some incentive and also just you know how to design things cleanly to I mean people may be airing to design something clean an API that's easily consumable but they might do a bad job but if they have experience you get better at that sort of things so yeah there's value in wisdom I'm not saying all old-timers should be should be marched out the door yes what yes so going back to yourself or engineering the fifty years and so they're giving people like par Ness and others who said well you know if it's really gonna be software engineering then where's the certification and I guess another way to look at failure is that we don't have such a thing but there are certain disciplines right where like safety critical systems and things were there there there's a huge amount of discipline and rigor I although I think with IOT in medical instrumentation were in danger of like that hope and also be coming consumed by maybe a hackfest but what but I guess my top level is like do you think software engineering certificate is worth anything what would it sell what would you know put what would you put it in and our there disciplines where so I think that we absolutely should have software certification and licensing but not today because we don't have the body of knowledge the ACM was involved in some projects put together by others knowledge but it's really just kind of like brain dump of ideas about software development there's no academic backing so I think we absolutely should have software engineering certification at some point and licensing but we need to be nice to set it as a forcing function like in ten years we'll have it now we got to go fix the problem but I'll have to actually work but so I think yes we should be licensed there's lots of things you could learn and I mean even you know security is a big thing you know it's all there's all kinds of things that people make mistakes they just shouldn't be making because they're not aware of the potential so yes I think we should have it but people have pushed software engineering Steve McConnell wrote a book about about doing engineering licensing today I doubt what I think would be a mistake because there's just not enough actual rigor behind what you'd be licensed to people on so he license people give him a test but they wouldn't actually be better software engineers that's a result and I'm looking for some actual real wisdom that people could be could be tested on before they were licensed so the theme of the divide between academia and industry I spent a lot of time teaching other students at university and it and university professors are easy to make fun of and they sort of live in their heads in that Gardens or some of them have part-time jobs and they also work in them they do a great job of helping show the in-between but typically if you want to become one of those people that can start to disseminate knowledge at a university you have to have stayed at the University for a long time instead of going and cooking for a long time and actually getting your hands dirty and building up the intuition and so now it looks to me like you've got this divine where the very people that we want to be able to go teach at universities are barred from doing so so how do we approach universities what I mean I you know we're not like I went to Princeton and it was ready to Bell Labs actually we had them several of my classes were taught by visiting Bell Labs successors who were not trained particularly as as professors but they hadn't they had this industry wisdom right they had been working away at the switching code whatever and it was quite valuable to get their their input and then mix that with the more theoretical teachers then I know that there are some schools that I actually really try to the terms it's computer science and software engineering are often used interchangeably big schools call it one or the other but there are schools really try to teach software engineering I know the Olin College in Massachusetts is really trying to focus on that we got to actually bring in some industry people and like teach what we can about software engineering so I mean I think hopefully universe will start to worry about this and more of them will say hey there is a difference and there's theoretical computer science which can be useful in some cases and there's software engineering and we do want the interested people to come in and we won't worry about do they have a PhD or are they published or whatever you worry about when you're hiring a part of my father is a professor so you know I don't have a negative view of professors he was a math professor but you know I mean there is there is this focus not academia on publishing and then and things like that it's not necessarily what's needed right now for for computer science yes if what we know today is like why do we you run a lot people in in today's practices right out of school as opposed to just you know encouraging them to be I know problem solvers and then just I don't know what's what well we know today will be proven wrong it'll just be shown to be not quite as right as people thought it was and I think it's also value in basically knocking people off their pedestal a bit off down a few pegs when they when they were in school this forest people learned something I mean I basically sailed through school with my self taught basic programming skills right I mean I I learned some algorithms but all all everything about getting my code working and laying it out no it was just what I figured out as a basic program which is which is which is not a good thing and so I think just teaching people anything teaching a different language you know like getting this idea that oh wow there is something to learn is very important just so they come in open to the idea that they don't know everything it's sort of like you know I compared it to medicine like if someone said I'm a doctor I didn't go to med school you'd be like well that's really concerning but you know if someone's a programmer and they're like well I made you to music or something which Microsoft has people floating around like wow that's awesome you know you are so smart but I mean it's like just as weird like what are you doing here how can a music major be successful as a programmer but they can because they can they don't still learn much I think just have a university curriculum where you have to learn something and study some stuff and like you know you have to pay attention to your professors to to be successful it would be very helpful just to open people's minds even if the specific skills aren't as as critical canonical in the sense that they would be industry people coming in and talking about DevOps practices like I don't know some random thing there that are considered to be like you know the current state of software engineering and that lots of people in one so I mean to be fair like the industry usually runs ahead of where academia is and DevOps practices are showing up in classes there's like a startup classes at CMU of how to do engineering if you're in a start-up which is a different set of strategies that you would picture a more established company there's DevOps classic North Carolina State University on specifically teaching fits out like University that's how did you go why is that not good it's it's like locking people yeah it's teaching them skills that they're they'll see and learn how would that when they get to industry they'll adapt to whatever they are going to be using at their company but and obviously the techniques and skills and processes that we have today are very different than those that students learn in school 10 years ago or 20 years ago or 30 years ago and that's okay we don't wind everyone learns through that what I hear I guess my feeling is I'd rather have someone coming in talking about DevOps and not come in and talk about DevOps because it's something from industry but I well I really what should happen is that academia would study DevOps and say this is what's real and this is what's bogus and then teach that but having a DevOps person come in is like I said better than reality is government funding for academic researchers and academics for the most part for our researches institutes have to partner with industry more and more there's a downside to that but it does you know it does help to bridge the gap I mean a lot of a lot of academics can't you know hope to have access to huge data centers right to do research on DevOps in say a data center cohn thanks without like maybe having a co appointment at Amazon or Microsoft then you see more of that I think I think there are some good parts of that so bad but but I think the notion of the ivory tower is is pretty dead these days I mean to be to be perfectly honest I mean you know the people who are doing theory you know there's a lot more systems out there so I think fundamentally the danger of anything is like we don't get the next great thinkers coming up with simple abstractions because everybody's sort of down it's working on our problems I fear more for that actually and I think magnetics are actually studying a lot of open source they're studying this law so I've a certain field over the last 20 years actually academics and oh that's gross they have got yukari's me but I still I feel Doug yeah I looked through curriculums and stuff and it seems like they're yo though they'll say what industry is talking about they'll talk about scrum or whatever but they're not they're just sort of presenting it as here's the thing you'll encounter they're not thinking about the researchers there's no no I've read a lot of empirical studies books and I make a big push for 20 years ago there's it's huge anymore between like a third to a quarter of the papers that you would see of any academic South Virginia conference there's so much more now I think it's very used to being almost nothing it's very funny you know it used to be more you know 40 years ago maybe if this comes back but like I said that make the software book is in a bunch of empirical studies which is great you know it is occasional but I mean maybe we have different experience have already seen but my stands talked a couple of Terkel studies people and you know they felt it was not it was still kind of you know it was it was surviving but it wasn't really booming you know I talked to Victor Brazil he is one of those sort of gurus of empirical just like it's anymore come you yeah and that's like that's two generations you should be poking the new kids on the block well I mean it was around in your retirement I'm just saying I think it's a little bit introduced you know if you're Pirkle size may come back that's wonderful I thought a lot about a vertical size in the book but I you know haven't quite seen it may as much as you have but that's good yes so one of the things you mentioned was empirical studies sort of start to feel old after 50 years so you people do these randomized controlled trials the Dukas EB tests and then about saying variable naming but then they start to feel old how do you keep these things fresh and like how do you keep them in the minds of I think you just I mean it may have empirical size of coming back that's great but you know you just have to keep doing them right [Laughter] no I mean you just keep doing in people if you recognize for it and companies have to have to start consuming an information you have to Microsoft has to have somebody come from a conference and say hey guess what Hungarian it's a crazy idea you know or whatever like which doesn't I did not observe that in a product group anyway people coming back from an ACM conference saying you know hey I'd learned some about software engineering so maybe it came to research but it didn't cross over at least them throw the group's I worked on my opinion unit tests are to allow you to refactor the code without breaking it that's what you don't test do and refactoring code is good so cleaning up your code is good so you know test guard against breaking your code accidentally regressing some other random thing I don't think they really help with overall software quality except that when your code is you're factorable it can help with the quality but I think there's a you know unit testing is not and you know it's not automated functionality testing but it's so important because having a retractable code is important so like don't throw it away they're cold because you factor cold and we need to rewrite in a test that's what yeah that's true and that slows down you to three times yes sir that's right yes but I think you just got to do it like it's part of the software is slowing down a bit because trying to be more precise about it right no there's there they're both useful for a different thing right and user testing is to make sure this thing actually works the way it's supposed to work and unit testing is so you can clean up the code without breaking it you know I mean that they're related but they're they're both testing but I think you know Ted they're both the unit testing is oversold as you can get end user functionality quality I mean I don't think they're that's not what it's about yes so in the industry now this is really strong trade-off between being able to write and should cook very quickly and they're gonna start up and the minimum or the maximum amount of bars you tonight that a customer will accept before switching to another piece of software feels like the idea that you're suggesting which is that software development in order to become reliable needs to slow down even further is and the better comes the idea that you need to go faster and faster in order to compute the marketplace only successful companies have the option of making reliable supper well I mean I mean you're right I'm biased in favor of more reliable software and against you know throwing something out there that to uh you know to hit the market I mean so I guess all right like yes a baby case is worth you can getting something out of quickly with lower quality is a good business decision but you know just like occasionally can build a bridge that's a little rickety because it's for whatever reason that's fine but but I mean again that's more business decision it'll be really nice if you could say I want this quality level and this speed trade-off and I could actually make some like pretty reliable prediction about it and just then it's just the business is and surely versus kind of winding up with something cuz you're in a hurry and you cut corners like well I guess that's what we're shipping because we got customers lined up with you that's not engineering at arguably speed these days comes from putting together systems rather than writing systems from scratch that the microservices model that you put up there that is a form of much of the software that's written to me those micro services don't take the aren't a huge amount of code but you do need to write them very carefully and writing them slowly and correctly is actually much faster because they perform you create the system faster from a lot of small pieces if those small pieces are terrible you have trouble no I don't think speed in software development anymore is about volume of the code I think it's about working components of code that work together with other existing it's fascinating when we study companies now for for cross lake I mean a lot of them are just like grabbing open-source components and I'm throwing them together like hundreds of open-source components and making software like it's sort of turning this like assembly line for a lot of it and it's just knowing the skill is knowing what to grab not that you know not actually writing these complicated code for each for your basic like it your database back website kind of Ruby on Rails kind of territory it's like there's not a lot of software but again I'm not I'm thinking about more like things like Windows and Office which are big and complicated that's what I'm worried about not some guy putting up a you know a clone of reddit or something I was sort of second the comment here which is open source also it drives out the economic incentive to actually test your code properly because you simply don't have the economic resources so if you actually look at the heart of some open-source projects you know I'm just saying there are economic incentives a year that go directly against our goal of building more reliable if you have no money you can't afford higher testers it's comes out and nobody wants to do the scut work of spending like half their time running tests for the new feature there's something they write the feature submit it with barely any testing is no you're right yes their economic incentives pushing against doing things the right way I don't deny that argument so all right JPL when like the job propulsion laboratory NASA they write a bunch of code too and so I read a really interesting article where it went into depth about the coding practices and how they write software for like space flights and space missions like for devices that millions of miles away you can't do bug that thing like you have to write any get it right the first time and so they went through it and so they have extensive documentation extensive testing a bunch of theory in there too just to make sure that because if the program goes wrong there's nothing you can do and that's like billions of dollars wasted and so I understand that's a unique circumstance but the article the point of the article is really trying to drive home the point that that's like the gold standard that industry should eventually get to the point where maybe we can also get to that so like there are economic incentives and especially if you're doing a start-up and you have like a new idea you to get it out before anyone else does it but like there are it's not impossible like it is impossible reality that we could get to the point where the way we do software development is as rigorous and like detailed and like extensive testing it like you can imagine merely funneling millions of dollars into making this device and for every extra gram or pound you have that's another like billion dollars in jet fuel or something so those are extenuating circumstances but I think we're in a unique circumstance given where the interest you have is right now that we have really big companies with a lot of really big resources that maybe we could spare those like extra days weeks or something - maybe I don't know I'm just saying there are there are examples that exists like currently exist where they are more or less be gold standard for the ideal case of software testing so totally agree with with what you're saying and I'd love to see a variance of this doc or making six ratings in stock were you go one abstraction level down into particular industries hmm because there's Stoppers not when doing thank anymore so to look at startups to look at rocket companies to look at power companies plane companies we see like how is it different across those companies with different economic trails in different safety trade-offs Debbie a lot of stuff is you know it is known how to make reliable software people just don't choose not to for a variety of reasons economics they don't know it they don't want to deal with it they're being successful without it you know whatever they tell me but there's a bunch of things but yeah I don't think there's like a it's not a huge mystery nasarah how to write better software I mean JPL which is where a lot of empirical studies were done was like you know yes they they knew they needed to make it right so anything they took the effort everybody's bought into that because the project wasn't the right decision sure I like to move to engineers to move to engineering I think that the argument was that well testers are limited because they're they're in this box you can only do testing and and so a lot of people who were worth like not able to do as good work as they as they couldn't have just reduced flexibility because as a manager you couldn't move people around so and of course most of the testers were trained as software developers so they could do the work it's over I think it's a good idea it's more efficient it removes some friction you have there were issues of course some - didn't want to write tests some teams just interpret it as we're just getting rid of testing and everybody's right in code I mean so there's there was some implantation uses but yeah conceptual like the idea I mean I think Deb should own quality not throw it over the wall to a separate team so I mean so so yeah I like the idea you know like even if it wasn't necessarily perfect in all cases I wish I wish more former test leads had become the engineering managers instead of basically the dev leads usually doing that even though I've you know that's what happened to me but I was a deaf leader became a manager but like yeah I think it's a good idea for all this team it's like half of the people actually work on these four starts to supporting the creation of the test cases and and I don't play Google has created a world where so thoughts they worried their infrastructure team the team that's you know does that stuff is somehow they've created a world where that is valued at scene is almost more important than than doing the product work and I don't know how they pulled that magic off but but - just Google's culture it's like it's like a a privilege to be allowed to work on this important stuff that supports other developers doesn't have that culture and so I think as culture for decades that effect disability do things and so one last question I think back here may I wanted to comment on it the most convincing argument for me for this unit testing and TDD silver bullet was actually that the value is in testability and not the test they these tools that they provide and the procedures are helping you to write code so that you can test it testability the value is not necessary if you have five or 500 but now your code can adapt it can change and that's I think the same argument for micro services you can all of it if you have tested it or not if you're in a start-up and and write in testable you might not have it now but you you have a path forward to do it and and so then that weird argument that's sort of upside down is like you have to write it in a way that you can adapt and change and compose that that's where the real value is and that doesn't like even though that just a ticket old dental ideas are longer I think that's that's for me a big learning being a right code so that you can test it that you can evolve it if that's a separate organization that drives this or if all engineers have to have this that doesn't matter it's that the methodology behind the order the the tenants behind that method is that dick-read no it's getting the test done it's not just support who does them you
Info
Channel: Microsoft Research
Views: 4,096
Rating: 4.9120879 out of 5
Keywords: microsoft research
Id: AkQlbmGlrms
Channel Id: undefined
Length: 84min 46sec (5086 seconds)
Published: Mon Feb 25 2019
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.