🚀 Lean Code (Kevlin Henney)

[Music] good morning good to be back what happened to the snow last time I was here there was snow what did you do with it okay so what we're going to talk about this morning is the Alps no lien coat the only realest Li the only reason that there's I've got a picture of the Alps Terrace it's the only photograph I had that had something that leaned so sorry terrible joke so I want to talk about this from the point of view of the developer and we've got an idea of lean lean has been kicking around as a term in software for nearly 20 years and it dates back to very much this book that Mary and Tom poppendieck published in 2003 but this was based on a previous paper published in 2001 extended work that Mary in particular had done from about the late 90s onwards and what is interesting here is you can notice there's a change of terminology lean programming this is around the time of the agile manifesto just around that year and it's also the time before everybody got I was gonna say excited about scrum but I think probably bored is the right term most people hadn't heard of scrum at that point the big buzz the big disrupter was extreme programming okay the original XP okay and so therefore putting the word programming on something was kind of cool so it started off as lean programming rather lean software development a Mary said recent work in agile methodologies adaptive software development extreme programming habit effect applied simple rules of lean manufacturing to software development we need to be always very cautious when we borrow metaphors from other disciplines software development is not really a manufacturing discipline or rather yes it is that's what the build process is for the bit that people do that's not manufacturing okay we don't carefully handcraft the bits when people talk about software craft that's not where they're doing like here your personalized bits made in Latvia the finest ones and zeros in all of Europe that's not a software craft that's not what people are talking about the results which we call lean programming are as dramatic as the improvements in manufacturing brought on by just in time and total quality management movements in the 1980s so this is kind of where it started what mary was doing was looking and saying what are these ideas from this domain that I am familiar with brought back to software and interestingly there's this whole agile space going on and she articulated seven what she referred to as principles eliminate waste build quality in create knowledge defer commitment deliver fast respect people optimize the whole now these are described as principles but actually if you I don't think they are principles if you look at the names they are more like directives they are telling you what to do and so I want to revisit these but I want to revisit them actually with the programmer perspective I want to revisit them and what it means from the code to the developer then to the bigger picture because often lean is envisioned from the bigger picture in words but somewhere we stop the message and I'm going to reframe this as a series of goals simple one-word goals so I'm gonna start with value I'm going to start with value partly because it's the most overused word that I find these days the problem with the word value is you have to quantify what you mean by it you have to qualify what you mean by it when people say you should be working on something that has value that has no meaning I mean it sounds good it's great and when people say we're going to prioritize by value we're going to prioritize our requirements by value that's an entirely content-free statement it has no meaning it sounds great it makes you feel good but you need to figure out what does it actually mean so the first question you always have to ask is value for whom who is it a value to is it a value to the developer is it a value to the team is it a value to the organization is it a value to the manager of the team but to nobody else that one happens is it a value to the user we really don't ask that often enough is it a value to society okay and when we say is it of value I mean what are the things that you value normally when you ask people name me the things that you value money is not one of them they normally talk about their family and things like that so you see this word has huge variants huge range and then when we talk about value we need to think about something else over what period okay over what period is something valuable is it a short-term gain or is it a long-term gain you see the word value is far more complex than it suggests otherwise you end up with really very shallow most people end up with this kind of interpretation yes the planet got destroyed but for a beautiful moment in time we created a lot of value for shareholders the point there is that value is that the value that you're pursuing I have no idea so when somebody says value you really need to push hard to understand what you mean so in this sense value is not simply a goal it is also a question and that's why I start with it you need to figure out what you mean the value for you the value for your team the value for the customer what period of value are you looking at short termism or long term ism this also gets us to question as developers many of the frameworks that we work within and what I mean by frameworks I'm not talking about you know honestly since the time I started talking somebody's probably released a new JavaScript framework you know that's not the kind of framework I'm talking about I'm talking about business framework there is this idea of what is the concept that you are working with what do you value as an organization all of these questions so you need to ask that question and when you start talking about things there's another thing you've got to deal with the code and it turns out that many organizations seem to believe that they are being paid for the line of code at least that's the only way I can explain how there's so much code that does so little ok the amount of value per line of code decreases hugely as a system gets old as a system has work done to it unless somebody puts particular effort they will end up diluting the value of the code so directly from the developer point of view what is the value of this line of code put simply I'm going to travel back in time a couple of thousand years this is not the only Latin in this talk okay these are three qualities of a building that Vitruvius Roman architect described in his volumes de architectura on architecture fermitas who Tillet ass venustas firm it s firmness strength robustness utility s utility usefulness value Venice das Venus the goddess of beauty is it beautiful that's kind of an interesting question to ask about code I'm not going to answer that today but we'll get close so I just want to concentrate on your tinnitus the very minimum that we should be expecting when we are looking at our code is that it has utility it is useful it solves a problem code is there because somebody needs something from it and that somebody could be another piece of code another piece of code or an end user in other words this has a job to do it is useful that's a very hard thing to do we have a real problem with most systems it's not just verbose code it's not just code that is very long-winded because sometimes what happens is people I don't think people necessarily sit down and say you know what I'm gonna write some really long-winded code today I'm just gonna I could take one line but I'm gonna write 20 I'm gonna take the simple idea and turn it into something complex I don't think people sit down with that objective but what happens is that we are often caught in a trap where our first idea when you're playing around with ideas you don't yet know what that idea looks like and we are not very good at that question of coming back to the thing we write the first thing it seems to work and then we check it in and when we say it works what do we actually mean when you run it it doesn't do something unexpected that's a very shallow definition of it works does it work for the business does it work for future developers oh no this is really bad it's like the first thing I thought of maybe I should do something with it we need to be of the idea that our code is not permanent that we are able to update as our knowledge updates I'm going to come back to knowledge the other thing is you know what you got to get rid of dead code I gave a talk here two years ago the error of our ways I had a whole section devoted to how much money has been lost through dead code that I know of Oh billions pick a currency doesn't matter billions simply because of dead code so when somebody says all that dead code it doesn't matter it'll never get executed if it doesn't get executed what's it doing there it has no value but there's always this thing there's a kind of a developer arrogance we don't need to worry about that I know it will never get executed do you know it or do you just believe it what happens if it's not actually well dead what happens if you end up with the zombie apocalypse and it comes back to life that's where rockets explode where companies go out of business because they trade in the wrong way against the wrong model of the market there are so many stories about this dead code has a value and the value is negative yeah it's not a hard thing to do you don't even need strong refactoring tools what you tend to find is culture and mindset because oh we're we can't delete it because we don't know of anybody uses it now you've just told me something about how much you know about your code you're you're basically saying we have no idea what's happening with our code our code is insecure because we don't know what it does our code is unsafe because we don't know what it does that is very telling that's where we need to focus so therefore we don't need to just think about adding code I find very few very few books or very few blogs and very few discussions people ever talk about how they retire the code they spend a lot of time talking about oh we generates this or we do this and we add this and when you want to add this and when you want to refactor this to add this there's lots of addition but life is made up of two ends what is the natural life cycle of your code under what circumstances do you remove it now this is not a new idea we actually have it you can see it in networking software you can see in network protocols they have a time to live TTL so that dead packets don't dominate your network we have this in things that we build this is not simply a consequence of life credit cards have expiry dates sometimes it is a matter of life yogurt has an expiry date you know unless you want to create new life I suggest you respect it but that's the point we have this idea that everything has a life cycle except dude we're really bad at this and we kind of slowly but surely started acknowledging that this may be a thing but that's just a little tag that's not a philosophy that's not a we as a team have a process and a philosophy for how we retire code and how we retire features yeah death is a part of life death is a part of product development projects don't worry about death products have to that's a really important part okay in other words if you have an entity it stays alive because the things that it is made of have a natural life cycle that is shorter I am not the same person that I was when I was born okay I might share a few molecules but mostly is new disappointing so we keep talking about incremental development we need to talk a little more about decremental development but there's a lot of things here that overlap in another area that push us into another thing quality finally this was one of with this is a word that when I got into software development people use the word quality a lot more not because they had it but mostly because they didn't have it I'm not saying that the stuff we do now is necessarily better or worse but the conversations specifically using that word as opposed to anything else we're much stronger and so quality covers many things I'm going to focus initially on the idea of simply robustness it works it doesn't fall over that's a kind of basic requirement it works as expected not only does it work as expected but we it doesn't have nasty side effects when we do things that are stupid because guess what we are human well I am pretty sure most of you are but here's an interesting thing when we talk about robustness I want to about the quality of the code itself as an entity and this is an interesting one because this takes us into the territory of things like technical debt and what I found recently was an interesting way of looking at it because sometimes the technical debt is probably one of the most accessible metaphors that we have for trying to reason about code and the problems we might have within it now when Ward Cunningham introduced the term technical debt in 1992 he did not imagine that people would run up huge amounts of it intentionally the problem is it turns out people have very different relationships with debt for some people for example credit card debt for some people they pay back their credit cards every month I think Ward is one of those people for some people a credit card is magic money with a bit of inconvenience attached and so therefore running up a debt is not a bad thing I remember discussing with you know over here well discussing it with a group of people who are from startups a number of years ago there were two people who were talking about their burn rate and this is financial debt not technical debt and it was kind of like a pissing contest who is burning up the most investor money who is creating the bigger debt financially that was a mark of achievement the problem is that some people regard that regard technical debt as a mark of achievement no that's not why Ward originally introduced it he introduced it for a very different reason it's the idea that you are able to temporarily get an advantage as long as you pay something back and it's the paying back remember I said the thing about death there's two events there's creation and then there's destruction or removal addition removal we make the debt we pay the debt we seem to be really good at this site this side not so much but sometimes people say always just a technical debt problem or we've got technical debt let's go back to worrying about what the customer wants I want you to go to the customer and say you have never seen the codebase like ass do you you know let me tell you all the problems with it anyway what did you want again your features are they really important do you want us to deliver features next year as well or the year after whenever people tell me oh the customer never wants us to pay back technical debt I think that's a little bit dishonest very few people have ever gone to a customer and said this is what this is going to cost this is what this is going to mean in six months twelve months two years three years that's what it's going to me when you tell people this is their repayment sense if when you tell people you know that loan you took out we're going to send people round with baseball bats to recover it and that is your cost that's the issue technical debt is also not just that issue it has other consequences technical debt is something that will lead to staff problems why do people want to work in that if they have a choice if people don't have a choice they don't have a choice but if they feel they have a choice to move elsewhere they will it also has some really interesting implications for security because what you're saying when you say technical debt you're basically saying we have no idea what I code does or there are bits of our code that we don't properly understand there are bits of our code base that we do not properly control anyway by the way our system is very secure those two statements do not live in the same sentence okay security part of it is knowledge compliance defects all of these things are related to this so there's a deeper case here one of the oldest pieces of advice that still survives from tangents guide to designing programs is this remember there is no code faster the net than no code it is one of the simplest things to optimize sometimes removing something is the thing that gives you the performance now I've worked with worked with a number of teams over the years and sometimes performance improvements are let's add complexity let's handle special cases sometimes it's let's get rid of special cases it's not always an addition sometimes it's actually removal sometimes it is actually asking the hard question it's saying do we actually need this and when you get rid of it suddenly everything goes faster with one team that was a simple question of network-based and disk-based I oh it turns out there was a whole load of Io they didn't need to do and when they got rid of that it was it was like they'd taken the brakes off when they were driving it's like they've been their code had been driving around with one foot on the accelerator one foot on the brake but suddenly they got like 200% speed-up so then we can generalize this there is no code cheaper to maintain than no code there's no code more secure than no code so this is not unique to software we see it in other disciplines I love the these Miles Davis perspective I mean honestly I always thought the trumpet was one of the least sexy instruments you could ever have I mean trumpets do not scream rock and roll at you but Miles Davis managed it I always listen to what I can leave out this is a fundamental aspect and there's an idea here paying attention to what's going on sometimes we're in a hurry we're all about the speed I think we need to slow down I'll get to that one now there's this interesting thing called knowledge what we do encode is knowledge work what you are doing is codifying quite literally codifying knowledge you are codifying an understanding of this is the world of the problem and this is the technical world and this is how we as a team potentially believe you can bring these two together using the technologies that we have against the context that we are aware of and you're going to organize your knowledge when you separate things out according to whatever paradigm you're using the paradigm gives you a model of organizing your knowledge it's appropriate we're in a library there is a whole idea of how do you structure knowledge there's more than one way to do it and you may have a particular philosophy you may go this is a data flow based organization of knowledge or this is a classic applicative functional model or this is a reactive model or this is a classic object-oriented model this is an enterprise object-oriented model I'm going to distinguish those two enterprise object orientation is generally 10 times bigger than classic object orientation and it will involve ten times more people now funny I'm mentioning ten because there is another aspect we have this myth about the 10x developer and there's lots of things been written forward against it but my favorite quote on this is actually from Brandon Schwartz I love this whole idea to be a 10x developer you need to be a good developer who helps 10 other people get better at what they do that's a lovely way of putting it it is the idea of quite simply you're going to communicate knowledge you can localize knowledge you can keep knowledge in one place but it turns out that's not a lot of use if you put a lot of effort into figuring out what that one variable called I does your initial instinct was it's an index because it's I and then you discovered it wasn't and you discovered later that it was an altitude or maybe later that it was an upper limit or made who knows and you make a note to yourself and you go I know what this is you have just rediscovered something that somebody else did but you've not yet created knowledge because it's yours the next person along probably you actually will have forgotten that okay that knowledge has a half-life in about two weeks time it will be gone you'll come back and go I oh that's an index and you'll go through the high you'll have this kind of haunting sense of deja vu and maybe that will speed you up but that thing you could have done you could have just renamed it and that would have been a communication but there's something more to communication than this and it's an interesting thing the word communicate comes from the Latin community RA I said there'd be more Latin community RA I also like the fact that in English the default reading of this is communique this is the origin of the word community it is the origin of the word common what this means in Latin is that to share among many that is what the word communicate has as its original meaning to share among many that's a great meaning and sometimes that is the knowledge you have about your tools sometimes that is the knowledge you have about the architecture sometimes it is simply the stuff you put in the code so a book I published 10 years ago and currently with Trisha geom we're editing 97 things every Java programmer should know so watch out for that a New Year Dan North had this lovely piece code in the language of the domain there is a reason that we care about this but when we talk about coding in the language of the domain that is not simply about the names sometimes people misunderstand they think that coding in the language domain just means using good names no it's that's the starting point but a good name is more than a label if you look at this piece of code you will see that all the names that belong to the user has opposed to the ones that are in there the Java collections are clear they are good there's nothing I could do to improve them portfolio IDs by trader ok trader portfolio these are great the only abbreviation in there is not a programmer abbreviation it's a real-world abbreviation ID that's a real-world abbreviation the this looks really like we're using the language of the domain but that's not what it means language also involves other structures this is what this means and this is the interesting idea that the language will shape your thoughts you're not simply moving collections around there is a purpose what we're doing here is preventing insider dealing traders cannot look at everything there are certain portfolios that they cannot look at and should not look at by law by governance so therefore this is the piece of code that does that this does exactly what this does it's a very simple piece of encapsulation but that's what encapsulation is about encapsulation is not about making data people often misunderstand that although I wish they at least understood that it's not about making data private making data private is a consequence of encapsulation it's Michael feathers notes encapsulation is important but the reason why it is important is more important yeah just digest that slowly encapsulation helps us reason about our code it allows us to reason it allows us to think it allows us to create knowledge to have knowledge to pass on knowledge that's what it's about quite literally we're talking about reasonable code the word reasonable in English has two meanings the most common one that people know of is that's okay you will hear British people in particular saying that's reasonable that's what we say to everything the world is going to hell yeah that's reasonable oh that is the best thing I've ever seen that's reasonable yeah we've got a kind of flat response but the idea of reason is generally positive but its original meaning is you can reason about this is my code reasonable is it okay but also can I think about it in well encapsulated code there are fewer paths to follow as you try to understand it understanding and knowledge are intimately related encapsulation isn't an end in itself it is a tool for understanding that is what we want our knowledge is there so that we can create and respond to it and response also involves handling change change we are terrible at this so this is this is I think the government the British government have been having a few problems in recent years you may have noticed Britain is running a rather large social experiment I'd say it's not going well don't do this at home and this is the this is the kind of the next generation computer that will be coming out of Britain because apparently we're gonna make everything ourselves now it's silicon based and twice a year it gives the right answer we're not sure why or how but it does what we have here is yeah we've moved from Latin to Greek monolith us monoliths one stone one heavy stone a stone stones that are so hard to move that it takes teams of people and we look back in time we look at this and we go how did they build it and we go in to work on Monday and we look at it and we go how did they build it why did they build it how does it work and you know what we originally envisioned when the system was young this is what we had in mind beautiful small stones elegance with the kind of like sort of nice Japanese seaweed aesthetic going on this is my youngest son when he was five it's just that he arranged this is just that and this is what you hear when bubu Sal yeah yeah we're talking about micro-services yeah you know what happens to micro service architectures if you don't really know how to do the architecture thing and you don't really respect the code and you don't slow down to ask the questions and say how are we organizing the knowledge are we making this valuable for the people who work in it and valuable in the long term not just a short term for the people who use it if you just go at it thinking microservices is the answer this is what you get the observation was made in the early 1980s by Alan Perlis the first winner of the cheering award in the long run every program becomes Rococo and then ruble this is the fate of everything if we do not pay attention to it that is what we're trying to do this is how we organize our knowledge but it is also the fact that not Changez now this is something we are very poor at doing we have an assumption that everything we know is fixed even though that is contradicted regularly our understanding of a system is going to be different even if even if requirements never changed so I'm going to run a simple thought experiment here the great thing about thought experiments is that you can defy the laws of physics imagine that you had the perfect specification that contained every piece of information you ever needed and it was all given to you upfront and not only did it contain every piece of knowledge you ever needed it was also comprehensible and it was never going to change and because I'm feeling generous because it's Friday we're not we're going to allow we're gonna basically prevent change to everything else except time oh no no there's going to be no team change no technology change there's going to be no market change everything has been frozen in place and yet there is still change you your knowledge as time progresses as you build a thing you learn how to build it you learn what it is that you're building the those brilliant ideas you had six months ago don't even seem so brilliant now because you're they are more you have better ideas you truly understand how to build something what we've just done there is completely artificial but what we did do was eliminate requirements change it turns out that even when you eliminate all sources of change there is still change that is your knowledge of course there are two exceptions one is you already know everything I have met people who have that belief that that is a problem or you're not very good at learning in other words you will never learn anything I've also met those people they've been in the industry decades and yet they seem to have acquired nothing and knowledge is flatlined but that's the point change is intrinsic to what we do because it is knowledge work you are always operating with incomplete knowledge so even if the customer never wanted to change anything even if the technology never changed would still be changed it is normal and how do we account for it well lovely observation so Haggard Hawks is a Twitter feed and actually Instagram feed that I follow presents unusual words and I missed this one until Michael retweeted this with the observation a word for the software architecture lexicon trauma tropism the regrowth of a plant or tree often in a bizarre shape or direction as a result of earlier damage or trauma like a lightning strike or a company merger or a technology migration or you name it but that's great because this is now you can go into meetings and you've got a richer vocabulary for describing you can say oh yeah that class yeah we've got some real trauma tropism in this yeah or we are experiencing trauma tropic technical debt oh that's good that is good trauma tropic technical debt TTD okay you heard it here first okay so the point here is that this is what natural systems do and this is fine except that I don't have to make we're not trying to build a company around that tree we're not trying to build a team around that tree we do have some control code is ours we don't get to control nature every time we try and nature tends to fight back the problem is when we tell people things might change they generally set hole I see what you mean we need to generalize we need to make everything configurable yeah that doesn't generally work out that brings with it complexity it brings with it masses of guesswork because what you're doing is you're working without knowledge you're saying this might change and if it might change it might change in this way there's a lot of mites and maybes in this it's a game of probabilities you will probably lose and you're going to end up adding a lot of complexity it turns out the easiest way to future-proof your code is to get rid of all this stuff to go into the future streamlined kind of ready for ready for anything the coat as lean as possible just get rid of the stuff it doesn't need make it focused this is what we're doing okay and this is easy too well easy to evolve we need a philosophy of how we've evolved this is something that platforms have struggled with Java has started dealing with it I've noticed C++ has started dealing with it different languages and platforms often have this blind view of the future is just addition the future does not involve experimentation the future does involve experimentation because the future branches we don't know which path we're going to take and so this is the idea of how do you deal with this uncertainty and there are lots of different approaches but you have to acknowledge here the other one is this other idea right code that is easy to delete not easy to extend we've got caught in a trap thinking that everything must be extensible okay the idea must be able to add and plug in and do there sometimes that is exactly what you need a lot of the time it is not there is this idea of find out which path you're on and sometimes if you're unreal n travel light okay the lean approach the more streamlined approach is what you need the plug-in architecture that you think you need will become apparent over time if you're not sure of it if you already have experience of what it should look like well done you've got knowledge but if you don't you're better off taking a streamlined view and this is old knowledge if you're not sure of something if you have a lack of knowledge then how do you organize it well it capsulated it turns out that this is a structuring technique this is 1972 we proposed one begins with a list of difficult design decisions or design decisions which are likely to change each module is then designed to hide such a decision from the others this advice is not new what is interesting is that sometimes when I quote this people say yeah but how do you know that their design decision is difficult sometimes you already know because just sitting there go like I've been wrestling with this problem but I'm gonna I'm gonna throw out something here that's really quite an interesting one maybe you are not the best person to determine this maybe the fact that you can't agree with your colleague is the most interesting piece of information that you have and you're not looking at that you might dis you might regard it as a difference of opinion of the tech the technology or the coding style that should be used but actually what that is telling you is the fact that the two of you or the three of you or more have a difference of opinion and I'm going to guess because you're developers you're probably not too stupid you're probably reasonably well-informed it turns out that that's the world or the universe telling you this might be difficult this might change so you have to kind of listen around the fact that somebody thinks differently actually is an indicator we probably don't want to have everybody depend on this assumption I wonder if I need to add an isolation layer a private key word or whatever it is at whatever scale it's quite an important yet really simple idea it doesn't involve normally a lot of code it just involves adding a little bit of distance and this is an interesting observation because it also teaches us why it is that one of the reasons that we care about loose coupling to reduce dependencies in a system the idea is to allow you to change your mind yeah your knowledge is not perfect and if I tightly couple to one assumption of knowledge and it changes then I'm gonna have to do more work than ever kept it a little bit further away okay and we see lots of examples if it's a standard example that I tend to use I get people to talk about how would you represent a date the reason I pick on dates is because apparently it's a really easy problem that everybody gets wrong yes Oracle some IBM Microsoft I'm looking at you the list goes on yeah there is there's kind of a there's kind of a very simple rule anybody who thinks they understand date/time handling really well doesn't anybody who thinks they do not understand date/time hand really well is probably right okay it's really simple but I pick on that as an interesting domain because how would you represent a day I could represent a year month and day I could also represent as a number of days since an epoch date both of these are valid which one's the best the word the best best is an interesting word you know what I can do I can implement both of those that's fine tell you what why don't we not depend on that why don't we not depend on the fact that it's one integer or three integers why don't we capture a concept called date and make the concept stable and we separate that out this is old-school classic encapsulation but it's not just at the the little stuff it turns out that that's quite big you if you've ever seen a large code base where you've had a representation assumption that's gone all the way through and you've decided to change it you will have realized that lots of little things repeated become a big thing it turns out it becomes architectural but we see this all the time one of the classic examples that you see is in web browsers or in web apps look at the look at the actual address on a lot of pages and you will still see in the URL dot PHP dot ASP I look to one of those just last week and it's a case of all hang on why are you publishing your implementation technology as part of the address you don't have to do that you know that's that's kind of a little bit strange why are you losing the encapsulation of your system your system from the users point of view should just be a system that does whatever it is allows you to get tickets for dev turna t except that it's sold out you can't do that anymore allows you to buy books yeah that's what you want but we publish the underlying technology which leads to some really strange consequences I spoke to a Ruby on Rails developer who had just redeveloped a side that was originally written in PHP and said yep we had to preserve all the PHP URLs as well so now you have something that has got this legacy naming it turns out it's very easy to inject so this is this idea this thing this idea is deep it's all the way through your architecture at every single level it's a simple idea it's not hard I'm not saying it's not hard so you should you know why aren't you doing it I'm saying it doesn't involve a lot of extra effort it just involves slowing down now that's kind of an interesting one because slowing down is - is relates to how we do things in time and there is if you like old school lean was very much more focused on this idea of eliminating waste and that's part of the story but these days pen to pen to emphasize the idea of flow a lot more things are in flow that they don't stop stop stop start and stop forever you know that the things are not blocked there's a very different way of looking at it and kind of what we're looking at so picking up on a remark that I threw out earlier the difference between project versus product if in software development we have often we often work in the project mindset we often work with deadlines and we know the consequences of those deadlines as you work towards a deadline what happens is that perhaps you achieve what you set out to do you've now got something that works or kind of works but you're exhausted it was hard to get there and now you need to do it again well that's not very clever but also what are you going to do about all the shortcuts all the technical debt this was Ward Ward's model the whole point about a technical debt model is you are able to run up a slight debt to achieve a short-term objective and then you repay this is the whole point of life cycles and code philosophies that allow you to say and now we pay back for the next thing I find a lot of people say well they again going back to this idea customers don't want to pay for this never assume what the customer wants unless they told you directly very few people ever asked the customer hey do you want us to really hit this deadline hard so that it messes up the next delivery I think they probably say no why were you planning to do that that sounds like a terrible idea if we regard software development as a game an idea I first came across through hours to Coburn the idea of software development is a cooperative game there is a very interesting thing about the nature of games there are lots of different kinds of games there's cooperative games competitive games there are games that are bounded and there are games that are unbounded okay so standard standard football match is structured as two halves to 45 minutes each way with a little bit of extra time on each half for injury and the possibility in a tournament of having extra time and maybe a golden goal or a penalty shootout at the end in other words there's a clear structuring but it has an end it has a number of criteria for defining an end it is about the end that is how projects are structured but that is entirely the wrong philosophy code that is written in that style is not written with this approach in mind the idea of sustainable development is simply you need to meet the Pope needs of the present don't put off stuff for the perfect architecture that will come they'll always be six months in the future what are you going to deliver this system Oh in six months you said that six months ago yep my answer is consistent yeah I've visited a company that had exactly this they've been working on the framework and I think the framework was spelt in caps and in bold and it was a few years late but the problem is we don't a sacrifice the future in order to meet the present it's a balancing act that's why it's hard if it were easy we'd all be doing it this is sustainability it's this balancing act but that's the point product development and therefore I would say most code falls into this not all code sometime code does have a very short lifetime we know we know certain things have a short lifetime things that are truly prototypes not prototypes that go into production things that are truly prototypes things that are written in competitions competition code has a very bounded lifetime there are a number of cases where we can say the lifetime of this code is fixed or is short and we know it's end sometimes there is a feature that we know is going to disappear because of a change you're saying government regulations that that's going to change in six months time and we will never need that piece of code again so we shouldn't put all our refactoring effort on it it works well enough sure it's not great but in six months time because the law is changing that code is no longer applicable sometimes code does have this property but most of the time when we're dealing with product development the goal of the game is to keep playing the game that's very different to the goal of football we also have a number of really bad sayings that have made their way into software you can guess which company popularized this just from my use of the font but this is not unique to Facebook this is actually an old engineering saying dates back to the 1950s as best as I can get it could be wrong could go back further move fast and break things like democracy and stuff like that that's not what we want at all I don't think it is I don't think that's the right philosophy I think we actually need to do exactly the opposite move slow I think people are obsessed with speed I I don't I've never seen anybody developed something fast that's come out well and we want to have some kind of sense of progress but we're trying to play the game to keep on playing the game it turns out that the obsession with speed when people talk about deliver fast in fact that was one of the original principles of lean development and I still see it now in fact I did a keynote at a company event where they sort of said I think was the tagline it was faster better etc some tagline like that first thing I did was get up on stage and say you don't want to do things faster there's a subtle difference you want to do things sooner not faster sooner now let me clarify the difference because this is a linguistic difference but it has huge huge consequence so when my kids were younger my wife and I used to have two axes act as a taxi service my older son has just passed his driving test so he is now the taxi service so you see this is what life cycles are all about so we used to have to taxi them around and sometimes at the weekend we'd end up you know oh this child has to go to this party and then we're gonna we I've got to do this I'll take the other child and then we'll meet up somewhere and maybe it'll be a cinema or maybe it'll be somewhere for sort of some fast food but whatever happened we'd end up with two cars and so then we'd say okay let's go home and a child would choose a parent you know one show up here who's gonna get home first ah I would always drive faster but my wife would always arrive sooner I have I have the speeding tickets to prove it okay but I also have a relatively poor sense of direction I don't have good knowledge of routes this relates to knowledge your goal here is to accumulate the knowledge that allows you to do things sooner it may be faster an execution from the outside it looks faster but there is a subtle difference my wife had far better route knowledge she would travel a shorter distance more effectively with less fuel and less time that's what you're trying to aim for simply looking busy is not is not really the goal of software development so the point here is you want to focus on velocity not speed now I know there are a lot of teams who say yes we're focused on velocity no you're not you're focused on speed there is a subtle difference and this is where you know somewhere in my past I have a degree in physics this is where my by kind of like care about words comes out again because speed is a magnitude velocity includes Direction most teams that say they're focusing on velocity have no idea what their velocity is it's kind of like saying yes I'm heading at 150 kilometers per hour are you heading in the right direction I have no idea but I'm going really fast you're going north $150 per hour yes you do know you should be going south it turns out that walking would have been faster so there is this idea that teams are obsessed with this one-dimensional view of how to measure themselves it's not their fault but it was like we have an echo chamber culture where we've reinforced this message progress is not simple and linear what you need to do is are we moving in the right direction in the right way is it fuel-efficient it's the simple way of putting it how much effort are we putting into our coat how you know is the code responding well every time we need to do changes is that the hardest thing in the universe or actually is it okay and is it well actually what the customer needs this kind of thing this is a this is a this is a more subtle process and we understand that such processes are cyclic and there's a classic way of looking at this plan do study act the PDSA cycle Deming shuart cycle I first encountered this in the 1990s I think probably under the TQM thing total quality management thing and I didn't pay it pay much attention to it and it was only when I started reading more deeply in the 2000s on development process I suddenly realized this is really simple this is the only development process you kind of ever need to start from because it has everything that you need you can make it more sophisticated you can make it simpler here's what we're going to do let's try doing it let's slow down this is by the way you may have heard a variant of this plan do check act PDCA I prefer study the original formulation for a very simple reason study sounds slower okay my my old boy is about to take exams next year to go to university my wife and I are not simply encouraging him to check his work have you checked your what yep done checking is really quick study sounds slow and so it should it takes time it takes you have to make a deliberate effort to do it how are we doing is that was that the right thing did we do that well can we've done it better you know what questions has that raised that's the other important one we don't stop to ask questions about what we're doing should we ask the client this maybe that's a good idea should I ask the architect this should we ask each other this is there a tool that would make that easier and then whatever you've discussed and decided do something about it make it so repeat we can even see that that is reflected when you talk about test-driven development it's not just a macroscale thing over weeks and months at EDD cycle people often rephrase it in terms of red green refactor which is kind of okay but I've never been found it very compelling when people sort of say the first thing you do is write something that doesn't pass a test well that's not exactly a very check very big challenge right something that doesn't work done come on give me something give you something else no the way you look at it look at these four steps what does success look like that's your plan what is the simplest thing that could possibly work that's your do take a step back what's going on what are the gaps and repetitions inconsistencies or trends I have about the code or the tests or the domain that's your study how would you address them that's your act it turns out these cyclic structures are really simple you don't need to learn lots of different methodologies it turns out once you've got this in your head and you realize it's works at different scales it's very powerful which takes us to this other thing which I've kind of suggested is quite important it turns out that people really are quite important when it comes to software development and there's you know I've just tdd so I'm going to pick on James Groening definition of te D from his book test-driven development for embedded C now I do this for a number of reasons one I like the way that he has described TDD here TDD is fun it's like a game oh it's the game metaphor again where you navigate a maze of technical decisions that lead to highly robust software while avoiding the quagmire of long debug sessions with each test there is a renewed sense of accomplishment that's quite good you know you feel like you're going forward and clear progress toward the goal automated tests record assumptions capture decisions and freeing the mind to focus on the next challenge here he's talking about a lot of things and yet has captured quite well a lot of our motivation for unit tests whether we do them TDD or not or any kind of test but what is interesting here it's not just that it's also the fact that it's for embedded C because sometimes people tell me oh yeah I see that TDD stuff you're talking about well that's all right for c-sharp Java or whatever but we're in a special domain we're special yeah are you special is embedded C that's the thing I think is interesting when people say oh we can't do that because we're special okay here's something is fairly special there's a whole book on it but there's something else here look at that we are a lap we keep focusing on productivity that's another one of those speed words I think that we should probably focus with a little more eye enjoyment it turns out that most problems to do with organizational culture team effectiveness and all the rest of it disappear when people just start enjoying themselves if you're doing things that are pleasurable you know what most of the problems disappear you don't have to do anything you don't need to read a book on a new technique to apply to your team turns out that these have human consequences now I can't give you beauty but I can't give you something that is a similarly aesthetic and patterns of software in the 1990s dick Gabriel talked about a very simple idea habitability is the characteristic of source code that makes a place livable like home when we talk about architecture and software architecture we are normally focused on structure but for some reason for such a long time we have missed the implication of the metaphor building architecture is for people it's not just there to look pretty it's not just there to be what has been turned Magazine architecture you know some buildings look really good in magazines with nice photographs but they don't work quite so well with people in them the purpose of a building is to have people in it what's it like purpose of a software architecture is not simply to be a structure that is rational so to allow people to work within it so we have a kind of a simple observation that it's a place that we live it's how we organize our team's biggest advantage of autonomously working teams is Risk Reduction through group intelligence this goes back to the knowledge idea as a team you're not simply a bunch of people who are good or hope to be good what you're trying to do is think better think more broadly and this is one of those simple observations you can't just add a bunch of people together and hope that it works out this is a problem with how we often recruit people we often end up recruiting people like ourselves we recruit people for being a good fit whatever that is we recruit people just based on their technical skills it's important that they do have some appropriate technical skills but actually there's other skills that are more important there's a little correlation between a group's collective intelligence and the IQs of its individual members but if a group includes more women its collective intelligence Rises now there are a few of you here already knew there but I'm going to say collectively we could be smarter in this room and it turns out there's a very simple reason for some of this people from diverse backgrounds might actually alter the behavior of a group social majority in ways that lead to improved more accurate group thinking it comes down to how people examine facts how people communicate it turns out if you're trying to do software development which is one of the most intellectually challenging things that humans have ever done thinking having lots of people thinking the same way is actually not very helpful it means you're not really thinking having lots of people who have the same degree who have the say come from the same place have the same background turns out that's a bit of a problem yeah it kind of gets you over one hunt for slams you straight into the next wall turns out you do need to have people looking at things very very differently and that will allow you to get instead of groupthink collective intelligence the wisdom of crowds is referred to James Surowiecki said you know for conditions that characterize wise crowds diversity of opinion independence decentralization and aggregation you can't all think the same way but you do have to get together now one of the best observations when it comes to human beings because I love this is a very simple one Hillel Wayne one of my most controversial software pinyons is that your sleep quality and stress level matter far far more than the language you use or the practices you follow a huge difference oh we spent so long arguing about this stuff it's fun sometimes but as he says nothing else comes close not type systems not TDD not formal methods not anything he's a formal methods advocate his stuffs really good but he's right it really makes a huge difference it's your ability to take on the world he's measurably changed when you've had a decent night's sleep and that actually you know when you don't feel stressed that actually has a huge consequence so overall there's this interesting effect that I'm going to end by putting it all together holism you got to take everything into account when it comes to your code this is a lovely book christmas is coming this is a good book it's a good book because it's a good book for a number of reasons one I found it quite inspiring it's about building architecture yet about half the design applies to any design base 1/2 the advice applies to any design based discipline the other thing is this is one of those books that if people see that you have it they will immediately think that you are far smarter more sophisticated than you are okay oh not just a software developer yeah always designers think by considering it in its next larger context we often focus we're very good at focusing in sometimes you need to just zoom out yeah when people talk about algorithms in computer science they don't focus on where they're being used they focus very much on the inward aspect which is fine but you have to then zoom out and we have we have a very interesting language going on I did a search the other week and LinkedIn full stack developer okay that's a great phrase even better you've got to be passionate as well it's just that wow this is really hard work I've got to be full stack and passionate that's that's that's a lot of love for a lot of coat okay maybe we're over writing that we need to be careful with our words my experience is that front-end development back-end development that's what people normally mean when they talk about full stack development now I'm not really a web developer at all my background is actually the other bit of the stack the the bit of the stack that kind of goes down this is my background so when people say I'm a full stack developer it's kind of like oh so what's your work on device drivers like what well that's the stack that stack goes all the way down there you know I'm not saying everybody needs to know this but there's another direction as well which i think is kind of important it turns out the full stack is quite deep it turns out where is this being used am I thinking about it as a product or as a short-term goal am I just thinking about the next deadline what about the people who are going to use it we're very we're very poor at thinking about users and the true user experience in fact we've even degraded the idea of user experience to simply mean UI design and a lot of people who say I'm doing user experience they're not they're just pushing buttons around I think that the idea is much deeper we should actually care about the user examine what is their experience actually like not do I think it's like and then there's broader picture some of which I touched on in my keynote two years ago developed needs to go further than the technical stack includes the world and the people around the software so on that note hopefully I've given you a kind of sense of what I mean by lean code and hopefully these are thoughts that you can take forward to your work and to your coffee thank you [Music] you [Music]

Channel: DevTernity Conference

Views: 50,612

Keywords:

Id: -nWhH-4wWBU

Length: 65min 2sec (3902 seconds)

Published: Fri Dec 20 2019