 Hi, good morning. Thank you so much for this turn out this early in the morning especially at the far end of the city. We have all had to brave the very infamous Bangalore traffic to be here. My name is Patil Kalya. I lead engineering in uncommon Bangalore and I am going to be talking about how we do or how we can do better, more efficient, more effective mobile engineering. Uncommon is agency that does product design and we specialize in large scale Android applications and these are some of the clients that we've worked with over the past four years of our existence. So if you look at the list there's actually a whole bunch of them. Small self-funded startups to nonprofits to large corporate conglomerates and the talk content largely comes from my experiences on working with these companies and how we learned that things that could be done better and things that were definitely of us across a lot of these places. This is not an exhaustive list. I throw up this list based on brands that people are familiar with. There's a long list and others that we can't really talk about. So let's see. We're going to go through four different sections today. First one where I contrast mobile engineering with web engineering. Specifically web engineering because largely most of us who move to mobile engineering from other engineering backgrounds did it from some form of web engineering and even if we did not move even if you started off with mobile engineering you really cannot work with mobile without actually having to interact with the web and having to deal with the services and things like that. Then start design which does not really mean does not entirely mean just UI design. I mean everything which is which means how do you build a cohesive product? What do you the features that you put in? How do you design them? How do you make them be visual? How do you plan your features and things like that? Then there's the platforms themselves which is the mobile platforms that we all work with which is Android, iOS, React Native, BWA's and all those things and then there's culture which is important I'd say probably the most important part because you can't do engineering without actually having a strong engineering culture and your efficiencies will drop and you will have problems unless you're able to build a strong and foster a strong culture of engineering across your organization. So, let's get started. So contrasting with the web one of the things that most people face when they have moved to doing mobile engineering is one of those realizations that dawns on most people is that there is a significant reduction in speed and that largely stems from two different things one that on a mobile device whether it's Android, iOS or I'm going to talk largely native here the UI is very tightly coupled to the rest of the application which is that if you if you're familiar with how a regular website works you have over the years there is a significant there are significant layers in how a web application works there is a UI layer which is that largely just HTML and CSS there is a middle layer which would do some sort of scripting and things like that there's a back-end layer and they're all very well defined on a mobile platform considering it's something that you hold in your hand or perhaps hold both your hands if you're using a tablet this is something that's very tightly coupled which brings in a significant delay if you are going to change things on the UI now on the other side of it changing things to the back-end also causes a significant impact to how a mobile application sort of develops over its life cycle and I have this really weird diagram I don't know how many people can actually read that I'm going to point this out here so this section is what say a regular let's say a project that's a web project application that you might be building this is sort of what it might look like which is that the trifecta of the product team and the back-end team and the front-end team who are working together somewhat in parallel to build this product that needs to be finished in time and product sort of starts so sure if you're going time going from here to here product team starts off in the beginning there's some design there's some ideas about what you want the final product to look like and somewhere along the line the back-end and the front-end sort of start parallely more or less and as the product develops the back-end develops and the front-end develops but largely there is a significant amount of independence when it comes to the web the same thing if you follow on the mobile there is this unexplained gap that I have seen most people get very flummoxed they don't understand I don't I don't get it I don't get it just a just a shopping app it's just a list of things that you're buying how why is it taking so much time why is it so hard for me to why is it so hard for you to change this grid of things here to a scrawlable list of things and these are like this is just one of the questions but these are questions that repeatedly time and again come up especially as for us in a nascent developing market where more and more organizations are moving from the web to mobile and still are in fact we are very heavily invested in mobile but we still there are organizations onboarding every day this is something I constantly amazes people that wow why does this happen and apart from the like largely being the UI and the back-end these changes to these systems later during of us a midway during a product lifecycle cause a significant impact to how the front-end reacts to this because unlike a website if you do actually change they the back-end where you are expecting a certain response of a certain type and you change that at some point without actually telling your front-end an iPhone app or an Android application will just crash and like a website which will potentially just give a blank screen or might throw a strange error user the sort of okay with that I guess we've been on the web for a long time we've been on the web for more than a decade like 20 years and we're sort of okay with that right we're sort of okay with websites kind of not working or why isn't it working F5 F5 refresh this thing it'll work eventually everyone's accustomed to board exam results coming out of things that's not working these are these are things that just that people are okay with on the mobile side of things these are sort of unacceptable people just don't understand this why why would this take so much time what is it that changes things a lot in when it comes to mobile and I think it's a sort of a double-edged sword it is a negative it's a disadvantage that the UI so tightly coupled is a disadvantage that that the back-end can actually cause sort of disaster on your client but there are advantages to it as well and as you see later on I'll talk about some of those things as well no dynamic updates ouch this one continues to hit people regardless of how much time this went including me I've been doing this for many many years and this is something that I wish I had a permanent solution to but there isn't an unforeseen delays that are not controlled by us to cause problems where you are already in production and you sort of realize that whoops I need to change something and now it'll take me a two week release cycle to sort of push it out and it'll take another two weeks or users to get the update half of them might not update and whatever this is a huge problem and this came about because of the closed store model which is very different from what people expect from the web where is that there is no store model there are no large gigantic corporations controlling our stores here there is we unfortunately have to submit to Apple and Google in this case and go by what they want there are programs and there are efforts being done to fix this largely being react native one probably the most popular one and react native is a very controversial topic on various ways I'm not going to talk about why it's better why it's worse and things like that but I will talk about one thing which is I think something that people sort of don't realize and it's something that we were discussing last week at the open house as well which is that react native adds a maintenance overhead to your system if you're regardless of whether you're doing Android or iOS which means that you're probably dealing with Java slash Kotlin or you're dealing with slash Objective C you are now adding and introducing another framework which is written on a completely different stack and a complete different language which means that your tech team now needs to be well-versed with the not only with the idiomatic ways of doing things in that language whether it's Java script or pure script or closest to whatever they also need to know how to do it if you had expertise in Java or if you had expertise in Swift now you need to build expertise in this and that is an overhead to every team and which is probably the most common sort of excuse I give to people against react native everything else is great it's a great effort and I think it is actually important for us to learn a lot of things from what react native has done but this is something that one really should keep in mind also I like to say there is a lot but I don't remember where this comes from but if you give the ability if you give people the ability to ship code all the time they're going to ship bad code really fast all the time and you can't help that that's just human nature it's not that programmers want to ship bad code is that we're largely just adding bugs to things all the time that's what we do yeah bugs lots of versions I mentioned it a couple of minutes ago but at any given point in time because of the closed-door model and because of the fact that you cannot really control or ensure that every wall of your user base using the latest version your system will have multiple versions live at any time this is something that I'm hoping audience here is very well but this brings in a very tricky point to how do you actually mitigate the risk that comes with this because that means that now every time that you have a backend change that needs to be made you have to now use versioned APIs to get away with things like this because you now need to ensure that okay these three versions that are kind of make up the 90% of my user base I have to maintain all three maybe you did a game breaking change somewhere in the middle of those in version 2 of the API now you need to your backend team now has a huge overhead of not only running version 1 but version 2 but version 3 also not to mention those last 10% people which might be on version 0.7 alpha 2 and it's always a headache you know you might be on a large revenue generating system think about it in terms of a company like Uber or a company like Gojek or a company like Flipkart at this at that scale where you have millions of concurrent users millions of daily use daily active users it's a huge pain and its versioned APIs are definitely one of the things that people very strongly use all the time but it is still something that adds to that time of stretching out how much time it takes to build a mobile system a remote quick switch is something else that a lot of organizations study a lot especially a lot of large-scale applications do build in because not because they want to prevent access to users prevent access to their systems but at some point in time you will realize that I have moved five versions ahead at this point and now I have to maintain this really old part that we've refactored to be something better I have to maintain this because four and a half percent of my users are using this a system like a remote kids where you can effectively force the user force the application to basically say sorry your applications to or please update to continue it's kind of kind of a bad thing to sort of lock out the user like that but then also you at that point you really have no option because you are now adding technical debt for simply to your own system and you don't really want to do that you don't want to be in that situation where you're willingly adding this and as a disaster control measure and as a way to keep your technical debt in check that's something that a lot of section to product design consistency is somewhat of an expectation on mobile devices on Android and on iOS this is something that continue that for the longest time on Android especially used to flummox people a lot and even inexperienced users even you know like how people say young users or very old previous generation there is a certain expectation of consistency that people have with the platform and largely that came about because of the push from our corporate overlords because both Google and Apple Google later than Apple have significant push and they've really tried to channel and sort of push people towards push developers towards understanding that an expert towards understanding and explaining that it is important to have consistency in UI design that is completely missing from web design one if you look at one website versus the other website there was no really there were trends that came about in the early 90s there were all the blink tags and they were markies everywhere and then there was a web 2.0 where everything on flat and things like that nice geometric lines everywhere those are things that happened out of trends but the way these mobile systems have changed over the past few years like even just in the last 10 years the amount of changes in UI and the expectations that people have had change so fast because there is a constant push from a single entity that controls this and this leads to unintended side effects that us as engineers and builders of things need to understand like the back button confirmation thing so many people I guess this is another thing that is vestigial from desktop users from the days of the desktop on windows and macOS is that when you on Android if you click the back button there is some of those irritating games and apps will say press back again to exit and the air-to-lab for one is probably the only one on my phone that I have to use and is on that this is me of every time every single time I have to double press the back button I realize that this the people who are running the show they really don't understand how this is supposed to work on iOS we have slight to go back and for the longest time after this gesture was introduced to Apple my friends who used to use iOS used to constantly get pissed because they became accustomed to using slight to go back on their phones for a very quickly because with that with the US update Apple ensured that all their apps work with it but the other apps did not and then you now have a broken experience where either there is a time delay in people realizing this or people just never realize this because they're not paying attention because the platform is moving so fast low tolerance towards jank how many of us know what jank is how many of us deal with jank every day even now okay anyone who doesn't ever experience jank on the world okay I was hoping that maybe there's one person I want to ask them what what is the secret to this but this is again something that is very mobile specific and largely not something that you see in other platforms quick question of the percentage of applications that are downloaded from the app store or the play store what percentage are apps and what percentage are games okay what percentage of the entire app downloaded always over the lifetime of the app store do you think is applications do you think 99% is apps or not your phone I mean like worldwide I'm not talking about how take a guess on like 70 to 75% apps and 25 20 to 25% games okay that's correct so so Apple's own estimates about 87% of all apps and the play store the app store unfortunately eats up reviews of older versions so we don't really have comprehensive data but the play store is full of reviews of badly performing games everywhere and this is not just on this is not just due to the fact that Android actually has a huge disparity in terms of the devices that it provides but even on like much like even on like really well performing really modern device I use a pixel XL and pretty much every game in some form will sort of start here in there and that's not okay it's not okay because I think we've been trained by the PC gaming era and by playstations on the Xbox is that game sort of frame and which is I think one of the reasons why gamers especially ones who are able tend to know things like what is what are frames per second but on the mobile devices even even in terms of applications performance becomes really really important and people sort of I think somewhere they haven't let go of the early the expectations that they had from the early Nokia and Motorola phones where if you turn the phone on it just turned on and if you when you said call Pratul it just called Pratul if I if I at this point if I use a Moto G or like you know an iPhone 4s or an iPhone 5 like if I unlock the screen there is a significant two minute two second delay and which Apple will nicely animate all the icons from space slowly into the dashboard like you know trying to trying to fool me into thinking that this is working everything's working really fine but there are no efforts like that have come into the mobile space because performance is important and these devices are constantly battling between how do we ensure we get the maximum battery life which means that we use the least amount of energy which means our SOC's must be energy efficient but users also want really fast devices these are these are completely orthogonal to each other and in fact they're competing there's no way you can have both at least we're proving but they're still they are orthogonal to each other and apart from performance being important it's also important to have perceived to understand perceived speed and sort of take advantage of it and it's something that Apple is really good at and I think Google sort of caught up with it and I'd say on or even on Android developers have caught up with it which is that if things are not always fast which they aren't you already know you already know you're probably doing this every day day in and day out you stay at your phones you're building applications you know that performance isn't always fast which means that it becomes important to how do I make the user feel that it's actually working fine how does my end user how does he or she know not to know that this is slow but it looks all cool one of the ways people do that like for instance the lock screen animation that iPhone puts in is one of those ways and it's something that is very new to people especially I'd say to folks getting onboarded onto mobile now it's sort of they realize it when they use their own devices but they don't realize it when they're building these applications out so one very large company that we work with who I'm not going to name the senior management that that company was very very amazed at the fact that it took use to take us some amount of time by some I mean 500 I think it's 400 milliseconds to actually start the application and in those 400 milliseconds they had to actually see sort of a blank canvas of the application and it's one of those times when I realized that even though this very same person I'm sure when they go back home and when they you know pick up their iPad or they got their phone to look at Google Maps directions they creep about the fact that there's jank but they also want us to put in the same thing here and they want us to you know fool the user into these things but that's happened that happened then this those are tricks of the trade mobile devices have extremely personal information I'm going to bring this in into product design because this is part of you designing the product because it's part of you making a conscious choice as to how the product should be like and it's important because especially in today's age where fundamentalism unfortunately is on the rise across the globe and across every facet of our lives it's user privacy is critical and which means it becomes very important for us as engineers and as product designers to be responsible for how we're using our users data and how is it that we're actually building features and do we really need all of that data that we're collecting does my product actually need to collect all of the things that I collect to build the feature a very famous example of this was given by Jesse Wilson from square it's a it's a very common example but Jesse pointed out in a talk which is that one of the very common features that most applications these days have is who other in my contacts who else in my contact list is using this application and the sort of straightforward way the easy way to do that on like very obvious way to do that is to upload your entire the user's full contact list on to your server and then compare who other who else in the has on my server has the same phone number in their contact list okay these people must know each other therefore I can show it la la la except now you have a problem on their hands because now you are storing my entire phone book on your server which means tomorrow if you get broken into you are responsible for leaking my phone number to slash my friends and my family's personal phone numbers out into the world Jesse Wilson pointed out that they're not the very easy and so not so obvious ways to build the same thing would be to use a very fast hashing function on the phone so instead of you uploading the user's entire contact list and storing the contacts list everywhere why not just hash the user's user's phone number using something really fast like md5 or even shower it doesn't need to be secure it just needs to be fast and instead upload the hashes and then compare the hashes you build the product in the exact same way and it's still telling the user the exact same thing but you're not now you don't at night need to wonder about am I ensuring that my data centers are using are storing this information safely or not and this is sort of this is important because there are legal implications to engineering turning a blind eye towards this as recently pointed out by the Volkswagen diesel cheating case I don't know how many of you know that but Volkswagen cheated on their diesel emissions they specifically designed parts of their engine to cheat and tell the emission testing authority that they were actually admitting less harmful gases when they were actually not and one of the folks who was actually I think handed a sentence in this was one of the engineering leads and it's sort of telling because at that point at this point we're all working with organizations and all of us deal with user data it is as much of as it is as much of our responsibility as it is of the product responsibility to build these features well and think of better ways of doing this it's going to the platforms themselves Android and iOS are both very new platforms they might be a decade old but if you look at the sort of spectrum of computing itself they're very very new the app store was launched about two years after the iPhone was released which means that in the app store and the whole app economy the multi-billion dollar app economy which is why we are all here is not even 10 years old they're also controlled by secretive corporate giants who don't always like to tell us the full story which means that you never really know as to what new decision they might take tomorrow which might impact the way your app works or your system works and these platforms haven't had time to mature entirely because we are still learning right we are still learning how do we how do I build the build this app in the best way for android and it's not just us who are learning it's also google and apple that they're learning and it's not uncommon for us to come across issues in the framework itself or like bugs in the framework and realize that oh you know something might got messed up by apple and google that which means that it is sort of a it makes it hard for us as engineers to build things really well unfortunately uh related to this badly behaved applications don't work on the play store slash app store at all and that's because they themselves penalize us for it by now apple and google have both gone public on this that uh if you if your app does not perform well they do rank it lower in terms of searches and stuff not to mention your users would be really pissed and they don't like no one likes a badly behaved application the platform itself has significant memory and processor constraints which means that you need to be extremely cautious with how you use something which means you need to be very uh certain that everything that you're doing all that processing that you're doing you really need to do it and that you need to do it at the time that you're doing it and if not it might make some sense to batch it up for doing what happened for it happening later this crashing is something that also happens on mobile devices i have a very interesting story for this one of our recent clients realized that their lower end devices used to crawl on performance especially after about half a day's usage on their application and it took us some amount of debugging to realize that that was happening because they were storing a ton of data in their shared preferences everyone familiar with shared preferences here if not shared preferences is essentially a way to store key value pairs on android just small yes no flags strings and stuff like that they were constantly writing things to share preferences they i think we measured their shared reference files in total to be about 10 megabytes which is a lot these are key value pairs in xml you can imagine they're talking about thousands of key value pairs here and because they would constantly write to shared references and because shared references are not a database shared references is just a file that is backed by xml which means if you real if you think about it let's say that i have a thousand nine long xml file and i change one thing here in the middle which to me as the developer is just a simple api where i just go and say please change the value of this key to this internally however for android because it's a flat file they have to go and i don't have to go and write the entire file again and that actually led to this particular application constantly writing to disk and that it was so significant happened so many times that every single UI operation that the user was doing it significantly slowed down and this is one of those things where they never would have imagined that just because aggressively storing all the user's preferences and aggressively trying to map user behavior caused a significant performance impact to their platform which brings into my next point which is that because the platforms are so new it's extremely important for us to realize that there's constant learning required it's in fact it's imperative you cannot get by being in the mobile space without actually constantly learning what is it that's coming about that's new in the system is apple giving us a better way to do the same thing can i do the same thing differently or with less permissions or with better privacy implications on a new version of android um in the previous talk someone mentioned that android who actually has significant limits on how for ground services can actually function and that's correct these platforms are constantly evolving and they're constantly adding new things which means that it it's up to us to you know educate ourselves and understand how can i build the same product better i'm going to quote a few examples here play services which used to be a huge binary was split up and split up into various different chunks i think there are now 18 different chunks of play services from odds to maps to games to things like that google blasts and stuff like that but before that every application that was even if you're using just maps you had to actually use all of play services but if you were careful and if you read the news followed your developer updates you'd know this recycler view prefetch there's something that android automatically added to a update to app combat i think this is 25.1 where the recycler do especially when you're flinging or when you're scrolling through a long list of items if you update your app compared libraries to something higher than 25.1 you automatically get prefetch on devices that have a render thread so that's a lollipop and above and this happens completely automatically all you need to know is to know that what is actually happening you need to actually just understand android o is coming about with a read sms api which is i think it's another it's a great idea in fact because at this point i think no application requests the read sms permission unless they want to only read it that's pretty much what all applications do they read some sort of sms otp and android o is actually coming out with a way to do this without actually getting access to the user's full sms database which means i as a user don't have to worry about what you're going to do with my sms and you as a user you as a developer don't need to worry about what the user will think when you're accessing all this data now because these platforms are new and because things are so you know constantly in flux sensing these are all that's happening and because performance gets impacted with small small things right like below 20% most most mobile devices both android and ios at below 20% battery will start to significantly throttle the socs which means that they will try to they'll try to optimize uh which means that you will try to have to optimize your application to work with this one of the ways people do this is splash screen delays which is not really optimization it's fake optimization please stop doing that please don't add a two second delay to your splash screen because you know that you are starting this huge library on the main thread and you have you don't want to spend the effort of doing that protocol buffers and json one of those things that i've heard enough number of times where people say that oh we have a lot of data running through our network let's just move all of our json to protocol buffers and everything's fine it's not in fact uh protocol buffers and json data is comparable in size there is no reduction in size like minuscule reduction in size and comes to moving from gzip json to protocol buffer what is good about protocol buffers is different things like for example versioning uh built into the spec itself and uh i think more data types that's something that's a more advantage but don't please stop doing optimizations on your applications by following sort of popular legends work and without actually verifying if you need this or not security theater is an actual concern uh again blindly following the hurt sort of a thing that happens especially on mobile devices people assume that if you pin an ssl certificate nobody will be able to steal your sdpi and that's that which is absolutely false certificate pinning is not a solution to protect your sdpi certificate pinning is to ensure that no one else is snooping between me the user and user backend i don't want someone else to be snooping between you know my user and my backend and stealing trying to steal my user's data which brings to my second point which is you should not do client side encryption again many people many agencies many organizations and apps i know that do this one of the other large-scale organizations that we work with that you know of do this really cool thing where they have to send the user's im here to the server so instead they have 120 line long last file which uses a s encryption to encrypt the im here on the device before sending it over a completely secure ssl connection and uh that's obviously useless because the connection is already secured and i actually had to ask the security name as to why they were doing it and their answer to that was it's more secure and you know that that one there is no debate happening because they don't understand security which brings it to my last section which is culture this slide is my favorite slide in the entire presentation and a very smart person said this that you cannot fix with technology what is broken by culture that's what's happening me and i said this repeatedly to people and i'm very proud of having come up with it all by myself and it's i realized the solution to most problems that people come to us with which is that oh we have a problem with this i said oh no the problem that you have is not with technology the problem with you have is with culture is the fact that you don't have an engineering culture you're not encouraging an engineering culture you're not actually helping your developers be better we have a problem because our release cycles are all stretch times go oh no no that's because you're not realizing that your team is burning out because you're making them work Saturdays and Sundays over the start of that that doesn't help at all you cannot you cannot ensure that you do great engineering by destroying your people your you know your employees or your folks lives quickly go through this unfortunately i have a little time it is not dropbox i think i wish i did not have to put this slide here because we've been i've been using it for about a decade now but there are three things that people still i realize largely don't use with yet one rollbacks sad but the number of people and number of organizations and teams very efficient teams otherwise when they had to rollback a feature they just go and ask a developer that hey after lunch can you spend half an hour removing this code and committing it back again it doesn't help anyone get already solved that problem for you you can just you know the fact that the developer might just introduce another issue while doing that change is a secondary problem but get already solved this for you bisecting no one seems to be using this how many of us here have actually used git bisecting i'm glad i'm very happy rest of you please go back and look at bisect it has a great way to figure out what part of the what offending comment actually introduced a bug it doesn't always help to fix a bug it helps to also know why the bug came out in the first place books git ties in really well with automation and git allows it has a very very nice way of letting you do things when other things are happening in git so i want to check that my developer writes the commit message in a certain way you can add a pre-commit hook add a shell script to check that i want to ensure that before a pull request is received i want to run my test heat belola there's another hook for that go ahead look at what is your bus factor how many of us know what bus factor is so bus factor came about i think it came about from due to the linux community from the kernel community where essentially what bus actor means is that how many people in your team need to get hit by a bus before your project derails and which means that your bus actor must be really high which means that it one person should you should not have like in a team of 13 people there should not be one person who is largely the only person who knows what's actually happening and the rest well sort of just run around this one person and try to figure out i'm not really sure oh you know what you have to do this oh i'm trying to do this oh no no you have to actually do that you don't want that situation where that one person is there and there are three ways you solve this first is documentation which is that you document your system and you document your processes the second is documentation which is that should ensure that you know these things are written down the third is documentation which is that your developers your product team your designers your if your organization has a certain process which i'm hoping it does this should be documented somewhere if i'm joining your team tomorrow it should be very obvious to me what is it that i need to do to get started here's your laptop here is your access card everything else is listed here this is how you connect to the git repository this is how you check out the code this is the initial this is the sort of low level bugs that you can automatically attack this is where as print planning happens all of this should be documented this should be present somewhere in a document it shouldn't be a person's responsibility it's really hard finding great people to work with i'm sorry everyone will agree with that and if you're going to take that one person's job for two days away and teach this new person that you know here tell this person how what it takes to be part of our company that's already a problem are you measuring the metrics data driven design is extremely popular these days data driven development is very popular these days interesting story again large corporate that we are very familiar with likes to really really catch all sorts of data that their users are producing generating and at the last time when you're working with them they had six different data collecting libraries in their application which caused a huge performance impact obviously if you're going to throw in new relic and local ethics and mix panel and crash litics and everything else bugs like this and that if you're actually going to throw in all those things apart from the fact that you should be really really certain that you're actually using those libraries you're also significantly impacting performance and that's actually a problem and it's exactly what we saw there we shaved off two and a half seconds from their startup to final whatever thing that they were doing time by two and a half seconds by just removing and consolidating their analytics libraries that was it that's all we did they were really happy that we did that but it did not take a lot it doesn't take a lot of effort to sort of realize that if you're going to throw in all of these things it doesn't automatically work new relic doesn't automatically tell you why your activities go it has to monitor those things everything it's monitoring it will have to somewhere it's going to have an impact effort does not mean progress this might again kind of obvious but the number of folks that we've worked with who when teams we work with who will tell us and say oh no we actually need 50 developers we need 50 people because they have a lot of work and they're all busy always see like you can see it cubicles full of 50 people working on the same android application that doesn't mean anything that just means they're putting in effort I could ask all of us right now to go and push that wall and we're already doing a lot of work and we all sweat but walls not going to come down hopefully it's not going to come down you can't just and keep doing effort without actually measuring that are you actually moving forward one of the ways that we do this is for a team that we work with go and see what your bug fix to feature ratios that in a sprint cycle whether it's to a week or two weeks or whatever is that is are you actually is your team actually working on 50 bug fixes and these sort of features is it like how you know 20% bug fixes 80% new things so a good ratio but if you just measure this if you look at the effort that your team is putting and you realize that you know this is something that's not good you can actually work towards fixing it and two very important books were written very very long ago before I was born which I will highly recommend the first one being the mythical man one by Brad Brooks kind of a controversial book because it's kind of sexist but please read it the second being people where which talks about productive teams and how literally just what I said which is that you cannot really solve things by engineering what is broken by culture that's the end of this slide questions I don't think we have time we have two minutes for questions okay two minutes questions if you think of some questions later we'll be back on stage at two o'clock as part of our off the record session on scaling challenges slightly different topics but I'm sure he's still interested thanks thanks everyone thank you very much