 When you are producing something any work that you do people work hard they get exhausted things happen you have checklist but you will still find that some mistakes will slip through how can we create a process so that these mistakes do not happen again it is okay to make mistakes once but do not keep making the same mistakes again and again. So that is where pokayoko was introduced poka means inadvertent mistake and yoke means prevent how can we prevent mistakes from happening. Let us look at before we get into examples I will just sort of quickly classify the two types of poka yokes that exist and once you see them you will be able to start connecting the dots together there are two types of poka yoke devices the first one is what is called control poka yoke and the second one is what is called warning poka yoke now in a control poka yoke the process is designed in such a manner that you would not be able to make a mistake you would actually go through the process step by step yourself without even realizing what is going on what is happening and you would get the right thing done there is no chance of an error occurring in that process and the other process is a warning poka yoke which means that the moment the error occurs is going to flash some sort of a message to you or some sort of a warning to you to tell you looks like you made a mistake right so these are these two categories ideally in an in an ideal world we would like things to never go wrong right so we would try and aim for control poka yokes as much as possible but you would automatically as we proceed through the talk realize instances where it makes more sense to have warning poka yokes rather than having control poka yokes so let us look at some of the examples in the manufacturing industry let's say I have the engine which is going to be very hot I have some sort of a component that's really hot and I want to make sure that I make use of bolts which are heat resistant but I have other bolts also which I am using for my manufacturing process right how do I ensure that the worker doesn't go and screw on the wrong bolt you'll screw on the wrong bolt everything will work fine right now but after some point in time when it gets hot that bolt is going to break crack melt something is going to happen so you're going to go and have to check right later down the line okay did the guys use the right bolt so what you would do a simple solution most of us will come up with let's color coded right so let's color code the bolt and I immediately know but what if a person is so there are people by the way you cannot distinguish colors you won't even come to know but there are people I suppose it's difficult to believe so a more elegant solution to this is make the size of the bolt slightly different from all the other bolts that's quite simple now he's not going to be able to put the wrong bolt in it's which becomes a control pokai of mechanism so you make special the heat resistant bolts which are most likely going to be the more expensive components of your parts slightly different in size from all the other bolts it will work both ways those bolts will not fit in a low expensive place and it will also work in the right place right so it's it is sort of has a nice healthy side effect another interesting example is in in in a car manufacturing plant you don't have different conveyor belts for different cars it just doesn't make any sense for manufacturers to do that it's the same conveyor belt but different models of the cars are coming down the same belt now different depending on which model it is it's going to have a different tire of course and then the bolts that go on that tire need to be tightened based on which and what is the size of that tire now how can you test if that bolt is is tightened just right there are chances that you can tighten a bolt too much and when the car is on the road it will go about a speed breaker after 2500 speed breakers it will crack because it was tightened too much or maybe it's too it's not been tightened enough and it will come off by itself how do you check for something tight enough it's weird right it's not an easy problem to solve how do you check for something that's just tight right right so what the what car manufacturers do they have this torque gun and this torque gun is pre-connected to a control system so when that car comes down this top gun actually gets a set point which says you only have to tighten it this much and the person doesn't get any control to choose how long to press it the moment he presses it that top just goes to that much amount of level and switches off you can keep it pressed it makes no difference you can leave it early it would still go on for the full line so that's again a control pokai of mechanism it's sort of ensuring that the bolt is tightened just right as much as needs to be tightened and not more let's look at in an ER room these are the various gases that are usually you can see in in common ER rooms which are needed during an emergency nitrous oxide medical oxide vacuum and so on obviously you do not want the doctor in an emergency to put vacuum right when if you need oxygen so they have color coded it but if you look more closely you also want to make sure that when these pipes are connected they're not connected to the wrong one right so the guy who has to make these connections has to make sure it does them right and and that's where what is called the pin index safety system comes into play so you see these these arrangements here which are in different angles the pins these pins are different and they have been standardized so you can't go and plug in something wrong into the wrong socket again a control pokai of mechanism you can only plug the right thing into the right socket this is should be a much more familiar example the problem what's the problem here the problem is you don't want a car to have all your luggage on it 40 kgs for people coming from abroad to India and then you put it on the cart and then it goes travels you want to make sure that the cart stops but you don't want to bring in a mechanism that people have to remember to push a pull a break push a pull a break in you know right we heard banquet story today of how he sidelined the treadmill so if you don't want to push and pull you're going to forget to put it on and it will still slide you want a mechanism that's part of your process what is the process I have once I put stuff on the on the cart I want to push it the push mechanism itself is going to happen irrespective of your pokai so let's put it in between so when you push the cart it will unlock itself and you can take it when you let go of the cart it stops there another control pokai mechanism so that's the idea see what would happen if you make this a control pokai you're saying I don't trust the judgment of the person I'm letting go of all the independence of thought that you have I'm taking over now I'm putting you in a framework boundary and saying this boundary is what you live in if I'm in a hurry if I if there is an emergency and my car is not starting now just because I can't put on a seat belt and there are reasons where you will not be able to put on a seat belt that's just not acceptable I'm not taking this car you don't want to lose control you want to bring in pokai you at the right time so you have to be pragmatic you can't let go of your thought process it has to be you still have to give people the independence of choosing it so a warning pokai you can this in this fashion so now that we've seen some examples in the real world let's switch over to software and see what happens in software when these things get translated what I'm going to do I'm going to first show you UI design software for end users and how pokai yokes have been implemented for end users and then we'll switch over to how development teams can use them for making stuff even better here's your first example creating a password or something that most of us might be familiar with you see a double box the double box is there for what reason to make sure that you don't make a mistake when you're entering it you can't see your password right let's say you entered something and then you don't know what it was that you entered very simple pokai look at the other one on the left side the password strength that's very interesting the password strength is telling you the strength while you are typing and this is very important you might think of yourself as very smart this is a very cool password it's nobody will be able to guess it but you don't actually have the real data what are the kinds of passwords that people actually create and what is it that's common and what is in common but that's data that these applications have the cloud knows that what is it that most people are using what is it that's common and what is it that can be broken well there is a a sort of libraries that can check for what is called lead speak L E E T and L E E T itself can is usually written as one three three seven because it looks like L E E T lead speak consists of vocabulary of words where you replace normal characters with ASCII symbols or with numbers and people seem to do that very frequently thinking that you know it's so it's so smart right like secret can be written as s3 cr3t it's a lead speak vocabulary word it can easily be broken there's nothing about it and there are lots and lots of such libraries that can catch these things so definitely it a secret is a weaker password than s3 cr3t but it's not strong enough and that's something that these guys will tell you that you're not using a strong password it's so obvious because you're using lead speak and that's where you're helping end users from mistake-proofing they're not doing it intentionally these mistakes are not intentional mistakes there are mistakes that are happening while you are sort of and you are thinking from the end users perspective while designing a software you don't want them to make a mistake so you mistake proof it this is another very interesting example this was an example that I actually emailed to Google when I was using Gmail lots of years back saying you know what I have done this a multiple number of times that I would write a sentence saying I have attached the following document for you to check let me know if it looks good and I forgot to attach right it's happened to most of us I was pretty surprised to see that feature there after almost six months after I wrote that email you send this and you get this message right now it says you wrote I have attached in your message but there are no files attached send it anyway mistake proofing right another one it will make you sound weird but this is also an example that had emailed them on the same day along with attachment because I've done this to I had John in two different companies as my customers and when I sent mail I sent it to the wrong John right but I told I was like you know what the email software knows it knows that I keep sending mails to this group so frequently that I had to send it to that John why did it send it if I have chosen a different John can't you tell me you know what this is not the group John that you usually send to did you mean the other John yes I guess I'm saying give me this feature and read my mails I don't care you know it's it's like that but I agree with you definitely definitely that makes sense so the idea is to understand the thought process of your customers and see what is it that the mistakes that they make and then try and fix them right try and help them not make these mistakes that's when they love your software way more there are a lot of other examples but for because of sake of time I'm not going to skip into development so that we get more deep inside take a step by step so the thing I want to talk about today which is actually something that I'm a lot more passionate about in poker yokes is when we work as teams teams nowadays have you heard of this term distributed agile it's become like the next buzzword so agile was one buzzword earlier it came in then distributed agile came in and there are newer ones I just won't say them right now but distributed agile basically means these things to people when they think of distributed agile all they're saying is we are going to encounter these challenges and we are going to do do very well through these challenges and it's a common thing even if you don't think distributed agile if you think of big teams remote teams people sitting here and there a lot of times you create checklists or you write an email with a bold font and you say you know what make sure next time when you do something like this don't do this this this or this or make sure before you send this or test this out or check this do these four things until you don't do these four things don't send something out these are indicators for you to think about poker yokes and these are things that I'm going to show you how it works so the idea is you want to make sure that in a team people don't make mistakes and don't repeat mistakes that you already know can occur right those are the things you want to avoid so simple things unit test it's like classic poker yoking it's it's got all those features of what a good poker yoke is supposed to have it supposed to be precise the moment it breaks you should be able to come to know what's happening it should be light it should be easy to maintain yes I know that there are unit tests that don't meet these criterias those are bad unit tests and that means those are bad poker yokes but unit tests mean this unit test means that the moment things break I'm going to tell you that's the quality of a poker yoke the moment something breaks it should tell you at that point it shouldn't come after three days you know what you did something wrong that's not a poker yoke anymore poker yokes have to be early they have to be precise build radiators compared with unit tests coupled with CI servers the moment you check in code you should immediately see a green or a red light and it's immediate is the important point not after 60 minutes or 45 minutes immediate means immediate means something that people will not just walk away from after checking usually that's under five minutes even if within five minutes I don't know what's happening it's not a poker yoke it's not going to help you people will walk away right ID is warning poker yokes while you're writing they will tell you simple examples that we can relate to let's let's look at more examples compilers are obvious they will tell you that you made a mistake but take it to the next level think of statically type languages think of Scala there are things that you can do with compilers nowadays for instance they can check your SQL query against the database at compile time and tell you that your SQL query is wrong those are not things you could have done earlier but there are there are features like that that are available to check right at compile time that your SQL query is wrong think of check-ins and think of the things you ask developers to look at before you check-in a check-in requires you to make sure that you have put a comment make sure you put the Jira issue ID make sure that if you're pair programming both the developers names are there because that's not going to be caught by by any of the version control systems make sure you don't check in when the build is read make sure that you run all the unit test check in into VCS right these are things we have a checklist for most people just have to follow these and a lot of us don't do it one of the other things slips through but instead of that a lot of teams what they do they have a pre-commit script it's the script job to actually find out all of these it'll ask you to enter the message the pre-commit script will ask you for the issue number it will ask you enter the developer's name it will also go and verify first whether the build is read or not if it's already ready to disallow your check-in these are the things and it can also check for new files so many times we've done a check-in and new files have skills have just gone through right why why should your team keep making the same mistakes again and again ask the team to create a pre-commit script and use that script across projects not just on your project and we do it all the time at ThoughtWorks autosave obvious control pokaiok right okay now these were certain examples are what I wanted to go next into was architectural examples of pokaiok how can you create architectures which will ensure that your system is mistake proof your system and developers were using these architectures were writing code in these architectures they don't just go in and do whatever and then it blows up back on your face and especially for things that you know blow up so one example for instance is the HTTP session how many people here know what is an HTTP session just before I okay there are people who are familiar alright so an HTTP session is actually supposed to be used for session right you're supposed to use an HTTP session to identify session you're not supposed to use an HTTP session like a knapsack bag in which you just go and stuff everything into it and pass it on around in pages agreed lots of problems there first of all you don't know who all I stuffed whatever into HTTP session then when you get into clustering you have to keep all these sessions all the synchronized so that when the request goes to some other server you want things to go right so you don't want people to do this so what do you do you take away that ability to do this right you create a framework for your own team and you say that you will not get access to HTTP session you will have a method which says get session ID because that's what you need and for everything else that you want to do I'm you gonna have to call the appropriate data structure go find out what is appropriate data structure for doing credit card storage or for storing the username or for storing the color of the last page that I visited but don't put it in the HTTP session so think about the problems and and remove the control away then in that case if you are working in a team where people don't understand this you have to understand the context don't apply any of this without context if your team is smart enough all of them understand that they are never supposed to use HTTP session for this purpose don't waste your time creating a poker yoke okay similarly context specific injections if you know the context of your application if you know that this is let's say a get context that means I'm performing a get operation you do not want any updates to happen to your system right rest don't don't make any updates HTTP says get call that means read only call so think about this and say what can I do to make sure that people are not going to write code that will go and update the system one example of not is giving a read only database connection that's quite easy right nowadays you can create a session and a hibernate session and say this is only a read only hibernate session so when it's a get call I will inject only a session that has only read only capability you can go and call any API you want to call as a developer eventually it will never get committed it it depends yes and that's something you have to decide based on your context whether you would like an error to be thrown or not in some cases you may not in some cases you may right if the developer knows now you know what my my tech lead is smart enough and he has already taken care of all these things I don't care I can go and call these three for API's because my code becomes much cleaner by calling them in this sequence I can reuse certain method don't worry even though this was supposed to go and update it will not update because it's it's a read only connection so sometimes people work around this right they sort of become a little lazy but you know it's okay they can do it if the code becomes more readable the trade-off is acceptable right so context specific injection understanding the context and putting inserting the services using DI or whatever to make sure that they are correct he's doesn't go and update and call services which you don't want to call understand the context for instance rails allows you to do things like you can say am I in dev context am I in test context am I in production context based on the context automatically the right services get injected you don't have to write your if codes oh if this if that and then again figure out the whole thing again make a mistake the architecture is taking care for you for this run under least privilege very famous run under least privilege says that you should make sure that your application your process should always be running under the lowest possible privilege so that somebody doesn't come in and go as a hijack your system operating systems do this all the time they make sure that the process that is created it has the lowest level privilege so that if a virus comes in or if something comes in takes over your process it will have no access to be able to write anywhere outside its memory area you're making me are helping the developers and the people who are writing the program from not having to worry about these mistakes or these issues or these things that you have already solved right another example of running under least privilege which a lot of people seem to forget for some reason is making sure that your database connection does not have DBA or admin rights right your database connection for an app only needs to access this these three tables then it should only have access to those three tables even if you get SQL injected it makes no difference let let them come to know these three data okay let's say whatever at least it's much lesser they're not going to wipe out the rest of your database because the original connection that they have itself doesn't have access to other things right so so try and sort of think through some of these things if you are just a reporting application it doesn't need update access to the database why should the connection have an update write itself give it a read-only access to the database run under least privilege yeah so unfortunately most of the answers to such questions are it depends right like so it depends on on what is it that you want to achieve so let's let's just let me answer this question in a in an indirect manner when should you use a poker yoke right you should use a poker yoke in two situations one situation is if you think that mistake is happening too frequently right so if you can actually seeing issues occurring like these two frequently and you know that your team is messing it up then you'll have to bring in a poker yoke or you will have to keep suffer the consequences right so if you see if you see in your application this issue and you say okay okay looks like we need a poker yoke that's when you will separate the connection pools if you feel that you don't need it just don't go ahead and do it don't like don't create rules like you have to every step you take in your in your development process as well as in your life has to be based based on not rules but pragmatism right you have to decide based on your current situation what is it that you want to do next and don't rules are there to help you to make the next decision so that the second reason why you would do a poker yoke is if the blast radius is very large of that issue it may not happen many times but if it happens even once you screwed right so far for example what would be a blast radius nice if you think the password gets logged in a log file or if you think something will slip through even if it happens once you know you don't want that to happen it's just bad reputation for your company or for your project then you must put in a poker yoke right you must put in that checks is this should never go through because I cannot afford it to go through if you think it's happened too many times that's your second clue don't put in a that you need to put in a poker yoke how many people here have heard of the circuit breaker pattern okay so there is this very nice book called release it by Michael Nagard you must read that book even if not for circuit breaker just like go ahead and read it it'll tell you about how to release software and how to create software that is production ready there's a very good explanation and that's where this pattern was introduced it's called the circuit breaker pattern a circuit breaker pattern is very much like in your house you have a circuit breaker the moment too much electricity travels through it the circuit breaker opens itself so that nothing more happens what does it do it saves the rest of your house right that's that's the idea right so it's a it's exactly the same pattern in programming that is used and it's actually it's it's now become very very common you will find most frameworks and and most production systems implementing the circuit breaker pattern the idea is if you have a service on this side and this and the there is a circuit breaker put in between the job of the circuit breaker is to detect that at any point in time if this call to service fails for instance it times out or it doesn't give a response or it throws an exception the circuit breaker will open up what this means is that after this point in time when the circuit breaker has opened any calls to that service will immediately be returned we returned with an exception saying I am right now open or there is something wrong with the service how does this help this helps both the people it helps the person who's calling immediately come to know that this service is done instead of getting blocked that oh after two minutes I'll get a response so after three minutes I might get and you will have a flurry of requests coming from this side all of them waiting for this service to open right but now because there is a circuit breaker it's immediately returning things back and not locking down this system not locking this person down how does it help the person on this side the app is the service on this side gets a lot of time to recover right now it's already under problem and then you coming in and sending me request one after the other one after the other what do you think is going to happen to serve the whole system here will also go down and this system will get blocked so what what the circuit breaker pattern does is it opens itself up for a specific period of time and for that period of time it will not allow anybody to go in it could be set to two minutes it could be set to three minutes that will depend on whether your system on this side has a capability to recover and what you think that time is after that point in time it will again close and it allow one service one of one call to go in it's called the half open state or the half close state it's the same thing it's like a half cup so it goes half down and it allows only one call to go through if that call succeeds it will fully shut itself then saying okay looks like the system is back on if that single call doesn't succeed it'll again open backs back itself up and it's a pretty good pattern it's mistake proofing both the system it's ensuring things don't blow up it's making sure that you don't have to worry about such issues and things are taken care of for yourself you can implement them in many mechanisms there's a very nice elegant aspect oriented way of implementing it so that you can put aspects around the the service method calls itself and you don't have to make it as part of the individual code another example there's primitives versus types you can go around passing primitives you can say this is a money value for instance or you can say this is a string that holds something or this is a number that holds something as an API designer I can return a number I can return a string the problem with doing things like this is you have you lose control over that value the moment you return something now another developer is free to go and update whatever it wants to do to it but if there is a business logic that is associated with it and if you actually wrap it up into an object and only expose methods that will make sure that the consistency of this value doesn't change then you're ensuring that once I pass something on down to somebody else those developers the coders were using this value they're not going to go and mess up with it because they don't have any methods to go and mess up with it right that's the idea of using a type rather than using a primitive even better which is something that even Venker talked about in some sense today was immutability if your objects are being returned in a manner that they're immutable which means that you cannot modify their states then you can be a hundred percent sure that none of the developers none of the code none of the APIs or the lines which are using this object after you've returned are actually ever going to modify its value and therefore what you are returning is always going to remain consistent with what's going through right some more interesting examples password log check another very common problem people will go ahead and log credit card numbers while debugging they might log a password while debugging they might log a CVV number by debugging because they just put a printer and statement for some other reason they weren't sure and they forgot to take it out and it got checked in how do you sort of make sure this doesn't happen right you want to mistake prove this error one idea for this is automation if you have functional automation or any form of automation in place you will find that most of the testers in the testing team will use the same sets of passwords and credit card numbers for their testing maybe a set of five set of six but that's it it's a small set you can easily go and check and grab the log files periodically of the automated machine to make sure that that set does not exist in any of your log files right so far in because you know that these are the sets that are running through these are the sets that are going through you know that this is the credit card number being used just just right as part of your automated testing after the testing is done one poker script its job is only to check that none of the passwords have gotten logged right and you can catch that immediately live data testing and very interesting example I'd like to share here I used to work on a travel project and very interestingly and don't ask me the reasons but it's true for many travel companies they do not have access to testing services when they do flight bookings for testing they're actually doing live bookings so we were actually hitting the real GDSS for all our testing and it's not just a problem we had with one travel customer it seems it's a problem across travel companies people who worked in the travel domain will share their experience with you on how it is when you're actually doing testing against live data and what are the precautions that you have to take while testing against live data so we had this email given to us which used to say make sure your test bookings are at least three to six months in advance make sure that they're not around any of the holiday season which means don't book against Christmas make sure that they're not against these three travel agencies because these guys don't honor and like our test bookings on them but you can go and book against this large you know carrier because they are they're like okay it's okay if you take a few bookings from here and there for us right and don't do more than n number of bookings per day or per hour or during this slot all of those things and okay so we tried our best we made sure that whenever we did a test booking we wouldn't we would book you always select in some sense on our test page automatically the date selector was six months in advance so that people didn't you know select a date as today but it's quite common yeah you need you need to have discipline to click on that next next six months in advance right it's so much easier to click today but within I think two months of our project this our customer got a $20,000 bill from a from an airline agency for for what for having raised the prices of that of their airline for a particular day because somehow one of our test program went and did lots of bookings and lots of cancellations for that particular day and because of so many bookings and cancellations they thought that they're having a good time and they raised the prices because of the raised prices the customers who are actually wanting to book that they didn't book their flights so they lost revenue and that lost revenue they sent us a bill right so you see what's happening it's it's really silly right that that for building software you can't put in a software check for things like this right you can easily put a check at the service level which will check these rules for you so that you don't have to write these checklists and you don't have to send emails to people saying it will just reject your booking if it doesn't fall into this category how big or difficult a task this isn't right but it's not so obvious for some reason every time like when you discuss things like this oh yeah I know I know exercising is good for me but do it like you don't think so much about it keyboard shortcuts another example if you notice in desktop applications we have this feature where you can press alt and then the accelerator and n is highlighted and o is highlighted and c is highlighted it's a good feature we all as programmers love you know having to use the keyboard rather than using the mouse there is a problem there what happens is when you translate this into other languages the translator actually translates these menu items and how you how you actually put an underline is you put an ampersand sign in before the character for which you want the accelerator to be specified now that accelerator ampersand is actually put by the translators for the language that they are because they see this file and say oh yeah I have to put this ampersand but the translator doesn't understand a where is it going to be used what's the menu option and and the most important characteristic of these are that they have to be unique for a menu right you can't have two of them both with n when you press alt and which one is going to be hit so so how do you sort of catch this defect right translators send these files back to you and now in French language there are three characters which I have got the underline and right under the same because they both all three start with the same character in that language it's quite it's quite common actually for something like this to happen but who's going to go and check this how many people are going to sit and test in each language whether the accelerator keys are the same so you put in a script the script job is very simple go through each translation file scan and check that for a menu are all the values different don't don't you know like don't waste time doing things yourself so the point I guess that I've been trying to get awareness and built into people here is to say that whenever you sit down to think about writing a bold font email whenever you're sitting and creating a checklist for your team whenever you are thinking at some point in time that you know what should I tell these people never to do this all over again pause and think can you firstly change the process in such a manner that the mistakes will not happen again if that's not possible can you create a warning poker you which will catch that mistake the moment it happens think about it if you think that's possible go ahead and create it if that's not possible then think about whether you think the email is important thank you people you can visit my blog there are lots of examples of poker you there in software and a much more detailed explanation than I could possibly give today any questions sorry I'm out of time but you can ask me questions