A Complete Waste of Time - Chet Haase

thank you what a beautiful venue here I feel so guilty giving a very serious business presentation it's really more suited to opera or comedy so let's see if we can go here come on [Music] alright time for my favorite joke how many engineers does it take to set up the AV system in a room alright let's go today I would like to talk about quality but not just quality in the words of Steve Ballmer quality quality quality quality quality quality quality quality quality quality quality quality quality quality or as I like to refer to it q14 someone pointed out to me that there's actually 15 so we're gonna have to take a look at that acronym I'm Chet Haase and I want to talk about how you can achieve quality and your software organization just like I have so we have a full agenda to cover today first of all I'd like to tell you a little bit about me because I'm sure you'd like to hear that next I want to define what quality means to everyone globally and then I want to talk about what quality means to me because again you care what I think then I'm going to cover a very important equation because I think that any presentation is enlightened and made more important proportional to the number of Greek letters that you use in the presentation math is good for Greek letters then we're going to cover some important quality metrics charts and data because we're engineers we understand data and data makes truth then we're going to cover some common misconceptions and quality things that you probably think are true and yet they aren't and finally what can you do to achieve this quality but first let's talk about me I'm Chet Haase I work for a company called chet haase quality consultants incorporated I am the president the founder the CEO the CEO the CTO and the Chairman I'm also a consultant and the sole employee I've been doing many interview in many years in engineering and also many years in creating bugs now that's an important fact we're going to get back to this all those years I was doing software engineering I was writing bugs this is sort of software anonymous my name is Chet Haase I create bugs however for the past four years I have been doing silly presentations on quality which means that I am not writing code which means I'm not creating bugs and you are going to find out how you can achieve that same level of quality and your organization finally I'd like to point out that this year I received a certificate of quality I'd like to show that to you now there's a couple of important things to notice about this first is that it says quality not once but twice next is my name which means it's mine and the third I want you to notice the fine level of detail in their certificate if we zoom in you can see the level of quality just in this certificate alright so what do we mean by quality well it's best to step back to the roots of words to really understand what their meaning is if we break up quality into its Latin roots we get qua which means what we get I T which is i T and we get Y which is y so if we put these together it's what ity which I think it's pretty clear but what does quality mean to me so does it mean tes lots of different tests we could run there's a load test there's all these other kinds of tests that we could run all the time is that what we mean by quality yes it is you can't have quality if you can't verify that you have quality do we mean metrics do we mean graphs important graphs showing that as the number of defects or bugs goes down the level of quality goes up again yes yes we do what about eliminating bugs is that what we mean by quality no it's not because to eliminate bugs it means that you had bugs to begin with that was your failure now I want to talk about a quality process whereby you will have no bugs to begin with therefore no bugs to fix so here's an important equation that I want to cover I cover that call this the equivalence theorem of code or Etsy the number of bugs represented by B equals the number of lines of code times the number of files in the project times the number of statements times the number of condition statements and we square all of this just because we should it's a math equation and the most important part is we introduced a Sigma in here to take the sum of all of this as X goes from zero to infinity now YX is there I don't know but these summations usually use X and they usually go to infinity and then finally this is probably the most important part we add in an error term because we're software engineers it's not really engineering we're just making up [Applause] and then you get the definitive answer to the number of bugs now the important thing to notice about this equation is that of course the number of bugs is directly proportional to the amount of codes as you see on the right-hand side we'll get back to that first I want to talk about some important metrics so where do the bugs live in the code there's lots of places that they could live in any project they could live in the documentation they can live in the specification to begin with maybe there's problems there what about the memos that we send each other in the office or the emails in which we describe software maybe somebody's desk drawers perhaps on the monitors on the post-its where you write your password maybe it's in the conversations that we have in the hall or the meetings that we have with other engineers on the team or maybe just maybe they are all in the code that's an important metric right there and I know because I made it so who writes the bugs in a software organization what about the people in the sales team or marketing what about the administrative staff how about the security guard or the people that clean your offices how about management's now there's an important point we worked with an organization where management introduced some bugs there were some managers who used to be engineers and thought that they could still write code and so they did they wrote the code they introduced some bugs and then they were no longer at the company how about the accounting department probably not what about engineering that is where all of the bugs come from right so we're zeroing in on the core problems here aren't we all right what about code versus bugs well here's an important chart so we worked with several organization we aggregated data and we can see that over time the amount of code in these organizations grew almost monotonically right whereas the number of bugs grew exactly proportional to that except for an anomaly in the middle you'll see that there was a dip in the amount of code and a rise in the number of bugs now what was going on there it turns out that an engineer made a mistake deleted a whole crap ton of code and caused even more bugs than they had before realize the mistake next day check the code back-end code went back up so did the number of bugs all right so what we want instead of all of this stuff going up all the time is for the number of bugs to go down over time instead and to do that we need to bring down the amount of code I think this is pretty obvious by now all right so here's some common misconceptions there are things that you probably think you understand about software quality and I'm going to prove you wrong I call these the believable solutions or BS first of all there's the creation of guidelines in the attainment of top excellence or what I call cogitate we first identify the processes by which we will write the code and then we document these approaches very carefully we form teams to discuss all of these processes and methodologies that we all understand it we present the findings to the overall department and organization and then we have explicit training to teach engineering how to carefully follow the specifications guidance and processes and then the engineers write the code so if we look at all of the steps in the cogitate methodology we can see that all of the ones at the top don't introduce bugs because there's no code being written and then the engineers write the code that's where the problem lies how about better specifications or what I also call BS we start by comprehensively itemizing all of the requirements for the projects we identify the problems up front so we can see what's going to happen in the future we identify it so we can do something about it we propose solutions to those problems and then the engineers write the code once again we can see that all the top ones don't create any problems because nobody is actually committing code however the last one does that's where all the bugs like then we have the code review approval process or crap [Applause] so here's the way you think code reviews work there's an engineer that writes some codes and then there's another engineer that reviews that code probably sees some bugs make some suggestions then the first engineer fixes all those bugs and then the engineer submits what should now be bug free code because the bugs were caught by the reviewer right so it seems like there's probably bugs that were written to begin with when the engineer wrote so yes we're dead on there and then there's a review there's no bugs created because there's no code written and then the engineer fixes the bug so there's no bugs and then the engineer commits the code no bugs and we're all good what the way it actually works is they create bugs to begin with when they write the code there's no bugs created in the review process again if you don't write code you don't write bugs and then the first engineer writes some new code creating new bugs along the way and then they commit it and there's more bugs created right are you following me through all this it's very complicated I wouldn't be surprised if you're lost I am all right what about product management supervision or PMS in the pms methodology we have a product manager that identifies the features that customers require and then tells the engineering department to implement those features then they track the features through to implementation typically by a process that goes something like are we there yet are we there yet are we there yet and then the engineer writes the code so the first step we identify the features no code written no bugs we tell the engineer departments what to do no bugs are created we track the feature implementation no bugs are created the engineer writes the code and there's the bugs finally we have work hours is never-ending which I call wine in this one the engineer writes some code causes some bugs feels really bad about it stays late to fix those bugs a for effort F for result creates more bugs because they wrote more code then the engineer gets tired and writes even more codes and creates more bugs in fact creates many many more bugs because they're tired and then the engineer falls asleep no bugs all right so all of this boils down to the simple relationship that code leads to bugs so what can we do about this in our organizations how can we use this important relationship which I for the first time had pointed out to you so I call this fixing the problem the original acronym was FTP I didn't like that so now the acronym is hero so here's a typical software organization I'm going to teach you about the reorg methodology so we have management structure we have a whole lot of Engineers reporting into the managers engineers have workstations they're all on some intranet going through a router that connects to the internet type of D type a T type in e check in the codes bugs are created right so what can we do about this first of all we work with organizations to eliminate the internet however that doesn't go far enough because the engineers probably have other ways to access the internet they probably just go to a coffee shop outside so we make it a little bit harder for them to talk to each other we eliminate the router and the intranet so now none of these machines or networks that makes it a little bit harder however they can still type it e type it e type so then we start taking away their machines however their engineers they probably have more machines than toes so eventually we end up in all organizations that we work with that want to pursue quality just eliminating the engineering department entirely so there's another step that you can take in your organization organizations grow all the time they need to hire more people you'll always need more resources to achieve more productivity right well there's the methodology that I call hire more managers or there are things that managers do and there are things that managers do not do they manage people they don't write code they attend meetings they don't write code they talk with other managers and they don't write code they facilitate cross-functional growth strategies and interdepartmental team facilitation for the purposes of collaborative interfacing and Department wide coordination but they don't create bugs so hire more managers start today hire as many as you can don't use those heads on engineers they're just going to create bugs what about sales you're saying we still have to sell a product we still need customers we still need revenue to make the paychecks how are we going to deal with this I call this was so here's the timeline of a typical product you have release 1.0 it goes out there everyone's happy but you realize there's bugs in there so here release 1.1 there's still bugs in there plus some new features need to be implemented so you release 2.0 o more bugs to dot 100 more bugs to dot 200 more bugs 2.3 and this is when we have what I call the corporate realisation of quality epiphany or cork this is when you realize that no matter what you do you're just going to generate more bugs but there's another solution right you need a new release but you don't need more bugs so you simply release 2.3 again but you call it 3.0 now you haven't fixed the bugs that are in 2.3 but it's very important you have not introduced more bugs along the way you've reached a steady state a bug equilibrium and I don't know what the acronym for that is after that of course you need to dot release because that's what customers expect and that's what they pay for so again you release 2.3 is 3.1 and on and on it goes alright so what you're asking since you're probably all engineers in here what about engineering all of those engineers that lost their jobs in there okay I call this week so here's the progression all of a sudden you're not doing any more coding which means you're not creating bugs which means that you're creating more quality on a continuous basis which means you're developing expertise in quality which means now you are experts in quality and now you can give presentations on quality [Applause] just like this one right we have a few minutes for questions I hope we have some good questions in the audience I'll see what I can do to come up with some good answers so this is the question period I call this queue please how can I solve your quality problems I can't eliminate you from your organization directly but I can certainly recommend that to your management anybody someone's got to be first I'm not going to go away until someone asks a question or they kick me off the stage are there any conferences for managers when all engineers have been eliminated all of the conference's will be for managers thank you how about QA you know you still need QA to verify that you have quality as I said tests are an important part of the quality process so even if your re-releasing 2.3 you still have to prove that its release 2.3 so you keep the entire quality department they just rerun the tests every time on the same codebase over and over they get so good at that job they're really they're fantastic at their job after the 50th time they've run the tests on the same release yeah yeah QA is great sorry what what if the QA czar engineers you know it doesn't matter if you're an engineer as long as you do not write code that's the important part you can call yourself whatever you want as long as you're not committing code then you're not committing bad quality I missed that entire paragraph can we that is an interesting idea okay so the idea is that you can have engineers and you can have them write code but not release the code like I kind of like that it's devious you keep them occupied you keep them happy because they think they're doing something

Channel: Devoxx

Views: 4,650

Rating: 4.8133335 out of 5

Keywords: DVXPL19

Id: IEQj8ZxHejo

Length: 20min 57sec (1257 seconds)

Published: Wed Jul 31 2019