Uncle Bob Martin - The Clean Coder

[Applause] okay that was good lordy larrikin huh bunch of PHP programmers is that what I'm talking to you here how the mighty have fallen so tomorrow will be the longest lunar eclipse of this century so far of course there's only 18 years in this century so far so I'm not quite sure why that's significant but it it made me think that we should talk about the moon there's a number of problems with the moon like where did the moon come from so when I was a kid that was a very very long time ago 1960 let's say when I was a kid my science textbook showed where the moon came from they said well there are several possibilities one of the possibilities is that the moon was captured as some errant asteroid that came by and and another possibility was that the moon and the earth formed together at the same time but another possibility was that the moon kind of bubbled out of the earth and then as I turned the page in the science textbook there was a picture of the earth centered on the Pacific Ocean with a picture of the moon superimposed upon the Pacific Ocean and it fits the moon fits right into the Pacific Ocean and the caption was the Pacific Ocean could be the crater out of which the Moon bubbled it's very old science book where did the moon come from how did we get this moon there's a number of problems with the moon number one it's in a circular orbit look again number one it's in a circular orbit you can't capture something into a circular orbit some errant asteroid comes by it's going to be wind up in some horrible elliptical orbit not a circular orbit so there's a problem with that and in fact the only way to give a circular orbit is some kind of co-creation event where the two bodies are so close to each other that they their angular momentum couples and the one is driven out by the other and it circles the orbit that's so that's a problem now you could solve that problem by saying well the earth and moon formed at the same time but there's a problem with that the problem with that is that the orbit of the moon is not in line with the equator of the earth the equator of the earth is tipped by what is it 23 degrees something like that okay but the orbit of the moon is in the plane of the solar system the angular momentum of the moon has more to do with the Sun than it has it to do with the earth which is very weird that kind of argues against this co-creation idea another problem is that the moon is tidally locked to the earth you don't get a tidal lock unless the two bodies start in closed and then the angular momentum couples them out so the moon had to start in closed the angular momentum had the couple of them out but they could not have formed at the same time because they have different angular Momentum's and then the last little bit of evidence which the astronauts brought back in moon rocks is that the moon and the earth are made of almost identical material down to the isotope ratios the ratio of of the isotopes of oxygen for example are almost identical with that of the earth now if you get a Mars Rock you'll see a different isotope ratio so the moon and the earth formed out of the same material except for one thing the earth has a ton of iron and the moon has none so they couldn't have formed out of the same material because the moon has no iron how do you resolve all of these issues and the way they've resolved all these issues is to very cleverly come up with a catastrophe right apparently a body roughly the size of Mars form the inside the orbit of the earth at about the same time that the earth formed at about 60 degrees away so at one of the Lagrange points a gravitationally stable point and eventually something upset that little body that's about the size of Mars and it slowly slid over and slammed into the earth melting both bodies the two iron cores go to the center of the earth these lightweight silicates all splash into a ring the ring about a century later coalescence into the moon a few thousand miles away and then they coupled their angular Momentum's and drive the moon out and tidally lock the moon it explains everything wouldn't it have been fun to watch that No well enough said about that I'm supposed to give a talk here I don't know if you can see my screen it's a talk about architecture I think do PHP programmers know anything about architecture no okay all right talking with the right crowd then this is a talk I've given many many times before in many different venues and it's essentially the the the theme of the book that I wrote recently called clean architecture it came about a long long time ago my son was writing a Ruby on Rails application and he handed me the the source code to it and I was looking through the source code and I saw something funny see if I can see if I can bring that up here let's see I think I'd do it this way there's way too much technology here I've got an iPad and the iPad is talking to an HDMI port and it's going over video signals all over the place and it's just a miracle all this stuff works yeah and it working is pretty reliable most of the time pretty reliable so nowadays I do all my presentations on iPads there we go so this is what my son handed me and I looked at it and I said yeah that's a rails app and you can identify it almost instantly just from the directory structure you see the funny little directories in there like the the DB directory and the controllers directory in the models directory all that stuff very typical kind of Rails directory structure and I'd seen lots of rails apps before and I knew at rails apps were and this one didn't surprise me at all and then all of a sudden I scratched my head and I said wait a minute why is it that the first thing I see when I look at that directory structure is a rails app I don't see what the application does I see a rails app why does the framework dominate why is the framework yelling at me from the midst of that directory structure and I realized at that moment that something was wrong with that now why didn't I realize this before well does anybody remember 1999 got a few people out here and old enough to remember 1999 said 1999 was the the pinnacle of the.com era and then we all lost our jobs and our minds our particular industry is always in demand how many programmers are there in the world do you think not enough is the right answer but how many are there how many programmers are there in the world it depends on if you count all the PHP programmers there's some debate about that I usually say VBA programmers for that one but I decided to give you guys a little little plug there have to be somewhere on the order of a hundred million programmers in the world now you know there's a billion people in the world and a hundred million well that's what you know 180th is it possible that one out of eighty people one out of every eighty people is a programmer of some kind is that possible I think it is all right so let's presume for the moment that there's a hundred million programmers in the world because if there aren't now there will be soon how long ago did the first programmer write the first line of code to execute on an electronic computer what year was that that was 1946 1946 Alan Turing wrote the first instructions to actually ever execute on an electronic computer some other people had written program like things before that but you and I would recognize the code that Alan Turing wrote in binary in base 32 in 1946 that's one and what's the year now at the 2018 that's 70 am I doing that math right let's see 58 plus 1876 76 years in 76 years we've gone from 1 to 100 million now you can do the math there what kind of growth curve is that is that a linear growth curve it's clearly not a linear growth growth car rides all right so it must be some kind of exponential growth curve ok well if it's an exponential growth growth curve let's use the base of two and figure out what exponent of 2 gets us from 1 to 100 million ok well what's what to to the what is a 100 million what is the log base 2 of a hundred million okay log base 2 of a thousand is 10 log base 2 of a million is 20 log base 2 of 128 is 7 27 takes 27 doublings to get from 1 to 100 million 27 doublings to get from 1 to 100 million in 76 years there have been 27 doublings how many doublings per year how many years per doubling 2 ish is the number of programmers in the world double every 2 something years Allah it's not very fair because in the first few in the first decade the doubling rate was much higher Alan Turing might have been the first electronic programmer but a week later there were a dozen so it was probably very high at first and then it slowed down so let's just say for the sake of argument that the number of programmers in the world doubles every 5 years is that realistic does that feel about right the number of programmers double every 5 years the number of programming opportunities double every 5 years this is the kind of industry that you and I work in right where the where that the demand for programmers doubles at an insane rate so in 1999 we have a little hiccup those are rare in our industry usually if you're a programmer you're gonna have a job a pretty good job well-paying job and you will probably have that job for as long as you want it because the demand continues and continues and does not abate and we find all these interesting things to do with computers how many computers are in this room how many computers are on my body at the moment and there's this one now you know that iPhone how many computers are in this there's a graphics processor and another processor and a Bluetooth processor and a GPS process probably six or seven maybe eight nine ten Todd knows how many and then I've got this thing in my pocket air pods and there's at least one processor in each one of the little air pods there's probably one or two processors in the body of the damn thing all right got my car keys there's at least one computer in there I have on my body over a dozen computers just sitting there running code written by some 22 year old at 3:00 in the morning right okay how many how many computers are scattered in the walls of this room where you can't see them right funny little computers just hidden away in the walls like the speakers right the speakers have little computers in them because nowadays you don't want to put a capacitor and an inductor to filter out 60 cycle hum you want to put some little DSP in there that has code written in an inci to do fast Fourier transforms to notch out the 60 cycle hum so but all the little speakers in the room they probably have little computers and how about the exit signs do the exit signs have computers in them they have batteries because if the power goes out you want the exit signs and still stay lit and those batteries have to stay charged and the way we charge batteries nowadays is to have a little digital signal process or trickle charging those batteries to keep the memory effect from from compiling so yeah there's probably computers in those damned exit signs if you think very carefully you will come to the realization that every second of every day you are in contact with some computer system and not just you your grandmother is in contact with a computer system every wait moment of her life because in our society you can't do anything without interacting with the software system you can't buy anything you can't sell anything you can't make a phone call you can't start the microwave oven you can't wash clothes or dishes you can't drive your car oh God your car how much code is running in your car how many lines of code horrible horrible code are running in your car at the moment and you get into that thing and you drive like it's gonna be fine you ever wonder you know midnight February 29th sleep here if the guy did the math right you know is the car gonna actually work or is it gonna turn upside down our society depends on us you and me programmers they don't quite get this yet we don't quite get this yet the level of dependence that our society has upon computer programming and therefore computer programmers is enormous well beyond the stage of critical enormous and our society does not quite understand although they are getting that understanding just how awful our industry is they got a hint with the Volkswagen Fiasco anybody remember that one interesting right all right we're gonna sell the Volkswagens in California by cheating the device the little testing mechanism now now you know what they did right they they they somehow detected that if you were on a test rig then they could tune the to cut down the nitrous oxide emissions right but then in the real world when you're out on the road they just crank those emissions right up because you get a lot more power that way can you imagine the discussion that occurred amongst the software developers when the management told them we got to find a way to deal with this testing problem and the hardware guys have said they can't do it that is you know the engine the diesel engine just can't do it but you software guys you can solve this and can you imagine the software dudes sitting in a conference room going ok man you know like how do we detect like you know we're on a test stand like how do we do that cuz you know like like the wheels are turning but guys not moving like you could look at the GPS right if I GPS velocity is close to zero then we would know who watched the the testimony of the CEO of Volkswagen North America before Congress how many of you saw that and you know Congress some got congressmen cuz they're all obnoxious as congressmen and they look at the guy and they say all right now how could you have let this happen and the CEO of Volkswagen North America said yeah yeah it was just some software developers who did it for whatever reason that is a direct quote and guess who got blamed the CEO of Volkswagen North America pointed his scrawny little nail bitten finger right at you and me deservedly so because it was a couple or maybe more than a couple of software developers who wrote that code and you can say well no software developers they didn't know what they were writing Yeah right if [Music] [Applause] so in 1999 the world went upside down both because of the dot-com thing and because of the web and the internet and we all fought everything has changed everything's different now right the web has come everything is different now in the dot-com thing happen everything is different now and for oh I don't know 15 years we kind of coasted along with this everything is different now and then maybe but no 2012-2013 it occurred to us that nothing at all had actually changed that the web was not anything abnormal web was just a normal kind of request response protocol that we've been dealing with for 40 years okay slightly different format but you know anybody out here working on 30 to 70 green screens do we have any old gray hairs out here that yeah wrote the hypertext that went out to the 30 to 70 green screens and got the forms that came back from the 30 to 70 green screens were just like a browser maybe not quite as impressive but same idea there's nothing new about any of that does anybody remember the emphasis we had in the mid 90s on design and architecture it was the heyday of design in architecture he had Ivar jakob s'en talking about he had Grady Booch to who knows who Grady Booch is who's heard that name right in 1995 I guarantee you every single software developer knew that name cuz how could you not Grady Booch that's a great name right now now it's gone no nobody knows nobody's seen those books nobody's read those books who knows who Ivar jakob s'en is how many of you've heard the name Ivar jakob Singh right one of the we in 1995 I was at a conference just like this one and Ivar jakob s'en was about to release a book the books were there at the conference we all lined up because we wanted to get that book object-oriented software hearing by American this was the heyday of design and architecture we were all focused on design and architecture getting the design right getting the architecture right was really important and then the web came along and blew that stuff out of our brains and kept it out of our brains for 25 years so my son hands me this source code and I look at it and at first I think yeah that's a rails app and then it occurs to me wait a minute where's the architecture where's the design what the hell does this app do and why is it that all I see is rails Israel's really that important should rails be dominating everything well no it shouldn't why because the web is an i/o device the web let me say that again is an i/o device this is nothing else it's just a way to get stuff out and get stuff in the web is an i/o device and you know what we've learned about i/o devices in the 1960s in the 1960s we learned the hard way that when you wrote code you did not want your code to know what IO devices you were using we call this device independence if you were gonna be reading records from a device you did not want to know in your code that it was a card reader you were reading from or a tape drive that you were reading from or a disk file that you were reading from so we invented this concept of device independence and here we are and I'm looking at that rails app and thinking the device is dominating everything about this code down to the directory structure the device dominates everything this is wrong this is fundamentally wrong so I started thinking about architecture what should the architecture of an application look like and I took a little side trip down to the architecture of buildings what does the architecture of a building look like and I I brought up a few blueprints and well you can look at this one you can tell it's a library right the the shape of the building tells you it's a library ignore the title it's a library and if that one doesn't convince you that's a church the shape of these structure screams out its intent it tells you what it's intended for you look at that to make my god that's a church either that or it's a very strangely constructed theater but that is someplace or a whole bunch of people are going to sit and listen to some guy pontificate on stage yeah [Applause] the shape the architecture of the building screams its intent where was the intent in that directory structure and I didn't see it and it occurred to me our Kotecha is about intent the architecture of a system is not about the frameworks that the art that the system uses it is about the intent of the system what I should have seen when I looked at that directory structure is a list of the intent all the use cases I should have seen all the use cases of that system one in each directory I should have seen you know added whatever it was I don't even know what that system was all I knew is that it was a rails app so here's the guy this is Ivar Jacobson anybody octopus in' wrote this book that I told you we all lined up for in 1995 to get a copy of and the name of this this book was object-oriented software engineering does anybody remember when object-oriented was a really important word right and nobody knew what it meant nobody knows what it means now but it was very important in those days and we all wanted to know object-oriented design an object engineering and object oriented analysis and stuff like that here this book and I want you to look at the subtitle down there a use case driven approach does anybody out there remember use cases remember the use case furor that went through the industry in the late 90s we all had to know about use cases and all the consultants jumped on board that and they all had to do each other so each each consultant published a PDF where there weren't PDFs in those days so it's probably some kind of a God what was the name of that printing protocol that we all used that laser printers all used the PostScript what language is PostScript what's the base done fourth any fourth programmers out there anybody done any fourth program oh you know somebody has so if you want to have a lovely deke out weekend right get rid of your family tell them to go away because you're gonna go down to geeky rathole fire up a fourth engine and learn a little bit of fourth it will twist your brain in a strange way and you will come out of it with a great appreciation for PHP so Jakob s'en he writes this book he says look architecture is about the use cases it's about what the system is supposed to be used for the intent of the system and he he gives us some examples of use cases which I've got here for you this is an example of a use case simple idea in this case it's a use case for an order entry system and this order entry system has a use case called create order and you can see that it lists the incoming data doesn't give you any any real detail about the incoming data it just sort of says yeah there's a customer ID coming in I don't know you know what it is might be an integer my pew name I don't know I don't care at this point and it's got some shipment destination god knows what that is but it ought to be in there and payment information customer contact shipment mechanism all this stuff no definition no detail the whole purpose of a use case is to avoid detail because detail is the stuff that happens later and then there's the course of events and the events are very simple the order clerk issues the create order command that's not even part of the use case that priest comes before the use case then the system validates all the data it doesn't tell you how it just validates it somehow system creates the order and determines the order ID that's probably a database function but I don't bother to say that here cuz I don't want to mention the word database in here and then by the way databases does anybody get that feeling that databases are the center of the system that the programs are the little minions that bow before the Great God database in the sky that all significant things actually happen in the database the database and the data model are the key what is a database it's an i/o device we're not supposed to know they exist databases are places where you put bits we don't want them to be the great god-king that we surround our code around and bow to it the database is a detail so I don't mention the word deed database here that's fine then I've in the end it says the system delivers the order ID to the clerk probably over a webpage or something like that but I'm not going to say anything like that this is a standard kind of use case now what Jakob scense said is that okay you've got these use cases you can turn them into objects in an object-oriented sense right he was writing this out this book called object-oriented software engineering so he said you can turn every use case into an object which he called a control object I've changed the name here I've called it an interactive object people have yelled at me for this and said Bob you should have called it a use case object there is a certain amount of sense to this but I stick with the word interactor the interactor object knows the application specific business rule now there's two kinds of business rules there's the application specific business rules and the application independent business rules what is the difference between the two well application independent business rules are always true even if you didn't automate the system they would be true for example the interest charge on an account at a bank that is an application independent business rule because the business rule is true even if you don't automate anything what is an application specific business rule that's a business rule that is specifically related to the automation to the application itself use cases our cases of the way the application is used so they are application specific they are somehow dirtier than application independent business rules but there are still business rules where do we put the application independent business rules well Jakob heym had an answer for that he said we're going to put those in things called entities now lots of people nowadays use business objects we all have business objects and business objects are a kind of hybrid of these two concepts and actually most systems don't make any kind of distinction between business objects and UI and databases so they're just kind of actually kind of messes so here we are separating the application independent business rules the entities from the application specific business rules the interactors and it is the job of the interactor to control the dance of the entities the interactive will be given a task and the interactor will then control the dance of the entity is telling the entities to do their little jobs and then gathering information from those entities to present back to the user and for that last function Jakub s'en had boundary objects which you can see here I've driven them I've drawn them here in UML as kind of interface objects and every interactor typically has two such boundaries one which it derives from so this little arrow this funny little pizza wedge that's the derives from arrow or the implements arrow that would be the input boundary data would come into the interactor through the input boundary and the other one the one that has the open arrow head that's going outward that is the output boundary so the interactor gets its data through the input boundary controls the dance of the entities gathers information and sends them out the output boundary this was Jakob since architecture and it is a lovely architecture separates things very nicely you now have a whole bunch of use case objects in those use case objects talk to a whole bunch of business entity objects and then you have boundary objects that control the flow of information in and out very nice now let's just walk through the whole process here we've got some delivery mechanism out there might be the web might be a might be a web age or a web system out there I don't care Mike nothing might be a console based system might be a thick client based system I don't really care something is going to be providing input to me and accepting my output and there's some user that user sits down there and eventually the user is typing in information which our system doesn't even know about yet then at some point the user pushes some button or hit some key that that causes the entered information to go into the system so the delivery mechanism whatever it is packages up all of that information that the user typed in and then passes it through the boundary the input boundary into the interactor I think I can actually show that here I think I've got a little kind of quasi animation there it is and notice that the delivery mechanism has created something that I call a Cree quest model a request model is a plain old object a data structure if you will it does not derive from anything it is not part of any framework it doesn't know anything about whether you're using a god-knows-what framework or god-knows-what engine or anything else it's just a bunch of little data objects that have been translated from the user's input into a nice convenient form and passed into the input boundary so the interactor can get at it and then the interactor grabs that and uses that request model parses it understands it uses it to control the dance of the entities so now the entities are busy doing their thing and the interactor is controlling them making sure they do the right stuff and then the flow reverses and the interactor gathers the result data from the entities and collates it and manipulates it and does whatever it needs to to create yet another data structure called a result model and that result model I think you probably have anticipated this already goes through the output boundary to the delivery mechanism which formats it for the user and sends it up on its way very nice cogent little architecture an architecture that would allow us to create Business Objects named for the use cases of the system if I were to see that in a directory structure I would know what the system does now let's say that we're using a framework some wonderful web framework that does lots of interesting work for you where is that framework here answer it's not anywhere here why would it be because the framework is an i/o device or a manager of i/o devices the framework is a detail frameworks not part of the application the frameworks just a bunch of tools that you use to help you do this the framework must not sit at the center of everything the framework must not be the thing yelling out to everyone I am a rails application the framework should be hidden away in a small corner and you use it as you need to use it from time to time what about model-view-controller aren't we all supposed to be MVC in here is it who invented Model View controller does anybody know who invented this where it came from say it louder small talk yes it was in the language it was in the language small talk that it was created was created in the 1970s by this guy and I'm going to butcher his name because no American can say his name it's Danish it's trig Viren Scout completely butchered his name he wouldn't say it that way but it's the only way I can say it and in the 1970s he invented this lovely little idea of model-view-controller I met trig v I was in Norway this was eight years ago now I think and we were both in the speaker lounge of a conference and I walked in and I was looking for a place to plug my laptop in and this drizzled old guy walks up to me and hands me a a power strip and I you know I don't even look at him right well thanks a bunch and you know my fingers brushed him and I looked up so it's triggy means cat I haven't washed that hand the idea behind model-view-controller was lovely now by the way it was for small talk right so it was small the idea behind my viewcontroller was a small idea not a big idea this was not a sweeping architecture to conquer conquer the masses this was a little thing and the way it worked was this you would have a model object a model object understood simple business rules let's say we're doing a digital representation of the time on the screen a digital clock on the screen well the model would understand time it would understand how minutes and seconds are related now hours are related to them and might understand calendars and things like that it would have no idea whatever how this data was displayed or how in input came in the controller was a little object that watched for input typically with the mouse so the controller would watch the mouse and the keyboard then it would capture Mouse events and keyboard events and then use those to send commands to the model to change the time the view and I've drawn that with that thick arrow because the thick arrow is an observer relationship it's a callback relationship the view would register with the model and whenever the model changed for every reason they would say hey or the model would say hey view I've changed and then the view would pull date out of the model and display it for everybody that was model view controller real simple idea and if you look at it carefully you'll see its input process output when we wrote these kinds of things in small talk we wrote them for small things a radio button would have a Model View controller triplet a textbox would have a Model Model View controller triplet they were little things they were not the grand scheme that has evolved into now nowadays Model View controller looks something like this now there's some relationship here but it's very different right you've got the web out here and God knows what that is it's some horrible framework in the sky that everybody uses no one understands and then you've got a bunch of controllers that the web calls because they know the web parses the urls and figures out what to do and calls the controller's with the data and then the controller's reach over here and talk to a whole bunch of business objects and then the controller handles hen's control over to the views and the views talk to the business objects and then hand that data back to the web and that's the Model View controller that we all know and love today and one of the problems with this is that there's no clear separation of where you put input processing and output processing so controller like stuff manages to work its way into the business objects and view like stuff manages to work its way into the business object so you don't have a really good separation so I like to avoid that by separating out the use cases into interactors and boundaries and so on so this is kind of the the picture that I like I've got a bunch of entities out here which is sort of like your Business Objects interactors are the things that isolate you from the outside world and control the dance you've got an interactive which in this case has created a response model it's going to pump that out the boundary across that double black line when I draw a double black lines that's an architectural boundary there's something significant about that particular boundary there notice that all the arrows point the same direction across that boundary architectural boundaries look this way all dependencies point inwards across in architectural boundary and more importantly they point towards business rules they point towards high-level concepts there are low-level concepts on the one side and all those low-level concepts point towards the business rules why well take a look at that left-hand side and never mind what it is I'll tell you what it is in a minute it's a plugin to business rules if I were to take that whole left-hand side and wrap it up into some component and hand it to you you could plug it in to the business rules business rules don't know it exists all the business rules now is eller some plug-in coming in okay well I'll use it normally it's a plug into the business rules now what is this thing over to the left well that's the web the web interface should be a plug in to your business rules your business rules shouldn't know that the web exists shouldn't be related to the web at all and the web should plug in and you should be able to unplug it and plug in something else you should be able to plug in a console interface and you should be able unplug that and plug in a thick client interface or a a what is that horrible architecture that people used for so long service oriented that's what it was okay so you should be able to plug in a service-oriented interface and none of the business rules should care at all because the device is independent we want independence from our devices now take a look at the left the left is kind of interesting the way I've drawn it here I've got a response model that's going through the output boundary to a thing called the presenter what the presenter understands is the format of the data that the web will eventually use it does not know that there is a web but it does know the presentation format so the job of the presenter is to create a whole bunch of strings if you have a date for example make sure there's a date in that response model well we're gonna turn it into a string the presenter will turn it into a string and store it in the view model if you have currency in the biz in the response model out there the presenter will turn that into a string if you have a button and that button has a name the presenter will create the name of the button and store it in a string somewhere so that everything that needs to be displayed on the screen winds up in this data structure the view model which is just a normal old data structure again a bunch of drinks in it and then the view which you see they're drawn ghostly it's just a stupid little program that pumps stayed out of the out of the view model and puts it on the screen somehow who's doing TDD test-driven development who's doing this he we got some people applauding that's good we have people with the hands in the air that's good about 10% of you I would say okay this is about well if I if I were to do this at a Java conference I would get a third if I were doing it at a ruby conference I would get half right so gives you an idea of the demography here what the hell are the rest of you doing you're not doing test-driven development with that get the rest of you doing how do you control your code if you are not writing tests and if you are not writing tests with some kind of discipline are you writing the code and then just kind of looking at it on the screen and saying okay it looks like it works that what you doing is this what our society needs now think about this very carefully because our society is coming to a point where it's going to start saying you know these software guys we depend on them for everything and these guys keep to a dancing right right like who remembers October 1st 2013 the date that the Affordable Care Act website was supposed to come online and it did it came online didn't it can you imagine the programmers right they're going to turn it on they really they really shouldn't turn it out and we tried to tell him that they shouldn't turn it out but they're they're gonna turn it on anyway is it because of that Fiasco and it's very interesting right here's here's a law passed by Congress signed by the president which dictates that a software system must be ready by a date certain now never mind the stupidity of that someone who wrote that lawn that have had no understanding of how software systems work never mind that they turned it on and it almost derailed that law that law almost went down because the software developers could not manage to communicate well enough to their managers that they shouldn't turn the damn thing on this is the problem that you and I have you and I are programmers right most of the time we don't think about society or your people because you know we're like oh this is cool and sis and we don't quite get the fact that our entire society is depending on us for the next day's operation for society even functioning so you can imagine what's going to happen one day because here's what's good so anybody know what happened at night capital hey anybody heard the story of the night capital nightcap it's just about about eight years ago nine years ago bunch of guys right they're writing this trading system they do high-frequency trading and they've figured out a way to take large trades and break them up into small trades and this is a trick that trading companies used to hide the fact that somebody made a large trade they break it up into small trades and they pump it out over a bunch of different networks and they have a lovely algorithm for it who works fine and then they decided to rewrite the algorithm so they put a whole new different algorithm in but they left the old algorithm in they just disabled it with a flag now already there should be sinker muscles tightening in the room they did what they left all that code in there and they just disabled it with a flag and where was the flag you say in the incoming transactions but as time went on as things do in software this all just got buried and hidden and no one knew that it was a problem or even there and then one day there was a new tax law that came along and they had certain transactions had to be flagged as being a part of that tax law and they saw this that extra little bit sitting there though we could use that and they wrote the system properly and they went in at night and they installed it into all the servers well not all forgot one they forgot one they had 14 servers they forgot one they put it in 13th just didn't quite pull the trigger on the 14th somebody miscounted and they tested it worked just fine they turned it on and they got a call within about 10 minutes from the SEC saying hey something weirds going on like you're making crazy trades and the programmers panicked and said oh man something wrong with the new code so they pulled all the new code out and put the old code in to all the other servers four hundred and fifty million dollars in 45 minutes down the tubes the CEO woke up in the morning without a company vultures had already swooped in and bought it out from underneath it this is the kind of strange thing that you and I might find ourselves involved with now what is going to happen right and it's it's very predictable right some poor software guy maybe you even know him or her is going to do something stupid and kill 10,000 people and it's just going to happen you know what's going to happen it's not that hard to think of the scenarios and then what and then the politicians of the world will rise up in righteous indignation as they should and they will point their fingers right at us oh they'll try to point at the CEO but the CEO so this offering guys did it for whatever reason and that finger will come right to us and they will ask us the question how could you have let this happen and we better have an answer for because if our answer is well you know the boss said that it had to be delivered on Tuesday if that's the answer we deliver then the politicians of the world will do the only thing they can do the thing that the public will demand that they do they will pass laws and you and I will all become public servants they will tell us what languages we can use and what processes we have to use what signatures we have to get and what books we have to read and what courses we have to pass what degrees we have to have and you and I will become regulated then that's something I would like to avoid now other industries have managed to avoid this how did they avoid it doctors doctors avoided this by coming up with the regulations on their own before the government could ever get to him and then finally government said you know these doctors we've got to regulate those and the doctor said well it just so happens that we have some would you like to use ours and government is essentially lazy right said the doctors have already done it like so we could claim credit for it this is what you and I have to do we have to come up with the regulations before the government comes up with them we have to enforce them we have to obey them the first step in doing that is to identify what these regulations are and doing them ourselves without anybody else and test-driven development is a decent candidate for such a regulation is a lovely little discipline that everybody can follow it's not that difficult doesn't take any extra time it makes things go fast gives you a lot of control over your code let me tell you you should think about this very carefully so I want to test that interactive I want to write unit tests to test that interactor can well yeah I just load up a fake respond request model pass it into the interactor yeah they look at the response model it comes out look at the day then there's yeah that's right I can write tests for that interactor with all the entities in it and I don't have to have the web running the web server doesn't have to be running when I do that I can just make calls directly into the interact or passing in data structures or can I test that presenter and I test the way that works that's easy I'm gonna pass in a fake response model pass that through the presenter and look at the view model do I have to have the web running in order to do that no cuz I don't need the framework in there I don't need the web in there I can test all that stuff in isolation being able to test in isolation is a decent indication of a good architecture being unable to test in isolation is a decent indication of a crummy architecture if you must fire up the web in order to test your app something is wrong what about the database I mentioned this before right is the database the Great God in the middle of your systems now you know what happens when you've got a great god in the middle of your systems it also becomes the dumping ground oh god where do we put this function I put it in the database he's going there somewhere I want you to think of databases as not existing right when you're designing applications I want you to think about the function of the application not the data of the application I want you to write the code that does the data manipulations and ignores the data storage defer the idea of data storage to a later time let me show you an instance of that yep there we go long long ago about 2,000 my son and I wrote an application called Fitness is anybody used to sit in the center you see anybody who's used tritanus I don't see any hands up okay alright Fitness is a wiki it's also a testing product you can write acceptance level tests on wiki pages I'm not going to get into the the mechanism there what I want to talk about is the architecture we knew we had to write a wiki and so we said well alright wiki's you have to store pages we're gonna need a database we want this to be open source the years 2000 what open source database was there well there was my sequence alright let's get my sequel and fire it up and we'll use that and somebody said well we don't have to do that yet because there's all this translation from wiki text to HTML why don't we do that first which is yeah that's a good idea so we're doing test-driven development and writing tests you know to make a little test pass and next test make it pass and take this wiki text and translate it into HTML and took us three months three months of working do you do to do to do make parsing all of the HTML or parsing all of the wiki text turning it into HTML and about three months later we're all done with that and we've got a functioning translator we that we can't put a page up on on the screen but we've got a functioning translator all the tests are passing so we think that's pretty good then we say okay now we need to get the database so that we can store this and put it up on the screen and somebody said well you don't actually need to have a database for this because what you could do is take the take the data and put it into a hash table in memory the hash table in memory is kinda like a database it's just that it's not out on disk and so here's what we did we created a little object called wiki page and it had little translate function in it to HTML that's the code that translated from wiki text to HTML and then that we also put a save function in there to save it in the database but we didn't let it save it on the database because we made a derivative of this called in memory page and that just stuck it into a hash table okay now we could write more code and we wrote all the code that linked pages together and put them up on the screen and actually ran tests and everything was a year we worked a year this way and we had the whole thing working couldn't save anything was very inconvenient but it worked except that you can save anything and then we finally said okay well it's time to it's time to get the database let's go get my sequel and we'll put it in my sequel Michael feathers was there at the time and Michael feathers said you know you don't actually have to do that yet because it'd be really easy to take that hash table and write it out to a file and you know you're gonna live with it that way because who the heck wants to live with a flat file but for the time being you could do that and keep on writing tests and we thought well that's a good idea and he actually came back a day later with the whole thing working in the file system mode so we just kept on working and now we had persistence and we could save the pages we took it on the road and we showed it to customers and clients lots of people liked it and we kept on adding new new features to it on and on and on about three months later we came to a very interesting decision we don't need that database we never put it in there there was no point we had it all functioning it works great we pushed that decision right off the edge of the project now normally you would think that the choice of database is a fundamental architectural decision it's not we pushed it right off the end we took it and pulled it off the planet except for one little thing about a year later customer of ours said we gotta have everything in the database we said well why some database vendor came and told our bosses about data assets and now they want everything in the database we said well it's a great word isn't it data asset don't you wish you came up with that go you wish you were the marketing guy at Oracle who came up with the idea of data asset what a great way to talk to financial people do you have you know you've got data assets no I didn't know he had dated oh yes you do and you need our system to help safeguard your data asses wonderful idea anyway here's this guy come since I gotta have it in a database why the data asset I got it so we showed him this structure right we said look just make another derivative call it your database page and all the father controls are there it's all gonna work just fine it came back a couple of days later the whole thing was working in my sequel for God's sake they crammed the database in at the very last minute we used to ship that as a plugin to fitness for several years but nobody used it so we threw it away even II throw it away in the end isn't as useless no point in doing that there's a interesting lesson to learn from that a good architecture allows major decisions to be deferred deferred to a time when you have more information a good architecture opens up options does not close them down it opens options it allows you to experiment with lots of little details without committing to any of them a good architecture maximizes the number of decisions not made think about that very carefully not it happens to me frequently enough that I ask people what's the architecture of your system and they'll say something like ah it's a Java system we're using spring and an Oracle in it that is not an architecture you have not given me an architecture what you've done is showed me all the tools in your toolkit they haven't described the architecture to me the architecture should make the choice of tools irrelevant and what that means of course is that we want all of the peripheral stuff like the database and the frameworks and the user interface all to be written as plugins to the use cases so that you can unplug them and plug them in later you don't like Oracle plug in some of the database you know go on maybe you want you know sequel server god help you but all right maybe you want to do that or maybe you'd like to experiment with some no sequel databases hmm you can plug it in because the application doesn't care oh I already talked about that I could talk about it some more than good that is the end of my discussion I can't see a thing ah the lights have come up are there any questions I don't know if I've gone over my time limit or not my watch died [Applause]

Channel: StreamACon Streaming Conferences

Views: 121,919

Keywords: PHP, Laravel, Laracon, Uncle Bob, Bob Martin, Coding, Programming

Id: NeXQEJNWO5w

Length: 64min 6sec (3846 seconds)

Published: Tue Aug 21 2018