okay so um they were kind enough to give me a laser which you can see nice green laser life is good you you got a green laser um this is a defraction grating my um children my oh this should be good up here it fell see there how's that can you hear me okay yeah all right good this is a defraction grating my grandchildren procured these to watch fireworks and it turns white light into rainbows uh and it works because um there are many Fine Lines drawn in here 18,500 per inch and they are drawn both vertically and horizontally now if I take my laser and I shine it through the defraction graving I get that why because it's laser because it's a laser and that's a good enough answer isn't it oh that's a laser that's why so what's happening here is that the laser light is passing through all those thin lines and it's separating into a bunch of wave fronts yeah the the laser light is made of waves and as those waves waves pass through the lines it creates a whole bunch of many different wave fronts and those wave fronts interfere with each other what you're looking at there is an interference pattern and it interferes constructively where you see a DOT and it interferes destructively everywhere else it's a nice pleasant interference pattern but now I'm going to take my laser here and I'm going to turn the intensity down way way down so so far down that the laser can only fire one Photon per second remember that light is made up of particles and those particles have discrete amounts of energy so it is possible to reduce the the brightness of the laser until it's firing 1 Photon per second now let's say that you could see one Photon hitting the screen so here I'm going to take my one Photon per second laser and I'm going to pass the single photons through my defraction grading what will I see on the screen inter will I see an interference pattern H I cannot see more than one dot per Photon because the photon must deposit its energy at a single point that is the definition of a particle so I must see on the screen a DOT for every Photon but what we do see is that the dot will be here and then here and then here and here and here and here the dots will appear all over the screen in a random [Music] order but if you add up all those dots if you were to take a camera and open up the shutter and just allow the camera to watch the screen for an hour it would collect 3600 dots and then when you developed the film that's what you would see the dots appear in the same place place with the same frequency notice how some of them are bright and some of them are dim that's just because more dots are appearing in the center fewer dots are appearing on the outside now that is an interference pattern so the interference pattern must be there even when it's a single Photon the single Photon must be passing through the defra action grading separating into a whole bunch of waves all those waves must be painting an interference pattern on the screen but not one you can see and then the photon must deposit its energy at a place where the interference pattern is brightest and it does this somehow randomly because you cannot predict from moment to moment where the dot will appear which means this pattern here is actually a pattern of probabilities it shows you the probability that a photon will land in the middle or that the photon will land at the outside the brightness of each dot is the probability that the photon will land in that spot which means the interference pattern is a pattern of probabilities which means the waves are waves of probabilities and that hurts my brain so I'm going to stop talking about the talk I'm going to give you is a talk I've given many places and many times it is called expecting professionalism and before I begin it let me introduce myself slightly my name is Bob I've been a programmer since well for about 50 years uh I wrote my first line of code if you could call it code in 1964 [Music] my mother had purchased for me a small plastic computer this computer had three flip-flops three bits they were little plastic things that slid back and forth they had a one and a zero painted on them three bits it had six and Gates these and Gates were metal rods the metal rods had Springs that would pull them towards the flip-flops and there were slots in the flip-flops that the metal rods could fall into if the metal rod fell into a into the slots on the flip-flops it could engage a mechanism that would change the state of one of the flipflops it was a 3 bit finite State machine but you could program it you can program it by slipping little soda straw tubes short little stubby soda straws onto pegs on the flip-flops that could block the endgate rods from activating the the device and and so you are able to write to program it to um count from zero up to seven the most you can do with three bits there would be another program that would allow it to count down from seven to zero and then back to seven again another program allowed it to add two bits yielding a sum bit and a carry bit a true full adder and there were many other programs that you could put into this machine I found this frustrating because the manual that came with the book did not tell you how to program it it just showed you what programs you could put into it and I had to put those programs in without understanding them and that bothered me at the end of the manual there was a a little paragraph the little paragraph said if you want the advanced program progamming manual send in a dollar and a stamped self-addressed envelope and we will send you the advanced programming man so I stuck a dollar in an envelope and I gave them a stamped self- addressed envelope and I mailed it into them and 6 weeks later it came to me 6 weeks cuz we didn't have Amazon in those days I opened it up and inside there was this little booklet I still have this booklet I keep it in a plastic Ziploc bag and I opened it up recently and I read it it is perhaps the most competent definition of Boolean algebra written for a 12-year-old than I have ever seen it has perhaps 20 pages and in those 20 Pages it outlined the basics of Boolean algebra starting with Boolean variables ven diagrams Carno Maps uh asso iives and distributive property uh demorgans theorem and after you've walked through all of that it's said okay now that you know how to do a little Boolean algebra here's how you program your machine you write down the truth table of how you want the bits to change you convert that Bo that truth table into a set of Boolean equations you use the tools of Boolean alge algebra to reduce those equations to lowest terms and then here's a little table that will tell you from those equations where to put the pegs the tubes on the pegs I had a little program in mind it was called Mr Patterson's computerized gate I wrote down the truth table I converted into Boolean equations I reduced the ab Boolean equations to lowest terms I put the tubes on the peg I cycled the machine and that machine did exactly what I wanted it to do and I was a programmer that was it I had made the machine SE my slave I was its master I was the god of the machine I felt the power I was a programmer and I've never wanted to be anything else since this probably happened for you there came a moment in your life when maybe you were in a store somewhere and you walked up to a a Commodore 64 or a Radio Shack computer and you typed a little basic program that just printed your name infinitely and you would yes I am the god and you wanted to be a programmer from that point on many of us wanted to be programmers because we felt the power of making the machine do your bidding we have a problem you and I how many of you are programmers so this is most of you good some of you aren't somewhat suspicious you have a we have a problem this problem is that um we do not have a profession we have I'm not sure what to call it what is it um a job a task but there are no ethics we have never defined ethics to our job we have never defined a set of practices or disciplines we cannot say that we have a profession because there is nothing that we profess and this is a problem because we rule the world we didn't know this we didn't want it but but it has become true you and I programmers we rule the world other people think they rule the world but then they write the rules down and they give them to us and we code the rules into the machines that make our civilization work our society depends now for its existence on computers everything happens inside of computers every significant commercial transaction any significant law that is passed any kind of traffic on the streets any kind of air traffic in the air anything that happens in our society happens through the agency of a computer and we are the ones controlling those computers how often does a person in our society interact with a piece of software and I'm not talking about technical people I'm talking about grandmothers of often do grandmothers interact with pieces of software and the answer to that is probably once a second anytime they use their phone anytime they look at their watch anytime they use a microwave oven or a dishwasher anytime they get into their car how much coat is in a car 100 million lines of code in a modern car 100 million lines of code in a modern car and you guys that should scare the heck out of you cuz you [Music] know my wife has a car it's got a front looking camera and it can recognize uh the lane markings on the road and so it it will identify if you're in the appropriate Lane position and if you drift out of the lane like you're falling asleep it will tug the wheel back the software controls the steering wheel what will it do on February 29th have they tested that how many people have died in cars because software failed many the answer is many toy just paid out a big big uh um penalty because a whole bunch of people died in their cars and the reason that people died is because some poor software guy uh didn't calculate the size of an internal stack properly and every once in a great while the uh internal process blew the stack and corrupted a piece of memory that belonged to a process that controlled both the break in the accelerator and the cars would accelerate into trees uh number of people have been killed by software and so we have to come to grips with the fact that we are killing people we didn't get into this business to kill people we got into this business to print our name infinitely on the screen but we are killing people and Society does not quite recognize this yet not quite yet we don't quite recognize it yet Society does not quite understand just how important we are but they're beginning to learn even a few years ago software developers became fairly notorious um when's the first time a software developer appeared as a major character in a holwood Hollywood film Jurassic Park Dennis Ned and he was the villain we had by 1990 whatever that year was sometime in the '90s software developers had become a the society had become aware enough of us to name us as a villain which is interesting I was in um Stockholm last year visiting the guys at Mo you know the guys who did Minecraft and uh I gave them a lecture and that was on and then we went out for beer and we were sitting in a lovely little beer garden middle of a little stockh home surrounded by a fence and we're just chatting and drinking beer and up walks this kid actually runs this kid runs up and he points at one of the programmers who happens to have red hair some of you may know this guy his name is Jeb uh if you track the Minecraft world Jeb is a is a uh somebody who's well known and this kid walks up and says you Jeb and and Jeb kind of nods and says yes I am and can I have your autograph and you know Jeb writes his because it happens to him all the time he writes his autograph our children have begun to see software developers as heroes from villains to Heroes there are children alive today who are 10 years old who aspire to be programmers that's an amazing thought but we achieved the Pinnacle a few weeks ago when the CEO of Volkswagen testified before Congress and Congress asked him why was this nasty code this lying cheating code put into these cars and the CEO of Volkswagen America Amica said well we really don't know it was just some software developers who did it for whatever reason now that was a stupid thing for him to say and it was perfectly transparent on the other hand it signifies something very interesting we have graduated to the status of scapegoat CEOs can now tell the world it was our fault and here's the thing about that there were software developers who put their fingers on those keyboards and wrote that code that lied and cheated software developers did that and we should be offended you and I should be offended that those software developers Dishonored Us in that way we don't have an ethical structure yet that would allow us to do anything about it but we should be able to do something about it we should be able to say those programmers cannot be programmers anymore they have stepped outside they are no longer programmers in good standing they have violated the ethical contract that we have with our users there will come a moment probably not very long from now when some poor programmer is going to do something stupid and he'll kill 10,000 people and you could imagine it it's not that hard to imagine right what driven by software could kill 10,000 people name a bunch of things there's a lot some poor software guy is going to kill 10,000 people and the world will react Society will react and say hey this can't go on and the politicians of the world will rise up in righteous indignation as they should and they will Point their finger squarely at us you'd think they'd go for our bosses but they won't they'll go right to us cuz it was our fingers on the keyboard and they will ask us the question how could you have let this happen and we better have an answer for them because if our answer is well you know you know my boss said I had to do it and we had a deadline and and so I did it if that's the answer then the politicians of the world will do the one thing they're good at they're not actually very good at it they will legislate they will pass laws and they will tell us what programming languages we can use and what processes we have to follow what books we have to read what signatures we have to get what platforms are appropriate for us and we will all end up working for the government this is something I would like to avoid and to avoid it we will have to do what other professions have done in the past professions like doctors and lawyers and architects who manag to establish a set of ethics and a set of disciplines before government got to them if we can do that if we can get there before the government does then when the disaster occurs and the disaster will occur and the politicians will rise up in righteous indignation and they will Point their fingers at us because 10,000 people died but if we can say this was not due to our negligence because here are our disciplines here's the standards we follow here's how we enforce those standards this was an accident or it was Mal fence but it was not our industry that is at fault and if we can say that we might be able to bypass the worst of what the politicians will do to us so what would these standards be like what kind of ethical principles should we follow I'm going to transport you to a world where I am your new CTO don't worry I'll let you out of that world soon enough but for the moment assume that I am your new CTO I'm going to tell you what I expect of you and you will hear these these expectations and your brain will react two ways at the same time the normal part of your brain will say perfectly reasonable good expectation the programmer part of your brain will react by thinking I'm completely insane Watch What Happens first expectation I expect that we will not ship this is a perfectly reasonable expectation but I see the little smirky smile I know what everybody's thinking oh yeah well sometimes you know so I'll State the principle we will not as a matter of Ethics we will not knowingly ship code that is defective or substandard and this is not something that you have to get permission to do you do not have to ask your boss is is it okay if I don't ship today because you were HED because of your knowledge you were hired because you know how to ship good Cod so you don't have to ask per for permission this is expected of you and it is not expected quite frankly that you would do this in order to meet a schedule or to to yield to pressure that is not expected no one expects you to violate a base standard of work you may think otherwise but ask them you didn't expect me to ship to you this principle is really just saying do a good job do a good job every day do a good job and you know what a good job is you know what it looks like you know what good code looks like you know what code that works looks like do a good job when you go home you should be able to look in the mirror and say I did a good job today you won't have to take a shower sometimes we go home and we feel and we have to take a shower I expect that we will always be ready what does that mean you guys doing agile you're all supposed to nod now oh of course we're doing agile yeah doing it yeah we're do what is your iteration size your Sprint what's your Sprint length two or three weeks two or three weeks which is the traditional answer two is better than three and uh what is supposed to be done every two weeks what is the stat of your work at the end of a twoe Sprint done done is an interesting word because in our in our world we have decided that done is not a Boolean variable we've decided that it has a range of possibilities how done exactly do you want it sir is it done or is it done done Deployable is the word every week or two weeks whatever your cycle size is the code should be Deployable that does not mean that you will deploy it it just means that you are satisfied you as a team are satisfied that the quality of the code is Deployable the business may decide that they don't want to deploy it because it doesn't have enough features for example log out might work great but you can't log in yet business might decide they don't want to deploy that but you are perfectly happy deploying it because log out works great we'll get to log in next Sprint but log out worse and it's been tested and QA and documented and it's all ready to go that's what is supposed to be done every Sprint this is what it means to always be ready to always be ready every at the end of every development cycle where there are very short development Cycles so that you are always ready I don't want anybody saying well you know we wrote a whole bunch of code but you know what we should really do now is run it for a month and watch it and maybe if it doesn't crash after that then maybe it'll be safe has anybody done that one stabilization phase we should just run it for a while you know cuz God knows what'll happen that's crazy what talk we should know code should be well enough put together so that you know I expect stable productivity stable productivity how many of you have worked on a Green Field project no code right just start with a blank blank screen no code how fast can you go when there's no code somebody asked you for a feature right and and they and you say I can get that feature done in a week and they say no nobody's ever done it in a week yeah I can do it in a week you start writing code and code pours out of every orifice of your body and a week later it's all done and everybody's going no you couldn't get that done in a week holy cow we never seen anybody go that fast before can you do it again yes come back to that team a year later hey can you do another feature for us ooh tricky you think it'll take us 6 months you used to be able to do this in a week yeah but you don't know how complicated this system has gotten like you know man if we touch it over here here why they might break over there in fact we can't tell what'll happen if we touch a line of code Like Anything could happen so yeah 6 months you know cuz we don't know that's a problem and it's a problem that affects lots and lots of software teams because they start out fast and then they they make a huge mess going very very fast and they wind up a year later going very very slow and imagine the business who started by seeing them go fast and decided to lay their plans based on that productivity and all of a sudden the productivity goes down into the toilet and the business is stuck there going what the hell happened how come you're all going so slow now you're not the same programmers we hired a year ago yeah we are we're really the same well you're not going as fast as you used to well we're working just as hard except now we're working hard moving around all this mess we need I don't want you to do that I expect stable productivity which means you will work you will produce features just as fast a year from now as you produce them today you will not slow down based on the mess you made because you're not going to make the mess how many of you have been slowed down by Bad Code look around this is everybody except for the few people who have their hands down and they're either not programmers or they're Liars everyone has been slowed down by Bad Code everybody has been slowed down significantly by Bad Code and then the question is why did you write it why would you write it if you know you're going to get slowed down by it and the answer to that is well we wrote it because we had to go really fast I'm going to leave you to deal with the logical conundrum there there's obviously an issue with thinking clearly you will slow yourself down by writing bad code you will slow everybody down by writing bad code and as long as that bad code is in there anybody who who gets near it will be slowed down and if the whole system is bad everybody's going to go slow all the time I don't expect that I want you all to go fast all the time so keep the mess out of the code oh we can't clean the code it's a mess well then you're going to go slow I expect inexpensive adaptability what do I mean by this I mean that the software ought to be easy to change the business should not find it expensive to adapt the system to new requirements it should be easy to change the code the word software begins with the word soft and soft means easy to change we call it software because it was designed to be easy to change the reason we invented software is so that we could change the behavior of machines easily to the extent that we have made our systems hard to change we have turned them from software into Hardware this thwarts the very concept of software software is supposed to be simple to change so I expect the software to always be easy to change that is just a fundamental goal of your job keep it soft I expect continuous Improvement and what does that mean it means the software gets better with time the code gets cleaner with time the designs improve with time every system should should be getting better and better not worse and worse this is what humans do humans make things better right we say things that are bad and we improve them it's a human nature our software systems somehow violate that they get worse and worse with time that's wrong you and I should be making our systems better Every Time We Touch them there's a rule it's called the Boy Scout rule it's a simple rule every time time you check in a CO check in a module you check it in cleaner than when you checked it out real simple idea never check anything in worse always check things in a little bit better you check out a module you have to do something to it don't make it dirty and then do some random act of kindness to it to make it a little better than it was when you checked it out always check it in a little better and everything will improve just that is if we did just that our code would get better and better over time I expect Fearless competence Fearless how many of you have um brought code up on a screen and you look at that code say oh it's a little ugly I should clean it and your next thought is I'm not touching it cuz you know if you touch it you will break it and if you break it it's [Music] yours so you walk away it's not going to be me I'm not going to be the one that's a fear reaction you fear what you created and if you fear it you cannot clean it if you cannot clean it the only the only thing that can happen to it is that it must rot it must get worse and worse and worse why does code keep getting worse and worse and worse because we fear remember when you got your first bit of code to work the joy you felt at being the master over that computer and how you wanted that feeling again oh I'm going to be a programmer and make these machines work you ruled it and now it rules you it's all changed around you feel what you have created you've lost control of it out of this sphere It Now controls you it dominates you you react to it you no longer are the master what do we do about this because it's completely unacceptable it is the Hallmark of unprofessionalism and sheer irresponsibility to have lost control of the thing we created to the extent that we fear any towards it what do we do about this well imagine that you had a button you could push a little magic button you push this button and some lights blink and shortly thereafter there's a little ding ding and a green light lights up and that green light means that everything works and you trust it you trust the green light everything works now look at your screen there's code on that screen it's dirty and you think oh I should clean this code and your next thought is well maybe I'll just change that one little variable I'll change that one little variable it's name is wrong I'll give it a better name hit the button ah green h worked okay um this function is a little big maybe I should split it into two functions hit the button ah green good okay um o this function should probably be moved over to that module over there hit the button red oh no put it back oh I see I did it a little wrong okay move it over here hit the button green ah if you had that button you could clean the code if you could clean the code then the code would always get better if the code always got better you could make it easy to change if you can make it easy to change you could go fast that button is the key to everything how do you get that button where can you buy it where do you get that button from how many of you are practicing test driven development look at this we got um not quite 10% and we do have a little of this going on test TR and development test TR and development is a discipline a discip displine the goal of which is to give you that button if you were practicing test driven development from the beginning from the start of your career every system you would ever work upon would have had that button to start practicing test driven development now is going to be difficult because you have systems that don't have tests and weren't designed to be tested and so writing test for them will be difficult but that's not to say that it's impossible and that's not to say it's a bad goal just difficult it may take you some time to get that button but now think of what that button can do for you what it can do for your team what it can do for your company and it makes it almost absolutely imperative to get that button what is the right level of code coverage test coverage when you run tests how many what percent of the code should be covered by those tests 100 it's the only reasonable answer 100% it's also an unachievable answer you can't ever get to 100% but we are used to ASM totic goals goals that you always approach but never quite get have you ever tried losing weight ASM totic goal but it doesn't mean you stop trying you keep pushing that number higher and higher 95% 96% 96 and 12% you get it high enough so that when that green light goes on you are willing to trust the green light has anybody got a test Suite where you're on it and it passes and everybody kind of goes yeah mhm because you know there are things that weren't tested you know there are big gaps in the test suite and so the fact that the test passes does not change your behavior you can make no reasonable decision based on your test Suite passing and that makes the passing useless when the test Suite fails it at least tells you that something went wrong but when it passes it tells you nothing that's bad the passing of the test week should change your behavior it should allow you to make certain decisions that you would not make otherwise if you have that button you wind up with extreme quality and I expect extreme quality I expect that the software is going to work consistently release after release after release I don't expect lots of problems and crashes and troubles and data Corruptions I don't expect those things I expect the software to generally work pretty well an occasional bug every once in a while is probably unavoidable but when they occur I expect you to track them down and get them get them um solved and and uh work on them appropriately anybody using a bug tracking system you got one you maybe jira or you one of them there's lots of them out there right and and we take all of our bugs and we put them into a database so that we can track them I want you to consider what it implies that we have to have an automated database to track our defects we must have a lot of them if we need an automated system to track our defects where did we ever get the idea that that was normal or right that it's okay for us well there's only 10,000 defects in the database where did we get that idea how long should the defect list be should fit on an index card it should be small you should have a little little pile of cards there's five or six defects in the system I we'll clean them up extreme quality I expect that we will not dump on QA do we have any QP QA people in the room here any testers oh got one good does this look familiar waiting for the load to be delivered I every and you know the load doesn't come on time does it you know the development team does not deliver on time does that change the delivery date no so the QA folks wind up with under the most pressure they have the most stress they have the least flexibility it is a high stress tedious job and this is how we're going to get guante quality there's something wrong with that whole concept I don't want the software I'm going to get rid of that cuz it's ugly I don't want the software team dumping their load on QA so the QA can sweep all the bugs back to them you don't just say well why don't we give it to QA and they can debug it when you release it to QA QA should find nothing I expect that QA will find nothing now of course QA will find things from time to time and when they do I expect the development organization to react and go well how the hell did that happen and to plug whatever leak that was because generally QA should go through its actions and then report no defects how did we ever get to the idea that it was a good good thing that that QA got defects where did that why do we have QA in the first place original software development teams didn't have QA departments how did we get them what what would motivate the companies of the world to create wholly new departments under different management to make sure that software developers did their jobs what motivated them was software developers weren't doing their jobs we were shipping and to come back at that to deal with that the uh companies of the world had to say well what are we going to do these guys are shipping well we need to come up with some group that can smell it how do you reward QA how do you know if they're doing a good job they find bugs more bugs they find the more job more of their job they're doing the one who finds the most bugs is obviously doing the best job so now we've made bugs a good thing there are people now who value bugs we want more bugs we want more bug now the developers do the developers value the bugs there's an old rule in software it goes like this if the code doesn't have to work I can meet any deadline you set for me name the date I will deliver so long as it doesn't have to work so now these two groups QA and development both value the bugs and both can set up a little economy how many bugs you're going to give me this week I need a little bit more cuz I need something on my uh s you coming up oh yeah I got a deadline to meet so probably ought to be able to give you five or six more actually the uh the words are never spoken no one ever says anything but the economy exists because everyone understands there's a mutual benefit and an organization where that is going on is a truly sick organization a deep disease in there I expect all of the testing to be automated there's some exception to that rule which I'll talk about in a little while but the vast majority of testing will be automated the hands you're looking at here are the hands of a QA manager for a large internet travel company this guy is holding out to me the table of contents for his manual test plan it is not the test plan itself it is just the table of contents he has 880,000 manual tests that he must run every 6 weeks he ships them over to an army of of people in India costs Hime I did we lose the battery something happened oh hello so where was I um army of he ships them over to an army of people in India it cost him a million dollars every six weeks a million dollars every six weeks and he's holding it out to me because the year is 2008 and the financial crisis has begun and he's just gotten back from his boss's office and his boss has just gotten back from the cfo's office and the CFO said I'm cutting your budget by 50% there's this big recession on and he's holding this out to me saying which half of these tests should I not run and I tell them well you can cut the you cut the document this way or that way doesn't matter you're not going to know if half of your system works this is the inevitable outcome of manual testing manual testing always ends with you losing the tests you could lose them directly like this guy did because they simply got too expensive but more commonly you lose them by QA deciding not to run them because they don't have time so QA will decide which tests are the most important to run and which are the least important and you will lose the tests anyway manual testing always results in this and manual testing is insane because we're programmers we know how to automate why wouldn't we automate that why wouldn't we have automated tests the test every business rule in the system every interaction in the system why wouldn't we have written those tests and you think well it's expensive to write tests no that's expensive that's people and look at what we're asking those people to do has anybody done this job anybody seen a manual test plan and then you know what you have to do right you open this massive book enter P95 23 into the username field enter xx9 52 into the password field click login did the welcome screen come up and this is your job I don't want QA acting like a bunch of aut automatons running a program that a computer could write QA are intelligent creative people we should move them away from the back end of the process where they're frankly pretty useless and move them to the front of the process where they can apply Creative Energy to figuring out what tests ought to be run and they don't have to run those tests programmers ought to run those tests most mostly those tests ought to be automated now there are some tests that you can't automate and there's some testing that cannot be automated mostly the tests the testing that you cannot automate is the testing that requires Creative Energy you take a system you hand it to a bunch of Crea people and you say to those creative people break it find some way to break this system and they will once you challenge someone to break something they'll find great Glee in figuring out some way to break it and they will think of all manner of interesting ways to break that system that's the kind of QA that I would like to see creative people figuring out interesting ways to break the system and also QA at the front end of the process writing the specifications and the tests that must pass I expect nothing in the system to be fragile you know that module it always breaks the one where all the bugs are everybody's got in every system wherever there's a bug oh yeah it's in that module fix that module I don't expect fragile stuff in our systems I expect that we will cover for each other what does this mean Bob is the database guy Bob gets sick nothing happens on the database this is unacceptable if we're working in a team if Bob gets sick someone else should be able to step in and take over for what Bob was doing and whose responsibility is it to make sure that someone can step in and make sure that they can they can take over for what Bob was doing it is Bob's responsibility to make sure that someone can cover for him or her I suppose there are hers named Bob who if they if he goes down it is your responsibility to to make sure that someone can cover for you if you go down now how you're going to achieve this I don't know you might decide that some paired programming is necessary or some heavy reviews are necessary whatever technique you choose it's going to have to be good enough so that if you go down someone can cover for you instantly bunch of guys on the on the field kicking the ball down the field one of them goes down the other players change their field position to cover that hole so that they can keep moving the ball down the field that's how a team works and that's how you need to work as well so figure out a way for you to cover for each other it's a simple expectation and it's not an unrealistic expectation I expect honest estimates what is the most honest estimate you can make exactly the right words I don't know the most honest estimate is I don't know because the answer is you don't know how long is it going to take me to do this thing I don't know but you do have a little bit more information than that see there's two components to an estimate there's the accuracy and the Precision now the I don't know is the right Precision it's just that you haven't been very accurate so give me some kind of number right like how long is it going to take you well you know I think Friday seems like a good number here's what I really want I want three numbers I want the best case the expected case and the worst case I want you to say well if everything goes right and I mean everything then I might be able to get it done by Wednesday but things don't usually go right so probably Friday H you know but if all hell breaks loose probably next Friday now that's a very honest answer it's honest both in accuracy and precision you've given both the the expected time but the boundaries on your on your lack of knowledge on your indecision it's wise to provide that kind of information and some some how many of you have done this ever and then and then had the response well that's not good enough we need to know what do you do then you say I'm sorry I'm sorry you need to know but that's the best I've got well you got to do better than that can't do better than that well there's got to be some way you can you can improve your estimate no there isn't oh come on you're not being a team player um actually I am I'm giving you the the best information I have right now you're the manager manage right and then here comes the word well will you at least try careful careful it'd be very tempting right now to say yes I'll try you must not say that the answer is how dare you imply that I am not trying I'm I've been trying this whole time I am still trying and you're suggesting to me that I'm not trying I don't have any magic beans in my pocket I cannot change reality the numbers are as I I I have told you you're going to have to deal with it I am not going to try you know by the way that you are tempted to say yes of course I'll try and why are you tempted because you and I frankly did not get into this business because we like working with people and we're not very good at working with people so in a confrontation situation where there's somebody in your face going I need it by Friday we want to get rid of them we want them to go away and if they say will you at least try you've got an easy way to make them go away yes I'll try now go away but here's the problem with that the fact that you have said you will try will not change your behavior at all there will be no different decision you will make no different Behavior you will use it will change nothing about the outcome it was a lie you told a lie cuz you already are trying and there's nothing you can do about your current uncertainty to specify it and let the let the chips fall where they may you had a question up in the in the back and I I delayed it as long as I could I just want to say the the response usually is the only he the Wednesday he yes of course right yeah you give them the best case the nominal case and the worst case all they hear is the best case and then they shorten it by two days right because they figure you're padding right this is just a trust issue and we've had this problem all along where you know developers will start padding on the back end and then the managers start taking the padding off on the front end and it's this constant race to see who the heck has got the most padding or can take it away you give the range and you hold to the range and then you improve the range when you have better knowledge because here's the bottom line here you were hired for your knowledge and your knowledge gives you the privilege and the responsibility to say no when no is the the answer when the answer is no we are the only ones who can say that we're the only ones who know when you know when someone says we got to deliver by Friday and you know that it's not going to happen we're the only ones who can say that no sorry it's not going to happen on Friday and it doesn't do any good to say well we'll try do you um remember what happened two years ago in October the um the American healthc care law demanded that a website be produced by the United States government and it demanded that this website would be turned on on October 1st 2013 so the law set a date certain for a software system now that's insane you don't set date certains for software systems especially if they're critical systems if you if there's any possible way to avoid it and they never did have to make it a hard date but they did they made it a hard date okay so what happened on October 1st 2013 they turned it on and yes it crashed horribly and it burned and it actually burned for several months and and it almost derailed the law that's how serious it became cuz the the fur of over the fact that this thing was turned on with great Fanfare and then immediately crashed and burned horribly was enough for a lot of people who were tentative on the law to say no come on this is nonsense very nearly undid the law however you feel about the law a software failure had a profound impact on public policy were there some software developers do you think that new that they shouldn't turn that thing on what were they doing sitting under their desks going oh they're going to turn it on aren't they they really shouldn't do that we are the only ones who can say no and we were hired for that ability so we have a responsibility to communicate to our company by the way guys you're insane this can't happen don't try we have that responsibility I expect continuous aggressive learning how many languages have you seen go by in the last 30 years let me paint U just a little landscape from on the computer languages for you um does anybody remember when cobal was actually popular [Laughter] that was the 1960s um and then after that after that we had c c became popular in the late 60s early 70s C++ became popular in the uh mid 80s then Java became popular in about 1995 and C right after that because they're really the same language and then Ruby became popular right around 2005 2006 and we're seeing another language start up the popularity chain right now which is well JavaScript I probably don't need to mention there's also things like closure and Python and so on the languages come in waves and the waves rise and then they fall and the career software developer surfs those waves right and you always have to be ready for when the waves starts your wave starts to go down you got to be ready so that you can leap onto the next wave cuz you don't want to ride the wave down it's hard to recover from down there so you as software developers should be learning all the time learning a new language every year or two you should uh learn new platforms new operating systems new Frameworks you should be fiddling around around and playing with stuff all the time because our industry is one that is constantly changing and your job will very likely change out from under you in ways that you cannot anticipate if you are not ready for it when do you do this learning there's a fundamental truth about being a professional it is your responsibility to take care of your career it is not your employer's responsibility to take care of your career do not trust your employer with your career now your employer may help with it might buy you some books might send you to conferences you know who knows what your employer might help you with and that's fine that's good but you must maintain responsibility for your own career and what that means is that when you give 40 hours a week to your employer to do the best job you can you are not done you then go home and you provide another 20 hours or 10 hours or 15 hours for your career you go home and you fiddle around with a new language you fiddle around with a new operating system you fiddle around with a new discipline you learn something new and you may say yes but I've got a family I've got commitments well I understand that believe me I understand that but you chose a career that requires grooming and maintenance and if you do not undertake that then your career will falter so either find another career or expect to invest the time when you go to a doctor that doctor puts in a hard week at the office 40 hours a week seeing patients doing surgeries at the hospital doing all kinds of stuff you kind of hope when he goes home he cracks open the books and reads the medical journal kind of hope he's putting in the time after hours to stay up on what's going on in his field because his field is changing rapidly if you ever get sued and you need to hire a lawyer you know that lawyer is going to be putting in a lot of time in the courtroom and in the office with you and then you kind of hope he goes home and he cracks the law books and reads on what's going on cuz he's got to stay ahead of what's going on in the law you have to do the same thing too one last point then we'll take a break and then after the break we'll have a little informal question and answer session mentoring how many programmers are there in the world 50 about 50 50 million yeah it could be 50 million could be 100 million could be 200 million it depends on if you count the VBA programmers or not it's a very large number how many programmers were there in 1948 five one yeah maybe five Big O of one Allan touring was the first real programmer uh the first person to write binary code that executed in an electronic computer and he and his staff of people learned a few things about it and within 10 years there were hundreds of computers in the world by 1955 hundreds of computers in the world and thousands of programmers who were those programmers those thousands well they were scientists and mathematicians and Engineers that were pulled out of other fields and they were already professionals and they were generally older in their 30s and 40s some in their 50s by 1955 there were a lot of those you know several thousand 1965 how many computers are in the world tens of thousands tens of thousands IBM was already producing 1, 360s every month how many programmers were in the world hundreds of thousands we're talking about about 20 years later hundreds of thousands of programmers in the world and again they were drawn out of existing Industries cuz there were no University programs teaching you to be a programmer there were no computer science degrees there were no programming classes if you wanted to program you figured it out on your own you learn you got a book out a book on foran or a book on pl1 or Cobalt or basic Assembly Language or something like that you figured it out for yourself and you better be pretty smart and these people were drawn out of out of Industry out of other jobs in Industry they took the best and the brightest and they said you're going to program these machines and these were people who already knew what a job was already understood business already understood schedules and deadlines and commitments and all of that stuff they were already professionals and they were in our field and by the way something like 30 25 to 30% were women a huge number of women were programmers in those days that changed in 1975 when I got my first job as a programmer it was in 1969 and uh the place I worked had 25 30 programmers I don't remember exactly but there were well about a third of them were women there was a lot of women there and I remember that and these were people in their 30s and 40s they were mature professional Ood what they were doing 10 years later I worked at a company that had 50 developers two were women and this curve that I experienced was experienced by the whole industry in 1975 the computer science degree programs had finally arrived you could go to college to learn to be a programmer and they universities started to graduate huge numbers of young men I I don't know why why they weren't even moving but the average age of the programmer declined by about 10 years from 1965 to 1980 is time frame the average age of a programmer went from mid-30s to mid-20s and the number of women in the field dropped from something like 25% down to 2% since that time the number of programmers in the world has doubled every 5 years think of it how do you get to 100 million in 60 years if you started with one just think of the doubling rate the number of programmers in the world is doubled every 5 years and that has a deep significance because it means that half the programmers in the world have less than 5 years experience and this has always been true and it will always remain true so long as we keep doubling every 5 years half the programmers in the world have less than five 5 years experience which puts our industry in the in a state of Perpetual inexperience how do we address the fact that all the experience shrinks to insignificance in the face of the massive number of young graduates pouring out of the of the universities and getting hired guys like me who've been in the field for 50 years how do I teach the young program rammers what to do cuz they come in out of school knowing nothing they know a little Java maybe they know a little something they arrive on the job and go what the devil is this cuz University does not prepare you for what's really going on in the in Industry it seems to me that it would be wise for companies and programmers frankly senior programmers to make sure that new kids coming out of school are not allowed to touch any of the core code for a year or so take them on as apprentices Mentor teach make sure they're not turned loose on their own I don't want to see you know a bunch of kids thrown in a room and throw in meat and have code come out it doesn't take a lot of intelligence to produce code it takes a lot of intelligence and experience to produce well structured systems with discipline and that that's what we need to inculcate into the younger folks coming out of school now cuz in general in school discipline is not a priority and with that I believe I will close the talk let's take a break oh 15 minutes or so and then we can return here and and we can have a a a session of question and answer and I'll just take questions as they come at that point so break first then [Applause] questions all right this is weird all right questions everybody filed back into the room I have a question regarding the test coverage yes you know you said this green button which you cannot really trust yes because you can never get the 100% coverage but how about the balance like when it is good enough so we can trust it kind of when is the when is the test Suite good enough that you can trust it this is something that you will have to discover for yourself um because in a legacy environment there is a very large batch of the code that works and it really doesn't need any further testing because it's been through it's been through the field it's been through production it's it's a decade old new works and you'll probably never get that tested and you don't need to get that tested so in a legacy environment the code coverage number is not very significant now how do you deal with a legacy environment that's a a an an interesting question all by itself you have a whole bunch of code that is not tested that was not designed to be testable how do you even approach getting this button that that gives you the green light how do you approach a test Suite that you can trust and the answer to that is first of all don't make a project out of it don't decide for the next 3 months we're going to run a whole bunch of tests this project will fail and it will discredit everybody who's been a part of it it will not produce the tests that you want and it will probably leave the system in a worse shape than you begin this is what happens whenever you start a project to correct a longterm uh lack of discipline the solution is to change attitude you shift your attitude you say I am from now on I and every member of my team whenever we touch this code we will make it a little bit better this is the Boy Scout rule I talked about earlier but when you're making a little bit better you check out the code you look at it you do whatever you have to to it you make it a little bit better when you make it a little bit better you are thinking about how you're going to get tests in there now you may be able to write a test don't write too many don't go crazy write enough tests to satisfy you for that day and then check them in but you might not be able to write any tests because the the code was not designed to be testable it's too risky to change it to then write tests so what you'll do then is you will make some small change to make the code approach testability just a little bit closer you'll break some coupling you'll open up some function you'll change some function argument something like that and then you'll check it in and walk away and hope that the next guy can push it a little closer to testing and then bit by bit this code will get better and better what code will get better and better the code that you're actually touching there'll be a whole bunch of code in there that you never touch that already Works you're never going to see it again don't go digging around in that stuff it's the code you're actively manipulating that you want to improve secondly sometimes you will be asked to add new features and you'll realize very quickly that there's two ways to add the new feature one way is to smear a bunch of code in the existing Legacy adding if statements and flags and stuff like that so that you can get this new feature in the other way is to write the new feature in a completely separate module and then and then couple that module in from the outside into the legac Cod that second way is the harder of the two and it's the one you should do because you can test it you can write all of that code with with tests and you can then Factor it into the Legacy so you will have improved the Legacy system by doing that over a lot of time the Legacy code will get better and better and more and more tested and then it becomes a bit like a snowball because as it gets better and better and more and more tested you start to trust the tests more that allows you to do even more cleanup which lets you trust the tests even more which allows you to do more cleanup and you get this runaway Snowball Effect you're kind of hoping that'll happen sometime within a year or so next question yep um test environments how many stages do you need how many in your opinion how many different environments do you need Oh you mean to test your production environment and this this customer and that customer and that and and this browser and that browser and that browser um the question presumes something that I I'm not sure I want to presume which is that you have entire system set up for the purpose of testing you may have that but that may also not be necessary because I don't want you on a regular basis to be testing in an offline system I want you to have broken up your modules to the extent that you can test the individual modules and know that those modules work and I want that to be your primary mode of testing and then as a secondary mode of testing you integrate those modules and test them in a in a lifelike environment in that lifelike environment how many of them do you need and you need as many as you have production environments outside and field environments now hopefully you can take one system and alter it so that you can test it in one environment and then the next and the next so that you're not replicating tons of Hardware but to be safe you're going to have to test it in each each production mode so you'll have to have some way to swap the system back change the configuration of the system to test each configuration each production mode that means it's going to take some time and that's one of the reasons we want these tests to run very fast a good Suite of tests should not run for days or even lots of hours it should run in minutes if it's a very very comprehensive Suite of test that goes all the way through the goey it's probably going to run in a couple of hours I don't want it to run much longer than that certainly and for most of the module tests I want it to be seconds I don't want that to take a lot of time pH at which point I should say something about goys please do not test your business rules through the gooey right A lot of people will buy these systems that um allow you to let a tester drive and the system will record what has happened and then it will play that back and make sure that what happens on the screen is the same um these systems are trap when you're testing business rules they are a trap and the reason they're a trap is very simple uis change people change goys and they change goys for arbitrary reasons they don't like the color they don't like the way the windows flow some marketing person will read some new fad on on uh user presentation and then you'll have to change the order of things on the windows and all your tests will break and if all your tests break then you'll be then you'll be stuck in the mode of having to redo them and you're never going to have time to redo them it's just not going to work and what you'll do is you'll throw them away don't test business rules through the UI test business rules through an API that gives you access the same API that the UI uses design your systems so that they are decoupled enough so you can test your business rules through the through an API now you also have to test the UI that's fine and for those you can use those systems if you'd like um when you test the UI decouple from the main system replace the backend business rules with a stub that return canned answers so that all you can test is the UI you can't test any business rules and that lets you test the UI independently of the business rules the business rules independent of the UI I could push this even farther and say that you want to test the business rules independent of the database but we probably don't want to go there just yet anybody else did I answer your questions good yes T development is the how come how come school oh what an excellent question okay so if test driven develop is the answer to everything why aren't people learning this in school okay first of all it's not the answer to everything so just so that we're clear on that but it is a very powerful discipline why aren't they learning it in school well some people are there are some professors that teach test driven development but it has not become a general discipline in in University then again what has what discipline of ours has become taught in school for example do schools really teach the discipline of source code Control Systems well do they teach students how to deal with check in and checkout discipline and merging and Branch discipline do they teach kids in school how to deal with unit testing whether it's test driven development or not do they even cover the idea of how you test your code and what what tests are and what a good test is what a black box and a white box test is some universities do most do not most teach no discipline at all and and the reason behind that is most of the professors have never held a job in Industry right they've been academics all their lives and really don't know they don't know what it's like to actually be a programmer in the real world so how can they teach It software is one of those industries that is ahead of Academia Academia is 20 years behind the industry and that's not uncommon uh when a when a avionics first when when um not avionics but Aeronautics Aviation was first developed universities Were Far Behind they had to be so who's figuring it all out you know us the guys in the field we're figuring it all out and then eventually People Like Us will become College professors and then we'll take all those disciplines into the university we're still way too young in industry for that to have happened so expect the folks coming out of school to be roughly 20 years behind as far as disciplines are concerned they know they know some of the new languages some Java Java's already pass the point of its peak popularity it's already on the decline some people think W it's a new great language no it's a really old language and it's starting to show how old it is anybody else y how's your point of view on sh and the framework on on The NET Framework and C oh c and net um they're fine it's good platform it's roughly equivalent to Java um and the history of that is fairly interesting Sun used Java as a way to capture the mindset of programmers back in the early '90s the mid 90s um they made this this uh decision that the way you sell Hardware remember that sun was a hardware company they sold pieces of metal um the way you sell metal most effectively is to win the hearts and minds of programmers they discovered in the in the mid90s that it was programmers who actually decided what Hardware got bought we often underestimate our power but we were the deciders even then and so they thought well what better way to win the hearts and minds of programmers than to give them a language and they hunted for a language that they could offer programmers and at first they thought it would be C++ but then they realized they didn't own that as a monopoly and it didn't fit with the idea of the internet well and then this guy who worked for them his name was James goling waved around this language that he had produced a few years back which was called Oak and should have been thrown in the trash but son said oh H that might be the language and they promoted it out to the world as the language of the internet that became J Microsoft said ah what a good idea so they produced their own Java compiler does anybody remember visual j++ right and then sun went to Microsoft and said hey you can't do that and Microsoft said oh yeah okay and they changed a couple of keywords it's the case of some some function calls and they called it C and the two have you know two are virtually identical languages cuz they were the same language and then they've kind of divided ever since uh Net's a fine framework uh are you using it who's using net and so what IDE could you possibly be using okay one of the problems with going in in the Microsoft world is that there's no competition right so you're stuck in a in a world that is not advancing fast enough Microsoft tries to innovate and they sometimes do a good job I like what they did with link I like some of the things they've done with C on the other hand I despise visual Studio it's a terrible I are you using resharper yes okay you have to use resharper and it's a very sad story um the idea behind these refactoring and good formatting browsers starts in 2001 and I many of us went to Microsoft and said guys you've got to do this you've got to improve your IDE there's there's idees out there for Java that are just you know knocking your clock off and Microsoft kept on saying oh yes we'll do that oh yes we'll do that for years and years and then finally the guys who made intellig for Java wrote wrote re sharper re sharper makes Visual Studio almost usable that's my thoughts on net um otherwise it's a fine platform I don't have any objection to it be careful I I think what's going to happen over the next decade or so is we're going to see the platforms survive the jvm and the CLR Will Survive the languages will begin to shift Java will sh will shift away it'll get replaced by something maybe Scala I kind of doubt it more likely to be something like J Ruby or closure or something like that on the net slide you're going to see fshp becoming more important I don't I don't know that that will actually be the language that takes over it might be something more like I don't know Iron Ruby or one of the other variants but watch what happens in these spaces the platform Will Survive the language will begin to wne and the reason the platform Will Survive is just there's too much invested in it there's enormous amount of very good stuff at the bottom layers that everybody's going to want to continue to use next what's your point of view on on Agile Release cycle so releasing or make your product shipal every two to three weeks versus true continuous delivery if you can do true continuous delivery you should do true continuous delivery uh if if you've if your disciplines are so sharp that every time you check things in and your tests pass you are comfortable deploying then you should do that uh I work on a project like that right right now where we have a suite of tests and we believe in this Suite of tests so much that if the test pass we deploy now we haven't made it instant yet um we still go through the manual step of deployment deployment but the the only gate is that the test pass and that's a really powerful mode to be working in there's no delays getting to that point is is hard right you have to get a suite of tests that is really far down that that code coverage one you're really close to 100% that little green light lights up you believe it you're ready to deploy uh most most folks aren't going to be there they're going to be at a at a release cycle that is a week or two weeks and that's fine if you can get there and then keep that going for a few years then you can start thinking okay let's let's push this see if we can get to continuous delivery we got a test Suite that's really hot stuff we're going to be able to just crank it out that'd be great um going to be tough to do with Legacy environments because you will probably never get the code coverage you need for but in Greenfield or brand new projects probably something you can you can approach um back in the '90s uh the developing Community they made a choice uh to stick with the u you Call strong language yes you think now the it's shifting to it certainly is and thank you for bringing that up because that's a fun story to tell um in the 9s there was a war fought and the war was fought between IBM and sun and the topic of the war was static typing versus Dynamic typing static typing are languages like Java C C++ where you must declare the types of your variables before you use them and the alternate language was small talk IB was the champion of small talk small talk is a dynamically typed language you do not have to declare the types of your variables at all a study had been done in the early 90s by Capers Jones that showed that people using dynamically typed languages could could write their systems five times faster than people who were using statically typed languages and people quibbled over whether it was five or three or two but nobody suggested that you could go faster with a statically typed language everyone acknowledged that yes writing in statically typed languages is slower but it's safer and that was the argument we prefer the safety to the speed remember this the next time that you are worried about a a deadline and somebody's you know hammering you over a deadline the entire industry decided to go at least twice as slow for the purpose of safety IBM lost the war U they had a whole Suite of tools all set up for small talk it was visual Small Talk visual age for small talk and all this really cool stuff they had it all set up they lost the war they abandoned the small talk engine they went to job All the Small Talk programmers were crushed and and as a language Small Talk died that was the last time Small Talk had any chance of becoming a significant industrial language and it never will again probably there's always a chance but I doubt the Java people won that war the C++ people won that war and that's where it would end except for a very interesting Quirk of History the small talk programmers were badly burned by this and they plotted their Revenge they work did IBM they decided to release a product that would destroy Sun they called it [Laughter] [Music] Eclipse work the final little bit of irony in that is that the Eclipse engine that generates the jvm code is to this day written in small dog next question question now I had asked how many of you are doing test driv development and I got a pretty good result actually was about um maybe 10 to 15% of you which was was encouraging usually when I go out into the industry at large that number is about 15 to 20% 5 years ago it would have been 5% 10 years ago it would have been hardly in we're on a a pretty good growth curve the discipline is beginning is moving through the industry more and more people are using this as a powerful discipline to get their code written and once you start using testen development it's very very difficult to stop because you get really addicted to that little button real fast and the power that it gives you to change code and to be free of the debugger uh is a a really immense power how many of you know what it is what is test driven development let me describe it to you very briefly this is a discipline that makes no sense to the normal developer and if you've never heard it describe you will recoil from it in horror because it really doesn't make any sense if you've been a developer for any length of time I certainly recoiled in horror when I first heard of it in in 1999 and it took me several months to wrap my head around this goofy idea testen development is composed of three rules and the first rule immediately sounds stupid you cannot write any production code until you have first written a test that fails now what kind of test are you supposed to write if there's no code right so it just makes no sense but the second law is worse the second law says you are not allowed to write more of a test than is sufficient to fail as soon as the test fails you must stop writing the test and oh by the way not compiling is failing so the instant the test does not compile you must stop writing it now you have no code you write a test it's not going to compile you write one line of the test that line is not going to compile because it's calling something that does not exist so then you have to switch modes and write the production code that makes that test pass but that requires one line of code and that's when the third law kicks in and says you are not allowed to write more production code than is sufficient to make the currently failing test pass so now you're stuck in a loop that's maybe 5 minutes long maybe 30 seconds long depends on on your how fast your compiler is and how quick your IDE is and how good your editor is you might be stuck in this Loop every 5 Seconds line of test line of code line of test line of code and again if you're a programmer of any years discipline this sounds absurd you'd never be able to write a loop without going back and forth no if statement could be completed without going back and forth a whole bunch of times it just feels wrong feels like it would be boring and and tedious and it would interrupt your flow of thought and all of this stuff and it and it is it does all these things all the things that you predict about it it does but there's the other side of the corner imagine you got a group of people like you in a room like this all doing these three laws pick one of them doesn't matter who doesn't matter when everything they were working on executed and passed all its tests within the last minute or so everything worked a minute ago no matter who you picked no matter when you picked them everything worked a minute ago what would your life be like if you were never more than a minute away from seeing everything work how much debugging do you think you would do the answer to that is pretty clear if it all worked a minute ago there's not a lot of debugging to do anybody good at the debugger you're really good you know you know all the hot Keys step into step over step around you know how you get good at the debugger you spend a lot of time debugging I don't want you spending a lot of time debugging I want your debug skills to wne I want you to wonder every time you fire up a debugger and you will from time to time fire up a debugger but every time you do I want you looking at it going okay how do I do a breako oh yeah click that thing step into is that f8 or F7 I don't want you to know I want it to be a tool that is so far removed from you that you're not familiar with it U because if you are following these three laws the amount of time you will spend in a debugger in a year will be measured in minutes how many of you have integrated a third party package so you get a third party package from the third party maybe a CD maybe a a zip file you unpack it somewhere in there there's some code there's also probably a PDF the PDF has got uh an appendix at the back with a bunch of ugly coat examples where's the first place you go you want to learn this this third party system you go to the code examples you don't want to read what some tech writer wrote you're going to go to the code examples and read those code examples and the code examples will explain how to use the system if there's any mystery you're going to go to the words after that but usually there isn't any mystery because the code examples tell you exactly what you need to know when you are writing these little unit tests back and forth back and forth what you are writing are the code examples for the entire system anybody wants to know how to call an API there's a suite of tests that calls that API every way it can be called you want to know how to create some object there's a suite of tests that creates that object every way it can possibly be created and these little tests are short little Snippets of code they are a kind of documentation they are absolutely unambiguous so formal they execute they cannot get out of syn with the application they are the perfect kind of low-level documentation for a programmer to read you want to read code code will tell you the truth code is unambiguous you want to document something so a programmer understands it you document it in code that doesn't tell you intent necessarily it doesn't mean that there's not other kinds of documents you need to write but the lowest level documents are code and this little technique makes sure that the entire system is completely documented at the lowest level with little Snippets of code that show you the examples of how Works how many of you have written um unit tests after the fact some people do this and they think it's test driven development um how much fun is it now notice the reaction that was an interesting reaction of course it's not fun right it's not fun to write unit tests after the fact why isn't it simple answer you already know it works you've tested it manually right you've seen it with your eyes you know it works and now some process guy said yeah but you're supposed to write tests and you kind of go oh well all right I'll write some tests and it feels like make work it feels like busy work it just it's bothersome but you go ahead and you do it all right I'll write a test here all right yeah all right I'll test that okay oh that one it's hard to test inevitably you come across the function that's hard to test it's hard to test because you hadn't designed it to be testable and now you face a dilemma I got to change the design well I saw it work never and you walk away and you leave a hole in the test suite and if you're leaving holes in the test Suite everybody else is leaving holes in the test suite and that means that when that little light turns green you all kind of Nod and go yeah I know if you write the test first that can't happen if you write the test first first of all it's fun because you haven't seen the code work yet and every little test is this little proof that you can still write code that works you write a little test it fails and then you go over here and you make it pass another failure yeah you get this little charge all the time yes I can still right code that works I'm still a god second you cannot write the function that's hard to test cuz you wrote the test first when you write the test first first you must design everything to be testable you don't have any choice about it your first thought about the production code is how do I make it testable and there's another word for testable decoupled that's how you make something testable you decouple it so the very Act of writing the test first forces you into this heavily decoupled mode you will decouple like crazy because of this and that will simply improve the design of your system you just get a better design there's all these little side benefits you you aren't going to be in a debugger for the rest of your life that will probably make you go a lot faster you'll have all this lowlevel documentation that'll probably make you go a lot faster you're going to design the system better it's fun that'll probably make you go a lot faster all these things will probably make you go a lot faster and it they more than make up for this funny business of writing the test first and all that stuff that you initially thought it' be slow and tedious and boring more than makes up for that and then after all of that you get this Suite of tests that you trust withth your life and that site of test that you trust withth your life solves so many other problems you can clean the code fearlessly clean the code you can manipulate the code you can twist it any way you want how many of you um believe that design is really important got to get the design right right books have been published about this right we got to get the design right why because we have to keep the code flexible and maintainable nothing makes code more flexible and maintainable than a suite of tests by a huge order of magnitude you give me an application that is perfectly designed beautifully designed but there's no tests I'll be afraid to modify it I'll be afraid to touch it it will rot you give me an application that is badly designed but it has a comprehensive Suite of tests I will improve the design I will gradually make that design better and better fearlessly because I have that sweet of tests the stive test means much more than a good design so to the extent that you are considering design important multiply that by 10 and make your tests important yes sir uh what do they mean by beautifully designed system when a design is beautiful uh what I meant was a well-designed system in terms of principles of oriented design and separation of concerns A system that is easy to change because of its design yes uh so T is one of those things in in nature still a lot of debate about and in exactly how does it look yes I haven't heard any same people argue against automatic testing or everybody wants the green light but exactly how do the code look afterwards and I don't you probably follow the debate on from David hman hon the test infus design damage which is kind want to talk about you obviously we want automatic testing but if the way you induce this sort of removes the your ability to read the code and and I know the argument very well yeah I know David So how do you see that that argument well here's how I see that argument David Han Hansen that's what whom you're talking about yes is the author of a framework called rails rails is the framework in which Ruby applications are often developed and rails gives you a a very powerful way to get an application up and running very quickly if you want to do anything extra with the application you will find rails starting to impede you and getting in your way and the more interesting stuff you want to do with the application the more rails gets in your way and why does this happen in rails because the way David designed it was to force you to couple very strongly to the framework if you try to decouple from the framework David calls this designed or test induced uh design damage because from David's point of view if you decouple from rails you are damaging your design why would he think that because it's his framework here's the thing about Frameworks and you will find this to be consistent about every framework author these people are not bad people they're good people and they offer their code to the world for free and you know Pat them on the back and say thanks Bunch that's great good but every framework author wants you to couple to their code they want you to derive from their base classes they want you to intertwine your code with theirs because somewhere in the back of their mind they know that once you've done that can never get away a good software developer looks at Frameworks and says somehow this framework is going to screw me and so you look at Frameworks very carefully and you think okay I want to use it because it's powerful but I am not going to take my family jewels the business rules that make my company money I'm not going to in fuse those business rules with that framework I'm going to decouple from that framework to keep my business rules safe because I don't know if I'm going to be with that framework forever I may want to change it a good software developer looks at Frameworks with a jaded eye they're going to hurt you so they're going to help you they're also going to hurt you and you never hear the documents tell you how they're going to hurt they do tell you how they're going to help now that's not to say they're evil or bad it's just the nature of any kind of framework any kind of framework must be less than perfectly General and must at some point cause you pain it just will happen and so you as a general rule keep yourself at arms length from Frameworks anybody doing a dependency injection using what spring or something else yeah okay so um do these tools want you to instrument your business rules with little twiddly things annotations or attributes or something a lot of them will do that the spring framework for example wants you to put at autowired in all of your business rules they want you to smear the framework throughout your business rules I would I would suggest you not do that I would find a better way to decouple from your from your dependency injector how much do you inject in your depend with your dependency injector are you injecting everything probably shouldn't be dependency injection is a lovely idea but it's not not the kind of thing where you want to inject thousands of objects into your system you probably want to inject a few strategic strategies and factories so that and you want to inject them in a safe part of your code and then pass them around the rest of your code in normal ways general principles you keep yourself safe from these Frameworks sorry looking at I'm sorry I have to stop this oh okay sorry I guess we're done
