 For the final presentation, we have invited Jim Weiner, the guy on the left here to come out. He's very successful in accepting to come out. Jim is, works for Edgecase. He's located in which city? Edgecase is in Columbus. He's in Cincinnati. Edgecase is in Columbus. I've known Jim out for 10, we're almost on three years I think. I showed up at RubyConf in 2006. Can't tell you what he presented on that. I can't reference you to the video because we don't have anything in 2006. But then at RubyConf 2006, we created conference. It all happened. So Jim has been major inspiration for test-driven development. Getting me out of the right code, playing with it, see if it works. And then taking it back to the customer to actually do the rendering in factory. I would say on a regular basis, I don't write code on a regular basis these days. Unless I'm playing on my own projects. But with that, the other thing that I've been a lot of Jim for is both Jim and his partner do test-driven development training. We had him out in early February with AT&T and I. Or AT&T and I, whoever we are. AT&T and AT&T and I. All 30 engineers, lots and lots of working full-time so that we could spend three days learning from Jim and his partner. And the other thing I want to mention is that you are an enterprise-related, working in enterprise businesses. Jim and Joe host a conference in Ohio in the fall. In August. In August, I'm going to call he Ruby Khan, which is definitely worth getting involved with. Now I'll turn the mic over to Jim, and special round of applause for him flying all the way out here from Ohio. I can't say anything so come and get back to the camera, so. Mike's not out today. Mike's not out? That's kind of the same thing. This is Mike's not out. There we go. Very good. Now we're going to make this all things. I'm Jim Myers, I was introduced, and I'm the Chief Scientist for EdgeJS before that I worked with a company where I was a consultant. And one of the things I did for those two companies, and I still do for EdgeJS, and I also do for clients that I work with, I do a lot of technical interviews. I would talk to someone on a phone for half an hour an hour, and I would try to clone their technical skills in different areas. Generally Java based or Ruby based type of stuff. I look at entrepreneurial design, the knowledge in math, I look at, I'll tell you about agile development, and just general ideas on what I'm going to do. I do this over the phone. There are a lot of questions I ask, play with these questions, and get a feel for that, just the technical stuff. One of the favorite questions I like to ask is what do you look for when you're doing a design? What makes a design good? If I were to lay two software designs to architectures in front of you, say we do it this way, we'll do it that way, which one would you choose, one over the other? What makes a good software design? And the scary thing is, most people, their answer is, and they kind of freeze, they don't know about the answer. So let me ask this question to you. What makes a good software design? Give me some feedback. Sustainability. Sustainability. Sustainability. By that you mean? Maintainability. It doesn't fall off a cliff six months down the road. It should be as simple as possible and no simpler. Simple as possible and no simpler. On your eye. Scalable, like your modular over here. On your eye. On your eye. Beautiful. Beautiful. That makes the question a lot of ways. Another interesting question. Okay. I'm glad you guys have answers. A lot of people I talk to don't have those, or they can't express it in a way, in words, which means they might have a good feel for this design is better than the other, but they can't quite put it into words. So think about this for about the next 15 minutes or so, and we're going to talk about it in an already different topic. Well, I guess we're here. Well, I guess we're here. Stay this long. Okay. Magic. It's magic, yes. Cheesy, touchy, mad, grab, generator. Pumping all kinds of negatively charged particles into your body. And we know that charged particles attract and repulse each other according to certain rules. Essentially, if you have two particles of the same charge, they will try to get away from each other. Very close together, the repulsion is quite strong. If they are farther away, the repulsion is much weaker. So it depends on how far apart they are. This is an electric charge, a small electric charge creates an electric field around an electric field nothing more than the force generated by that charge at every point in space. Now we can represent this field at a particular point in space as an arrow in the direction the force is pointing. And it's very interesting. Now most electric fields are static, but it's very easy to generate an electric field that varies, that moves back and forth. Now the interesting thing about a changing electric field is that it never exists alone. Whenever you have a changing electric field, you also have a changing magnetic field that for some odd reason is perpendicular to the electric field at that point. So essentially, if you take a charged particle and shake it up now, really, really fast, you get a changing electric field and a changing magnetic field. Now this is really interesting because in the 1800s, there were two forces and they moved on magnetic forces and they discovered that there's this bizarre relationship between them. But they couldn't quite figure out what that was. I gave this talk last week in Edinburgh, Scotland. And it turns out that James Cook Maxwell was born educated in Edinburgh. I didn't know that by James Cook. So now you have more information. Maxwell came up with four partial differential equations, both Maxwell's equations, surprisingly light, that describe the relationship between a changing electric field and a changing magnetic field. And it describes in such a way that he can very clearly define how they change the relationship between each other. It turns out when they change, they generate a wave in space, an electromagnetic wave. Light. Light is an electromagnetic wave. So I'm describing these two entirely separate forces and by unifying them together he was able to come up with the entire theory of electro-magnetism. And this work was done in the 1800s. Beautiful work. In fact, Wikipedia says that Maxwell's work in producing a unifying model of electro-magnetism advances in physics. And someone back there mentioned beauty. When you can do this with two separate things and unify them, that is a thing of beauty. In the early 1900s, in the beginning of the 20th century, physicists decided that they pretty well knew everything there was to know. In fact, prominent physicists were coming to the universities that they should not study physics because everything was creeping out. There were a few minor details they needed to work out and figure out what was going on, but for the most part they pretty well understood the nature of the universe and there was nothing left to learn in physics. At the time, they believed that matter was like oatmeal. In other words, the positive negative charges and they knew that there were these charges in matter but these charges were kind of spread out more restlessly in this kind of rather lumpy soft oatmeal-like material and there was no real structure in there at all and just kind of oatmeal-like. In the early 1900s another fellow named Ernest Rutherford decided to do a really interesting experiment. He took a gold leaf foil and hammered it down until it was as thin as he could possibly make it. Just a few atoms you could almost see through the gold foil was that thin. And then it took a beam of alpha particles. He wasn't quite sure about alpha particles but he knew they were positively charged and he shot them through the gold foil and he made a prediction. He says if gold foil is really structured like oatmeal most of my alpha particles are going to get the backside of that detector and they will scare our problems. They will scare about a little bit but most of them will go mainly straight through with just very little of much of either way. The result he got was surprising and he said that the best advances in physics happened with a failed experiment and the results he got back were always surprising because they did deviate a little bit but there was a small number of particles that deviated widely. They were reflected off to 90 degrees a few about one in 8,000 particles were reflected almost straight back at the particle detector. Rutherford said that it was really broken and that's all mush. What in the world was causing these things to bounce back? They should just shoot through that opening like bullets. So something was wrong with this theory of matter and so instead of being like oatmeal it was like oatmeal with raisins. Something was hard in that oatmeal reflecting back and by further study we had a better understanding of how matter was made and it turns out and the more model the atom was created we have a positive center of the atom the atom is mostly empty space with a kind of electronic cloud orbiting the very small nucleus. Now this isn't a scale, a real scale thing we have that nucleus impossible to see so small but the matter was mostly open space that's why the alpha particles went straight through those that reflected back are the ones that hit that tiny, tiny nucleus in the middle and by examining that they can figure out exactly how big that nucleus was by the nature of reflection of the alpha particles. Fascinating stuff. So now we have a nucleus of a whole bunch of positively charged well we can call them protons now we understand they're protons how what did I say at the very beginning things that are at the same charge you want they repel each other so how in the world do you get all these positively charged protons together in one tiny space why doesn't it fly apart so all of a sudden the mystery started opening up in our understanding of the world and we didn't have anywhere near the understanding we thought we did at the beginning of the 19th century turns out there's a number of forces involved we've unified magnetism and electric fields into a single field electromagnetic fields we know about gravity that's been studying since Newton's day we fairly well understood that turns out that there is another force called the strong nuclear force that binds the protons together and even though they're electrically repulsed from each other these strong nuclear forces stronger and binds them together and not only do we have that there's also a weak nuclear force that has something to do with what's called beta decay I'm not sure I could explain that but the physicists understand here and now four separate fields that they have to deal with and this bothers physicists because physicists like programmers deal in three kinds of numbers zero, one, and many and you can get away with maybe two fields a lot of magnetism and gravity but high four four doesn't make any sense to the physicists why not high, why not three why not 20 there's no they have no theory that explains why there are only four so physicists are desperately trying to unify the four fields together under what's called the grand unified field theory and they have been working on this for a hundred years ever since they knew about the different fields they wanted to bring them all together Einstein tried to work on a unified field theory and failed and there's no real boom theory right now there's a couple of things like string theory and it seems like 14 dimensions or stuff and it hurts my head when you think about it so it's not simple anymore so that's the state of physics today we've got a bunch of things that are out there and we're trying to bring them together under one grand unified theory so let's talk about principles we mentioned some principles that you use someone mentioned dry, don't repeat yourself principle, the solid principle does anybody know what solid principles are I saw one hand back we have five principles, Paul Martin talks about them a lot they're talking about single responsibility open-closed principle that was list cost substitution principle I is interphase segregation and D is dependency inversion talks about how we relate to each other and how to write through code five principles there small methods are designed by contractors, we ever use Eiffel how to write software so they can cooperate together so there's lots of ideas on how to write good software but we don't have a grand unified theory that software developed yet so I want to present some ideas today that might confuse you to think about how we might unify at least some of these things from 20 principles down to a handful ok, so the topic my title is really grand unified theory of software development I didn't like the the modularity title, I had to submit the abstract theory and I couldn't think of a good name this name came to me later so I like this name much better because I want to think about how to unify all these ideas go back in time when I was first starting writing software my mentor gave me a book by Wendell Meyers called composite structure design back in that day everything was structured this was structured that it was my object oriented our functional programming is today it was the big fat so you had to call everything structured something like that I didn't start my time at the time I had no idea how I would have been talking the thing I remember most about this particular book was that he'd find coupling and cohesion in a very straightforward way and I went from today on particularly about coupling and Meyers defined seven layers of coupling starting from the top where it's the weakest and best kind of coupling down to the bottom which is the strongest and worst kind of coupling and kind of put them in this ordering and it's actually a very good ordering I really like it let's talk about the ends of that at the top we have no coupling that's easy if this software has no interface to this software we hear they are not open at all and that's a good kind of coupling now if we threw all our modules and made them un-coupled for each other we wouldn't have any programs that actually work together so we need some kind of coupling between modules the bottom most is a cognitive coupling and that's evil that is when you're reaching the end of a model and manipulating the insides that would never intended to be manipulated like that Meyers uses the example of writing assembly programs that jump into the middle of a method instead of starting at the beginning really strange stuff like that calculating offsets in the membrane from things that you shouldn't be doing really evil kinds of coupling that's cognitive coupling it's so bad most people don't even do that today so I can't really worry about that these four in the middle are really interesting because they're related they are related by the fact that pass data back and forth between modules the top two pass data via local methods in other words generally parameters I call this method and I cast parameters into it so that makes that calling method coupled to the caller method through the fact that I can cast a data to it the bottom two pass data via globals which we all know is bad we tend to avoid globals these days so that's why they are lower on the list with more coupling the distinction between the top two and the bottom two together is the distinction between simple data and structured data if I call a method and only passing data types like integer strings symbols things that have no internal structure that's a lightweight kind of coupling if I call an object and I pass in a user object that's a complex object it has methods on it and all kinds of assumptions and so when you pass complex data that's a higher coupling than passing simple data so that's the distinction between data coupling and standard coupling the difference between external coupling and common coupling is the same except you're passing structured global data versus passing simple global data so those are easy enough to understand and it's fairly easy to agree with the ordering there the middle one content coupling is really interesting because it's different from the other it also deals with passing a data but rather than the type of data it is the intention of the data that matters in control coupling there's a there's two things that flag control coupling the method the parameter passing is some kind of flag it instructs the method you're calling to do one thing or the other and you can tell this generally by the fact that the description of the function generally contains the word or which is semantically equivalent to or and the other thing you can tell is that the flag value is arbitrary it's not related to the domain of the problem that you're trying to solve true false is rather arbitrary let's look at this method what does this method do returns returns this method is on a ray what can these methods do turns the parameter on I'm gonna say true false I'm gonna say false how many of you have no idea what's the problem that's control coupling true false has no relationship to the meaning of the method if you have two methods here and all instances whatever then you can it'd be easy, it'd be obvious there would be no control coupling there at all also the example has this in the description that uses the word otherwise which I will claim is semantically equivalent to or another example control coupling, right the fact that we use the symbol first has no intrinsic meaning to the problem that we're describing furthermore they return different kinds of things when we return to single object the parameter returns a list of objects so if I actually pass that first parameter in as a variable I wouldn't know how to handle the result because I wouldn't know if it's an array or a single object you have to know what that first parameter is so another example of control coupling a little bit better because at least we use symbols that hint at the meaning but it's still control coupling now minor specifications were pretty good for the time this is what had been made in Fortran and Pascal C was beginning to get some popularity so these specifications look really well for the statically compiled straightforward language like that however in today's dynamic languages that use object orientation these categories are weak they really don't cover all the way to get past things around a couple of days especially in Ruby which allows such dynamic behavior so these categories from is a good start is not quite where I want to be so let's fast forward to 1996 a fellow fellow named Wheeler Paige Jones wrote a book called what every programmer should know about object oriented program rather a pretentious title nearly as bad as the Grand Unified Theory of Software Development and in this book now this is a good book that has three sections in it the first section is an introduction to object oriented design it gives Groovy your way past that introduction you won't need it so forget the first section the middle section is a description of a graphical notation to use to describe your designs who uses UML these days you don't even use UML probably at all this wasn't even UML this was before UML no one uses this notation so the middle section of the book, forget it however the third section of the book talks about a concept that I would like to share with you today that concept is called canasis canasis means things that are born together and change together in other words he's trying to capture the idea of what pieces of code affect other pieces of code in terms of software two pieces of software share canasis when if I have to change this module that module needs to be changed as well or at least I have to look at that module to see if it needs changing so things share canasis from changes in one affect changes in the other that's the basic definition of canasis style that would be pretty good but Miller-Page Jones took that a little bit farther and said there are categories of canasis that we can talk about and the first one we're going to talk about is this suppose I have a model called customer and it has an email method in it and then I use that email method and some other client for it I want a sense of email and I call the email method on a customer object there is a canasis between these two pieces of code identified by the name of the method we call this canasis of name because changing the name in one requires a change of name in the other piece of code so they are coupled by a name but there are other examples of canasis of name in this code right there some people say oh I forgot this slide canasis of name not only applies to code but can apply to things like the database to change the database I might have to change the name there some people will say the name of the class and the name of the variable that is actually not canasis of name because I can change the class name and the variable name doesn't matter it's nice or readable that they are the same so that's not canasis of name however there is another example that's right here in the method that's the match the name that you use inside the method this is obvious we all know this so there is nothing more deep here the point is that you can have canasis between close pieces of code and canasis between code that is more distant than other that leads to a principle that I call locality so you can have things that are grouped together the canasis between the things that are grouped in the same class for example in the same method in the same class in the same module you can have stronger canasis than things that are separated part of that model so it's okay to have stronger canasis than things that are close the principle of locality as the distance between software component increases you want to decrease okay that's canasis of name let's talk about another kind of canasis I was working on a Rails app that returned parameter values in a hash like this the key of the hash was the order number identifying the order in the database the second parameter was whether the order should be expedited or not it was a checkbox and I turned this funky hash from Quran into something that I could handle a little better I looked up the order basically put the first number and then I would put a x dot by true or false in the second position control column watch it real closely but that's okay but there's a different kind of canasis going on here we actually have an ordering top line I processed the order and knew it in each loop I had to specify parameters in the lambda for the each and they have to be in the same order as they are on the list in fact if I build the place where I build the order list problem the place where I process the order list has a canasis between we call that canasis of position if I change the position of those things in the order I switch them around then I have to change every piece of code that assumes the order is in the first position and the flag is in the second position that's canasis of position okay, let's think about this this did not bother me too much in order there seemed kind of natural to order to convert the flag in second however suppose I had something that looked like this if I had to write this code all of a sudden I would begin to get bothered by the fact I'm depending on the exact position in this list what the items were this is a very strong canasis of position a higher degree of canasis of position if I ran into that code I would probably convert it from an order list into a more structured type of thing a struct in Ruby or a class or if something, a hash at least where I had the names of the things and I didn't any longer convert it into an order this is a reduction from canasis of position to canasis of name if I were playing canasis of name it's probably a better and bigger form of cases so when the degree of canasis is too large if you want to reduce the form of canasis canasis to a bigger form of canasis so the degree max another example here suppose I had a defined method that took two parameters the condition and the field sort the results by again I wouldn't hesitate to do this in fact I understand that early versions of Rails would be exactly this but they're finding something very similar to this however when you start to get a lot of things in that parameter list that begins to get unwieldy if you're suffering from canasis of position parameter lists are bound by the order when you have a lot of things in your list that should be a good value personally one item to a Z and maybe three items I wouldn't think much about I start getting three to four items I start wondering is there a better way to do this this is another example of high degree of canasis I want to convert that to something else in this case in Rails what they did they converted it to canasis of name by introducing a hash and keys so we order no longer matters and you tie everything back to a name so now we've got canasis of name a couple of those are the names okay another example oh this one yes we were running tests in our test we needed an example in future so we just said user give me the first user in the test and it worked great when I ran and it worked great when I uploaded it to our integration server but when my body downloaded the coding we're just going to find this test failed actually it worked for a long time until we introduced roles into the user objects so certain users could use certain things and all of a sudden which particular user you've got don't matter and the ordering of users in my local database was different than the ordering of the users in Chris's database so we had a really strange canasis of position issues with data in our database the solution of that was to go to canasis of name to find the exact user you want to use that and find the random ordering of data in the database okay the other canasis we're doing a medical program where we give out medications they have a set of two checkboxes that are given not given or unchecked to indicate that we're kind of skipping this that there's no decision at this point and these values come back in a form like this where two is not given and one is not is given so the code that processes this has to actually check for those values if you were reading this code how did you know that's correct you'd have to go and compare both of them what we have is a canasis of meaning where two pieces of code have to agree upon the meaning of a piece of data solution again reduce the canasis of name where we introduce constants that have the values we write our code like this and now we've got canasis of name between three pieces of software but this is better than the canasis of meaning better than we have it before so another example of reducing the strength of your canasis this is another optimal so we've got met given and met not given and there's not a canasis between these two pieces of data if I change one the other doesn't have to change unless I change them to the same value this is called contra-nases because they don't change together they change separately they cannot go like a contra-nases turns out to be a very important thing Karen was talking about this X&O library earlier today everything's a node objects in your X&O that's usually in my X&O library in your bracket library you also have node objects we have a collision of names between my classes and your classes this is contra-nases this is a problem in Ruby the simple solution to this is nested inside a module now you still have contra-nases between the module names but there are fewer top-level modules and there are top-level classes so the probability of collision is much reduced so this is good library design put your stuff in namespaces you're not doing this shame on you I have someone complaining on the just this past week about rage because rage puts some things up in the top level and the next major version of rage is going to address some of those issues class node use all of the places in Ruby that each one is in its own main space so they don't collide however suppose you want to do something in old funky for some reason you want to be able to take any Ruby object and convert it to a node so you put a two-node method in the kernel it's funky, I know, let's just pretend for the moment and the guy doing the wrapping library wants to do the same thing now we have a canasus collision we're seeing the node name method names inside a single class there's no good solution for this other than to don't name your methods in kernel in the public classes that you monkey patch or don't monkey patch if you don't have to and if you really got to give them unique names that won't collide eventually Ruby might get selector namespaces that will address this issue but we don't have one yet, that's coming in Ruby to me they'll figure out how to do it eventually okay another canasus, suppose I have a checksum library and I have, I think, 3 digits and I add a check digit to it so I have this string and I add an 8 to it and that provides a check sum and I also have a check method that will return true or false and I can't even know whether the check digit is correct or not and the code for these things looks like this a really simple code but it's really an interesting fact these two methods do some different things but they are coupled by the algorithm used to calculate if I decide to switch from a simple sum of the digits and mod it by 10 algorithm to something more elaborate like XOR I have to change both places so changing the mod is changed by that there's no name canasus between it there's no position canasus there's no meaning there's no data in that word depending on what the meaning is for we call this canasus of algorithm because the algorithms have to agree into different places of code now one solution for this tends to be take that common code and put it into some library and now you've reduced this again to canasus of name because you're depending on the name of the method that identifies the algorithm you can't always do this sometimes you have canasus of algorithm between your Ruby library and that Java library over there that you're talking to over the web you have to agree on the protocol that's canasus of algorithm sometimes you can't pull this trick it's also known as draw so we see that hey this canasus idea is kind of feeding into these other principles that we already know about interest this is one here suppose you have an account object that credits the amount of the account and you create a whole bunch of threads and all of these threads probably are to that account what's going to happen crazy stuff let's walk through this this is not if you've never done this Reddit programming before this might surprise you if you've done threads you're really familiar with this okay so the number there by 23 is the amount in the account right now this is thread 1 and thread 2 there at the top is 123 a local register in the first thread and at that point in time you get time slice change and the other time slice run it also copies the 23 into its local storage the first I guess to run again it increments the stores back the second guy increments the stores back and the final result should be 25 because we've incremented it twice but instead it's 24 we've lost data a race condition between the two threads a race condition is kinases of timing where the timing of elements of your program will affect its outcome now the solution this is this particular problem is fairly straightforward you want to reorder the steps so steps 1 and 2 happen together and steps 3 and 4 happen together but if you do this by adding new taxes and synchronizing you'll solve that problem there's other threading issues that I'd love to talk to you about but really don't relate to kinases so I'm going to move on so I find kinases very interesting because when I look at that I begin to see all these elements of all these other principles coming into play we saw the dry principle of an issue of kinases algorithm we saw a lot of people are familiar with the law of divider essentially the law of divider says you shouldn't create a train wreck in your code in other words method dot method dot method it's a long train to a crash the reason for that is because every method call is another addition of kinases method to a building of a long train of kinases so that ties into the law of divider of the solid principles single responsibility principles if you get into the solid principles there's a lot of kinases based issues in that so I think kinases is kind of like the quarks in physics they're the building blocks that you start talking about kinases is very low level you're not going to build principles out of this kinases or that kinases but you can begin to look at them and base your principles upon understanding of kinases and by understanding these principles how software relates to other pieces of why when you change your piece of code I have to rewrite my library understanding that will help us to build better codes make better design decisions there's other kinds of kinases here I didn't have time to talk about we talked about most of the static ones kinases of height just means you have variables you have to work the integers that's so called the dynamic kinases is really interesting to be looking at we've got a couple of rules about kinases I think these are the beginnings of a unified software involved there right now I don't think it's going to cover everything I think there's other issues involved in this software development such as readability kinases doesn't really directly address but in terms of maintenance and changing codebase I think it's a very good start so how am I doing this time okay let's go ahead and take talk about to read on this topic this top is up on GitHub under my name there's more kinases and there's a PDF up there you can grab that and you want to check out these references the Milo page Jones book is there the Bob Martin book is up there so so questions yes what's the best way to teach this to new programmers or programmers switching to something new we're really disappointed there's not more talk about kinases in the general programming of public right in the 90's 12 years ago 13 years ago and why there's not more talk about it I'm really disappointed in that how to teach it to new people coming in I think you need to have an understanding of yourself then take on a mentorship an apprenticeship with other programmers bring them in and train them under a mentor like I said that first book I got from Gunford Myers was my mentor the guy that I was programming under my very first programming job came he laid the book on my desk and said Jim read this book so I think the idea is a software craftsmanship you got to take those and run those to teach the people I think that's the best way yeah would you say that the different types of kinases are different types of coupling? the question is yes essentially kinases is another name for coupling the problem with the term coupling is that everybody has a different idea of what it is and we don't have really firm definitions of it so H. Jones took kinases names and okay this is what kinases means so we've got a firmer understanding of these things that's why I kind of like her because kinases is really fun to say a lot of people came to me today and said what are you talking about? I'm going to talk about kinases today sounds deep are there any code analysis tools that you're aware of? good question Brian asks if there are any code analysis tools that will tell us about different kinds of kinases not that I don't wear I don't wear off there are some tools that we've always found methods some of the solid principles those are the first five we've said about 10 principles Bob Martin talks about and some of the later principles are couplings between larger pieces of code and there are some tools that do those kinds of methods good yeah that's good I was wondering like social kinases kinases are programmers the question is he's wondering if there repeat that if you think of his term as social kinases he says there's some kind of social kinases kinases are programmers that might explain readability I don't know kinases definitely means if I change this this has to change I'm not quite sure how to apply that to the readability issue so like I said I'm not there to brand theory of the whole thing different approaches like design patterns are all about trying to create the continuations of naming everything gets reduced down into that naming or that structure every problem is reduced to structures and that's kind of like a response to kind of like these things that this person is not like there's some kind of a link to that yeah so you're just saying there's some kind of way to design patterns these things down to the structure the idea of kinases all of the different ways in how to turn it into structure and all of that as well is just how you need to organize yeah design patterns are beginning to fall off at the very beginning of that main structure yeah actually about that long I encourage you guys to start thinking about and if I can get more people involved in thinking about how software is developed and how we can do it better then I achieve my goal thank you very much