Jeff Terrell: Okay, we'll get started here today. Hope everybody had a good long weekend, enjoy the beautiful weather if at least you're if you're still in the Chapel Hill area, uh,
Jeff Terrell: I just realized I have some background noise. Sorry. Give me just a sec.
Jeff Terrell: Yeah. So, today we will talk about architecture and Simplicity Simplicity, especially as regards choosing architecture.
Jeff Terrell: And why that's important. Alright so today.
Jeff Terrell: I picked stuck in the middle with you by Steelers wheel classic song from I think the early 70s.
Jeff Terrell: Because maybe that's how components feel as we'll see in a little bit.
Jeff Terrell: Other announcements grades are up to date. So I think there might be like one mentor report that I haven't accounted for yet. But other than that, we're, we're all up to date.
Jeff Terrell: And also, I got a question that I thought might be worth kind of sharing with everybody.
Jeff Terrell: Regarding like when is it too early to start coding, it's not, you can start coding. If you have started coding, you might be a little bit ahead on the assignments.
Jeff Terrell: Because, you know, it helps to make decisions together as a team about what languages and technologies you're going to be using for your app.
Jeff Terrell: before you actually start coding but also you could start coding in service to those choices by trying out some of these technologies and getting a feel for how they work and whether they might be a good one to pick for your
Jeff Terrell: Excuse me for your project. So in either those cases, it's not too soon to start coding. You're not behind. If you haven't, but if you're chomping at the bit to get started.
Jeff Terrell: On the actual code of the project, you can start jumping into that. Just be careful about what decisions you make. So that you don't have to undo your work later.
Jeff Terrell: Okay, I was going to also just kind of check in about where we are with the assignments in the semester. This week, you should either be finishing up your user stories here in the next day or two, or maybe you've already finished that depending on when you meet with your mentor.
Jeff Terrell: That was two coffee cups of difficulty. The clickable prototype is due next week and I was expecting that be would be about for coffee cups worth of difficulty.
Jeff Terrell: At this point, based in the content that we've covered in lectures, I would consider you to be equipped for assignment for or at least as equipped as you're going to be from lectures.
Jeff Terrell: The rest is up to you.
Jeff Terrell: Next week is assignment five, the first apples reflection. This is pretty easy. It's just like a one page essay. I don't need to equip you for that. It's actually pretty straightforward.
Jeff Terrell: But assignment six could be a little bit more more of a big deal, as well as assignment seven. They're both to the week after next
Jeff Terrell: Or, well maybe it's three weeks for now. Anyway, whatever the week after that is and four cups might be a little bit pessimistic for assignment six. I know some of you had already had a good handle on what what your technology decisions. We're going to be
Jeff Terrell: Which I think greatly informs your application architecture. We'll talk more about application architecture and the diagram today. That'll be what I am equipping you for today, as well as kind of what we talked about last lecture with evaluating technologies.
Jeff Terrell: But some of you have constraints choices for you anyway. So, so these. Some of you might definitely might not feel four cups worth of effort on a six.
Jeff Terrell: But then, yeah. After that, a couple weeks after a six and a seven or do we have the walking skeleton do assignment eight and that is the big one, five cups worth of difficulty. The only five cup one that I've
Jeff Terrell: That I have here and and that's a big deal, it'll take me several lectures to to feel like I have a quick you as best I can for that assignment, but we'll start talking about that next lecture.
Jeff Terrell: Any questions about assignments so far.
Jeff Terrell: Okay, here, all that is on the website as well.
Jeff Terrell: No question. I'll see any questions. Okay.
Jeff Terrell: Keep moving.
Jeff Terrell: Okay, so today in service to a six and a seven. I'm going to talk about architecture concepts and diagrams.
Jeff Terrell: We're going to give a brief example of architecture and architecture.
Jeff Terrell: For an app.
Jeff Terrell: We're going to talk about the virtue of simplicity and why that is an important thing to pay attention to when you are making choices about technology and then I'm going to save about 10 or 15 minutes at the end of class for quiz to hopefully 15 we'll see how I go
Jeff Terrell: Okay.
Jeff Terrell: Architecture concepts.
Jeff Terrell: Didn't have time to animate all these points so
Jeff Terrell: We'll just do what we can here.
Jeff Terrell: Architecture describes the structure of something. And in general, you know, when we're talking about this in the context of this course will be talking about the structure of your app or your program.
Jeff Terrell: That you're building as your project, but of course architecture applies to buildings, it applies to a variety of things. And so to talk about it in a fairly abstract and generic way.
Jeff Terrell: We could say that let me define a couple of terms that will help us define that. So first of all, first of all is the system. And that's basically the thing that we're talking about the structure of
Jeff Terrell: So when we talk about the architecture of something we call that something a system and the system is a complex combination of multiple things working together for each thing can affect the others.
Jeff Terrell: So you got multiple things happening, it's a complex combination these different things are working together.
Jeff Terrell: Okay. And actually, before I give some examples. I'm gonna jump down to the bottom point component is one of those things that's working with other components. And so that's the word that I would use to describe the parts of a system.
Jeff Terrell: And a component is necessarily interacting with at least one other component. Otherwise, it doesn't make any sense for it to be in the architecture or in the system. So that's kind of assumed. I mean, I suppose, as an artistic statement. Perhaps you could
Jeff Terrell: Have a stairwell that leads nowhere and doesn't interact with anything else but we're talking about software systems and hopefully you're not going to be doing silly things like that in your app.
Jeff Terrell: So a few examples of systems that maybe you can relate to the electrical system of a house. So this is a complex combination of a lot of different things working together.
Jeff Terrell: You know, you've got the input coming in from the outside the from the power line or whatever you've got the main breaker and the breaker panel for each of the individual breakers.
Jeff Terrell: You've got all the circuitry in the house. You've got the switches, you've got the plugs. You've got stuff that's plugged into the plugs sometimes plugs are complex with their own sort of
Jeff Terrell: fault system or breaker system that you can reset, like the ones in a kitchen or bathroom. Sometimes, or that way. So there's a lot of stuff going on.
Jeff Terrell: But it's all interconnected. It's all part of the same system.
Jeff Terrell: Notice, for example, how the lights dim when the air conditioner comes on, or maybe when you plug in the vacuum cleaner or something like that that has kind of a sudden Hi Dr electricity.
Jeff Terrell: That's because the lights are connected by virtue of being a part of the electrical system to the plugs and TO WHATEVER IS PLUGGED INTO THE plugs.
Jeff Terrell: So that's an example of a system. Another example would be plumbing and a house is a similar kind of thing.
Jeff Terrell: So maybe you are running the sink and washing the dishes and somebody else we're in the house flushes the toilet. You might notice the water pressure drop. And that's because this is all part of the system, everything's connected, everything's working together.
Jeff Terrell: In my house actually sometimes I'm on a well and so i don't i don't have an unlimited supply of water and sometimes we forget to turn the hose off its watering the garden and we noticed the water is not coming out of the tap in the kitchen.
Jeff Terrell: And we realized what happens, we've made. It's just take a number of times. And so we know we've we've left the hose on that's got to be what it is. But that'd be another example of these effects that can happen across the system.
Jeff Terrell: A really beautiful example of this is like a living organism. I think there's so much interesting stuff happening just in like the human body, for example, or really any living
Jeff Terrell: living organism. So many. You could even talk about. I mean, the people who study these things and call it like the circulatory system like that's a system unto itself.
Jeff Terrell: And then the body is like a system of systems all working together. And there's incredible complexity there. It's amazing to me that everything
Jeff Terrell: all works together. Obviously there are different kinds of flaws that can result as if one system isn't doing the right thing, cancer, for example, but um
Jeff Terrell: But it's amazing. It's amazing. All that happens in a body.
Jeff Terrell: So that's the key takeaways here for this I is that when we talk about architecture. We're talking about a system and its components and we're describing the structure of that system.
Jeff Terrell: Okay.
Jeff Terrell: Um,
Jeff Terrell: So when you talk about the system as a whole. There's some perhaps large set of responsibilities that the system needs to accomplish.
Jeff Terrell: And if we want to tame this complexity and get our heads around it. We need to start decomposing it. Our brains are relatively finite, we can only hold a few things that I had at once, and we need to start to
Jeff Terrell: Understand, at least a piece at a time in order to make progress on implementing the system and making it actually work. So decomposing the response responsibilities is an important part of managing and taming the complexity and just implementing the system.
Jeff Terrell: And so what we do is we divide that responsibility up into pieces and we assign some segment of the overall responsibility to a component and we say hey component A you're responsible for this, you know, in the electrical system example, the main breaker is responsible for
Jeff Terrell: Turning the power turning all the power off in the house disconnecting the entire house from the source of power, so that you can safely work on the circuitry or whatever else.
Jeff Terrell: You know, an individual plug has a responsibility or even just that kind of the class of plug in other words, that sort of abstract plug you have instance and stuff throughout your house has a responsibility it is to provide power to an appliance through a standard interface.
Jeff Terrell: Okay, so then the idea here is that taken together this set of responsibilities of the electrical system is pretty big. There's a lot of stuff that it needs to happen and electrical system. But we, in order to
Jeff Terrell: Break up the problem into smaller pieces we break up the responsibilities that each component is responsible for
Jeff Terrell: Now a particular component might depend on others to do its part. So, for example, the breaker is going to depend on the source, the power source coming in from outside the house.
Jeff Terrell: plugs are going to depend on the wiring inside the house, all the way from the plug to the breaker and and you know they we have these dependencies here.
Jeff Terrell: When it comes to software.
Jeff Terrell: Typically we don't decompose the components of the system along the lines of, like, a user story.
Jeff Terrell: But we have more of what you might call a cross cutting concerned with respect to features. So in other words, we don't have like component one is going to be for few feature one component to is going to be for future too.
Jeff Terrell: It's not really how it works. Usually it's more like will see an example of this later, but it's like, Okay, we have the database. The database is responsible for storing all the data and a persistent way that survives crashes and reboots and things like that.
Jeff Terrell: The database is going to be involved in a lot of features, maybe even all the features. So it's kind of a cross cutting concern that a lot of features depend on, but when it comes
Jeff Terrell: When you're thinking about the system that makes more sense to decompose things that way. So there's a bit of like art or skill or technique to decomposing a system into components.
Jeff Terrell: But here, kind of like what we saw in the design principles lecture, we can make use of existing patterns to make our jobs, a lot easier. We don't have to reinvent the wheel and come up with a de novo decomposition, just for our app.
Jeff Terrell: Each components responsibility can probably be further decomposed. And so you can talk about the responsibility of the system as decomposed into pieces and maybe one of those pieces is
Jeff Terrell: Handled by a particular component, then you can kind of zoom into that component and you can talk about the different responsibilities that that component needs handle
Jeff Terrell: And maybe you've got five different sub components that all contribute to that overall goal of the components responsibility.
Jeff Terrell: So there's kind of a fractal nature to this, you can kind of like zoom in and out and see similar things happening as we decompose. I'm not really going to talk about
Jeff Terrell: The sub components or anything at that level.
Jeff Terrell: I'm trying to keep this all at a high level, kind of at the architecture level, which is the highest level of the overall system.
Jeff Terrell: And once you have these responsibilities defined for each one of these components, you can start to see how these components, talk to each other and you can define an interface for each component to talk to its neighbor or neighbors.
Jeff Terrell: So the interface is basically a specification for exactly how the communication happens
Jeff Terrell: When the program or some component of the program. And in other words, some sort of code driven thing is the consumer of an interface. And one of the actors in an interface, then we call the interface and application programming interface or API.
Jeff Terrell: When the user is the thing that's consuming a an interface. We call that a user interface. And so these are the same kind of thing. They're both interfaces.
Jeff Terrell: But one of the in one case, the a program is consuming the interface and using it to get what it needs. And another case a human is using the interface to get what it needs what he or she needs.
Jeff Terrell: Okay, so then we might need to negotiate boundaries between components like we might say, for example,
Jeff Terrell: We have these two neighboring components and we need to figure out exactly where to draw the line between the two.
Jeff Terrell: There's some set of responsibility that the two components together need to accomplish, but
Jeff Terrell: We could move this this smaller responsibility over the line this way or that way. In other words, if you kind of move the line.
Jeff Terrell: Closer to component A or closer to component be or whatever. And there's a lot of, you know, you could draw squiggly line that kind of encompasses some things over here and some things over there.
Jeff Terrell: As a concrete example of this. Let's say that
Jeff Terrell: You have a backend and a front end they're talking to each other, front end is code that's running on maybe a user's browser and the back end is running on the server.
Jeff Terrell: And somewhere. What we want to do is take a set of fraud measurements and compute some basic statistics about them.
Jeff Terrell: Now, we could say that the back end is only responsible for sending the raw data to the front end and it's the front ends job to actually compute the statistics so that they the front end can display that them to the user.
Jeff Terrell: So that's one reasonable choice and other reasonable choice is that the back end could actually do all the statistical calculations and only serve up the the stats rather than the data.
Jeff Terrell: Depending on what you need to do either choice could be reasonable and you can you can kind of define, where that boundary is. But once you've defined a boundary
Jeff Terrell: Then you can start to define the interface and detail, including all of its details about how this is accomplished and once the interface is defined in sufficient detail, then both sides can actually actually be implemented in parallel.
Jeff Terrell: So if you have your API and your API says the stats are what's going to be conveyed from back into front end and in other words, it's the back ends responsibility to compute the statistics, then
Jeff Terrell: The front end can assume that those statistics are going to be received over the wire.
Jeff Terrell: And can start working on displaying those statistics to the user in some way that makes sense. Maybe according to the clickable prototype and in parallel. The back end can work on actually calculating the statistics and sending them over the wire.
Jeff Terrell: And both of those things can happen in parallel. So the step one is create the interfere define the interface and step two is the producer and consumer sides of the interface can work and can be implemented in parallel.
Jeff Terrell: And this is an example. Remember we talked about in programming in project management rather
Jeff Terrell: How it's helpful to have a lot of these these tales to find as much as possible in advance so that work can be done in parallel. This is an example of that. Pull the the work to the front or pull the specification to the front so that work can happen in parallel.
Jeff Terrell: Okay, so that was what I was going to cover for architecture concepts. A key ideas where
Jeff Terrell: The system is the thing that we're describing the architecture of the architecture is the structure of that system and the components constitute the system, the components are the pieces of the system. Each component has a segment or a slice of the responsibility.
Jeff Terrell: That that of the overall system and components connect to each other, relate to each other and talk to each other over these different interfaces that you might create. So any questions about architecture concepts.
Jeff Terrell: Okay.
Jeff Terrell: They'll see any raised hands or
Jeff Terrell: chat messages. Okay, so now let's talk about architecture diagrams.
Jeff Terrell: This will directly be in service to assignment seven
Jeff Terrell: I should mention, I need to take another look at assignment seven to make sure that
Jeff Terrell: What I've described there. I really haven't looked at that, since last year. And so I've understood a little bit better what I want from an architecture diagram. So if you've already started on this.
Jeff Terrell: Check back maybe after this week because I might change some things related to the assignment.
Jeff Terrell: But it's i mean the the bulk of its going to be the same. I just might add refine a few things tweak the wording, a little bit to try to make things more clear.
Jeff Terrell: Okay.
Jeff Terrell: But the following represents my current thoughts on architecture diagrams that this is this is kind of more current than what's in the right up. So this is potentially a little bit more reliable than what's in the right up
Jeff Terrell: Okay, well, you know, you've always heard the expression a picture's worth 1000 words. And that's kind of the idea behind the architecture diagram.
Jeff Terrell: You could describe the architecture of your system with words. And at some point, that might be useful to do but that should not be the only thing that you rely on to describe the architecture.
Jeff Terrell: The diagram is really a lot saves a lot of time.
Jeff Terrell: For people to understand what's happening at a high level.
Jeff Terrell: So this is visual documentation.
Jeff Terrell: This documents the composition of the system at a high level.
Jeff Terrell: So it answers questions like what components are there.
Jeff Terrell: What are the components of the system and what are, what is each one responsible for
Jeff Terrell: And which components actually talk to each other. It's not guarantee that every component is going to talk to every other component
Jeff Terrell: There probably will be system wide effects and there will be sort of indirect connections and effects between components, even if they're not directly connected but
Jeff Terrell: Not all components should be directly connected to all other components. If you do that, you might have to define order n squared interfaces, rather than something that could be a lot simpler.
Jeff Terrell: The target audience of the architecture diagram is there's a variety of people that will consume this and find it useful, your mentor is, of course, one of them your mentor and a lot of ways is the primary consumer of a lot of these assignments.
Jeff Terrell: Future developers that might join this project, even after you finish up for this semester.
Jeff Terrell: So,
Jeff Terrell: Keep that in mind that your project might live on beyond the semester. And you might continue to work on it after the semester or somebody else might take, take it over and extend it in various ways, potentially a
Jeff Terrell: Future.
Jeff Terrell: Compact 23 team. In fact,
Jeff Terrell: And I will also look at your architecture diagrams to get a sense of what what your project is
Jeff Terrell: In fact, I think your architecture diagram will be a good part of the good thing to include in the midterm presentations that are coming up in a month or two.
Jeff Terrell: So the rest of the class will also see these things.
Jeff Terrell: It can really help to include icons and or names of the technologies that you choose. And those choices would be justified in assignment six
Jeff Terrell: And these can concisely convey a lot of information. So somebody who's already familiar with a given technology can see that icon and say, oh, I have a really good sense of what this project is because I've used that technology before I'm familiar with it.
Jeff Terrell: You know, you might use the express framework and Node JS and because you use the express framework somebody who's already used, it is going to have a pretty good sense of how the back end works because they've already they're familiar with that framework.
Jeff Terrell: Don't go overboard on details.
Jeff Terrell: If you change something in your market in your architecture which you forget to update your diagram and your diagram becomes wrong that's potentially worse, at least in some ways than not having an architecture diagram at all.
Jeff Terrell: At that point, you have a diagram that's misleading and can be, you know, confusing to somebody who comes along and tries to understand the architecture of your system in the future and doesn't know about this change that you made.
Jeff Terrell: So the more details you have, the more maintenance effort, you'll need to expand to make sure that diagram is up to date and so yeah there's a bit of a balance there like include the high level stuff but don't don't go overboard on all the details.
Jeff Terrell: A good rule of thumb for your architecture diagram is if the system becomes unavailable or degraded by something be some component becoming unavailable.
Jeff Terrell: Then that component should appear in the diagram, there's a bit of a, you know, I've talked about components being the constituent parts of the system.
Jeff Terrell: That's not quite as black and white as perhaps that made a sound some things might be kind of
Jeff Terrell: Fuzzy or or a little bit gray about whether they should properly be considered a component or not. And so this is a good rule of thumb to help resolve some of those gray cases or it's not clear.
Jeff Terrell: And it's helpful to know where there's any redundancy or multiplicity. So one example would be, you're probably going to have multiple clients or users of your app.
Jeff Terrell: And so, in those cases, it's helpful to indicate there could be multiple of this type of component
Jeff Terrell: In an electrical system, there might be multiple plugs, there might be multiple switches, there'd be multiple individual breakers.
Jeff Terrell: Things like that. And so having an architecture diagram that indicates whether something is a singular thing or whether there's a multiplicity of things can help somebody understand the system better
Jeff Terrell: Again at a glance at a high level.
Jeff Terrell: Okay, question about
Jeff Terrell: architecture diagrams or what's useful to include there.
Jeff Terrell: That was all on a single slide. So I'll just put that back up for a second.
Jeff Terrell: No questions. Okay.
Jeff Terrell: Okay, so let's see. Next I'm gonna give an example of an architecture. And this is a pretty simple example. There's not a lot here, but just this gives you an idea of
Jeff Terrell: How to describe the architecture for a simple web app. Now, I haven't included icons on this and there are some changes that I would have made if I have had a little bit more time before class today, but this may be good. So the ideas across
Jeff Terrell: So you can see there's kind of three. I mean, we have five different bubbles here, but three of those are just an indication that we have three like there's a multiplicity of client. There's really three different kinds of components.
Jeff Terrell: One, we have clients, which is could be multiple and these would be browsers that might be running some front end code, but at least are displaying things to the user.
Jeff Terrell: We have the server, which is an always on back end program listening for requests.
Jeff Terrell: And we have the database that's storing data persistently and can survive reboot or a crash or power outage.
Jeff Terrell: But notice that if any one of these things breaks or becomes unavailable or stops working in some way, the whole system is affected, either the system becomes in the app becomes completely unusable or service degrees pretty severely
Jeff Terrell: You know, if a client's browser doesn't work. I'm not gonna be able to use the app at all if the server crashes and isn't available.
Jeff Terrell: Maybe you have done some sophisticated stuff to make your app semi available in that case, probably you haven't. But this is the idea behind a wave. Is that true
Jeff Terrell: I was going to say it's a progressive app, but that's that's a different kind of thing. And they're related concepts, but anyway. Now I'm just confusing myself.
Jeff Terrell: But at the very least, even if you've done some sophisticated things to make your app available even when the server is not available on the Internet is is out.
Jeff Terrell: Service is still going to be degraded in some way.
Jeff Terrell: And then finally, if the database is out, then yeah, you're going to have all kinds of problems and probably thinks they're going to break
Jeff Terrell: Also know the connections here the clients do not speak to the database directly
Jeff Terrell: That's a really key part of the architecture of the system. In fact, that's kind of the whole point of having a server is to be a gateway to the database that controls you know who's allowed to do what so questions of authentication and authorization
Jeff Terrell: And just sort of controlled access to the database. The database also has to always be on
Jeff Terrell: And you could theoretically if you trusted your clients, you could let them directly manipulate the database, but
Jeff Terrell: You shouldn't trust your clients if they're running on untrusted machines by untrusted people. So you should you should have a server have a back end to interface between the client code and the database.
Jeff Terrell: So it's a key part of the architecture that we don't have that those lines that go from from client three to the database.
Jeff Terrell: Also note that there's
Jeff Terrell: There's only two basic kinds of interface in this app. There's what you might call the API which exists between the server and the client.
Jeff Terrell: So it'd be an interface here that the clients would use to access data and to send data to the backend server. And there's also a database or an interface and maybe a set of functions that the server code can use to interact with the database. Since query data and add data.
Jeff Terrell: So,
Jeff Terrell: So that's an example of a, of an architecture of an app, specifically, this would be a web app.
Jeff Terrell: Any questions about anything related to architecture, including this example.
Jeff Terrell: Okay.
Jeff Terrell: Maybe I've put you to sleep by now. We'll see. But now it is time for a poll so you can stand up and stretch if you need to.
Jeff Terrell: If I put you to sleep. But anyway, let me activate this poll
Jeff Terrell: What I wanted to do is get a sense of
Jeff Terrell: Oh maybe I shouldn't do that. Okay, full screen.
Jeff Terrell: I make changes to that. Anyway, okay, let me know if you can't access this but polivy.com slash Jeff Terrell
Jeff Terrell: I'm trying to get a sense of
Jeff Terrell: How useful is going to be to talk about layout. Next time I'm planning on talking about layout.
Jeff Terrell: And
Jeff Terrell: I don't see any way of
Jeff Terrell: Telling. How many people I feel this out. So I'm going to look at that.
Jeff Terrell: Okay, and we're up to 50 results yeah 61 students in class. So that's most of you.
Jeff Terrell: 5354 56
Jeff Terrell: Okay, I'm going to move on.
Jeff Terrell: Feel free to finish typing and submit your answer. If you are still working on it.
Jeff Terrell: Okay.
Jeff Terrell: Next, I wanted to talk about the virtue of simplicity
Jeff Terrell: The reason for this is because I think this is one of the more important things to pay attention to when you're making decisions about which technology to use
Jeff Terrell: This can be a little difficult to assess sometimes, but I wanted to give you at least a few thoughts about why simplicity is important and how to choose technologies, based on simplicity, how to be recognized simplicity and
Jeff Terrell: And different technologies.
Jeff Terrell: I'm stealing a lot of this content from a talk that I really, really like by rich Hickey creator of closure, the closure programming language called simple made easy
Jeff Terrell: He's a really deep thinker and this is one of his better talks. So if you have some time. I think that's a fun watch
Jeff Terrell: The origin of the word simple is from the idea of having one fold or one braid.
Jeff Terrell: And so it's really about a unity of concept role or task.
Jeff Terrell: So something as simple when there's sort of a unity about it.
Jeff Terrell: Doesn't necessarily just mean one instance or one operation there could be a unity of concept or a unity of role or task, even if there is more than one instance or even if there's more than one thing that it can do.
Jeff Terrell: The key idea about simplicity is that there's a lack of interweaving of different concepts together when you have different concepts that are braided together.
Jeff Terrell: And sort of pushed in the same space to become part of the same tool that's when things get complex and simple.
Jeff Terrell: So it's not about a lack of cardinality. In other words, or lack of number. It's really about a lack of enter leaving of concepts.
Jeff Terrell: The opposite would be complex. And the idea of complexity is that this is multiple distinct concepts tied together.
Jeff Terrell: I use the word complex earlier and lecture to talk about systems.
Jeff Terrell: Systems are inherently complex because they have multiple components. Each doing their own thing and those components are tied together by being part of the same system was that would be a good example of something that is complex.
Jeff Terrell: Now remember from last time when we talked about evaluating technologies, I said that easy is a relative thing.
Jeff Terrell: That word origin for easy means something that's at hand, something that's relatively easy just to pick up because it's right nearby you
Jeff Terrell: And this is relative, because, you know, maybe some programming language is easy for you because you've spent the time to learn it.
Jeff Terrell: But it's not easy for a teammate because they haven't learned it yet. So easy as a relative thing simplicity is more about the inherent qualities of the thing itself. So it's more of an absolute thing that a relative thing.
Jeff Terrell: Now is simplicity as cut and dried as maybe I've made a sound know you can debate which things are simple and which things are complex and you can get into some fun philosophical debates about the nature of a thing and ontology and there's lots of fun to be had there.
Jeff Terrell: So there's a bit of perspective that can enter into those kinds of discussions and you might disagree about how simple something actually is. But the idea about simplicity is that it is inherent in the thing itself.
Jeff Terrell: And you might see that thing differently than somebody else but it's it's trying to talk about something that's inherent in the nature of a thing rather than something that is relative.
Jeff Terrell: Depending on where a person is positioned or what skills they have
Jeff Terrell: So its simplicity. So why is simplicity, a superior metric for or superior priority for choosing technologies and note, I'm not necessarily saying that it is the supreme priority.
Jeff Terrell: It's not necessarily the best thing. And the only thing that you should pay attention to, but it can be a really good thing to pay attention to, especially when you're thinking about long term health of a project.
Jeff Terrell: The first reason and really the fundamental reason is about understanding
Jeff Terrell: So it turns out there are studies that show that people eat an individual person can hold about seven things in their mind at a single time, give or take two
Jeff Terrell: And and I'd like to maybe understand this study a little bit better because I know, for example, if one of the things I'm trying to hold in my mind has to do with words.
Jeff Terrell: I can't really hold anything else in my mind that has to do with words. So I'm not quite sure how you would define a concept here, in this case, but
Jeff Terrell: This is what's studies show and complex things have multiple ideas and take up multiple slots in your attention if you only have seven total
Jeff Terrell: Then you have to be careful if you're trying to combine multiple concepts into a single complex idea you're filling up multiple of your very finite slots, just to told that thing in your head at one time.
Jeff Terrell: But if you have
Jeff Terrell: Things that aren't complex, they just take up one slot and so you can you can fill you can have more things that you're trying to use all at the same time if those things are simple.
Jeff Terrell: So the key idea here is that complexity undermines understanding
Jeff Terrell: And this is actually
Jeff Terrell: This is a really deep thing I'm stopping myself from going into a whole lot of detail here, but I could
Jeff Terrell: Describe at length why complexity undermines understanding and give you examples of why this is true.
Jeff Terrell: And we'll see some examples. A little bit later, but there's a lot of depth to this statement. And that's one of the reasons why I recommend that talk from a cheeky because it
Jeff Terrell: It's pretty illuminating. It helps you understand some of the things just, I don't know, it's pretty interesting. But I'm going to stop myself there and not not go too deep, deep here.
Jeff Terrell: Okay, so the second reason simplicity is superior is if you're debugging, and if you don't have to debug it all the semester.
Jeff Terrell: Then I'm sorry you had to read that book and you must be amazing, never to have to debug anything getting it right the first time.
Jeff Terrell: You know, more power to you, but at least for most of you, I expect that you'll need to engage in potentially a prolonged debugging exercise as you're trying to get your whole system working and trying to understand why it isn't.
Jeff Terrell: And then this is from hickeys talk as well what's true of every bug it past the type checker and the tests.
Jeff Terrell: So tests are not a panacea. Here the type checker is not a panacea, but understanding is what you really need, you know, your brain is the best debugging tool that you have at your disposal.
Jeff Terrell: You got to understand what's actually happening in order to solve the bug. And that's something that the the debugging book and really helps with gives you some practical tips for being able to tackle some of these thorny bugs.
Jeff Terrell: But complexity undermines your ability to debug it undermines your understanding of the system and how everything is connected together and therefore, it makes debugging harder. In fact,
Jeff Terrell: Debugging and understanding are related at the author of the book, I keep pointing over here like you know that my book is over there.
Jeff Terrell: The debugging book author, I believe that's the first rule is understand the system. So he recognizes that understanding is really essential to
Jeff Terrell: Any sort of involved debugging got to understand what it's actually doing.
Jeff Terrell: And let me, let me say one other thing about this. I didn't think to put in the slides.
Jeff Terrell: You're gonna have some complexity. Right. The system itself is complex and the debugging principles that we learned in the book.
Jeff Terrell: Help us do a debug complex things. And so it's not it's not the case that you can just choose the simple thing every time and then Debugging is going to be easy.
Jeff Terrell: Now you're going to have complexity because you're dealing with systems of related components that are all working together to do with the system needs to do.
Jeff Terrell: So we are going to be dealing with complexity. But the point here is that if you are composing simple tools together.
Jeff Terrell: Then it's a lot easier to understand a system even, even though the system is complex because it's it's a composition of multiple simple pieces.
Jeff Terrell: It's a lot easier to understand a system composed of simple components than it is to understand a system composed of complex components. So I think I didn't make that point very well, but that's the point I'm trying to make
Jeff Terrell: So this is all pretty abstract. Let's talk about some concrete examples.
Jeff Terrell: This is a simple tool.
Jeff Terrell: There's a unity of purpose about this tool. It's a handsaw right it's for cut cutting wood.
Jeff Terrell: And it does that job. And that's all it does. It does that job well.
Jeff Terrell: So maybe you're starting to get a sense of what I mean by unity of purpose and why I would call this simple. One of the things about simple tools is that, you know, when you need them. Right. And if assuming you knew what a handsaw was and what it's used for
Jeff Terrell: If you needed to cut wood and you're in your garage looking for a tool to use. You wouldn't even have to think about it, you would just think I need to find the saw. This is the tool to use for this job. And so having
Jeff Terrell: That understanding
Jeff Terrell: Sorry, let me let me back up a step. Having tools that are simple, make it a lot easier for you to understand and remember, when do I need to care about this. When do I need to use this tool.
Jeff Terrell: Another example would be a hammer.
Jeff Terrell: And I say a simple tool, mostly. Why did. Why do I say mostly
Jeff Terrell: Well, there's actually a combination of two tools.
Jeff Terrell: Right, the hammer the front side of the hammer is for driving nails into wood, but there's also the backside, which is the claw side which is for taking nails out of wood.
Jeff Terrell: Now those are very related concepts and so I wouldn't argue if somebody said this was simple, because there's still a unity of purpose here even though you can both drive nails in and take nails out with this tool.
Jeff Terrell: But this is a pretty simple tool. And I know when I need a hammer.
Jeff Terrell: If you have any idea what a hammer is, you know, when you need a hammer and it doesn't it doesn't take any significant thought to remember that you just kind of know it. And this is what simple tools afford is that we know when we need to reach for them. And we know when we need to.
Jeff Terrell: To use them.
Jeff Terrell: Here's a complex tool.
Jeff Terrell: I believe this is called the you grow it.
Jeff Terrell: Product or system or something. I think it's related to actually didn't really look at this very, very much. But I think it's related to growing plants and it's got some sophisticated stuff on it to
Jeff Terrell: Help you grow plants somehow maybe some sensors and things. But there's a lot to this right you can see how this is complex.
Jeff Terrell: And maybe there's a unity of purpose. Maybe this is all serving a single purpose, but there's a lot of different moving pieces here and I would say that this is complex.
Jeff Terrell: Now, does that mean it's not useful know it might be a great tool for the job that is trying to accomplish.
Jeff Terrell: Just like the system of your app that you're building might be an excellent tool for your clients to use
Jeff Terrell: So just because it's complex doesn't mean it's bad. But the point that I'm trying to make here is that when you're choosing technologies.
Jeff Terrell: You should think about whether the technology you're choosing as simple or complex and you might lean towards simple tools over complex ones if you know all else being equal,
Jeff Terrell: Okay, another complex tool.
Jeff Terrell: Is the farm bot open source CNC farming tool.
Jeff Terrell: So this is a computer controlled
Jeff Terrell: Thing for for doing farming, you can you can write code to water your plants in a certain pattern with a certain amount of water per square inch and
Jeff Terrell: Probably, there are other things that you can hook up to this thing.
Jeff Terrell: That's a complex thing. There's a lot of stuff going on, maybe even have an app for
Jeff Terrell: running your, your farm bot. So there's software involved. There's hardware involved. There's the frame. There's the soil. There's the plants. There's the water. Lots of stuff going on.
Jeff Terrell: Again might be a really cool, really useful tool that you wouldn't want to recreate with simple components, but just noticed that this is complex.
Jeff Terrell: Here's an example of a simple compostable tool.
Jeff Terrell: Right, I would call this simple, even though there are multiple different heads that you could put on a screwdriver
Jeff Terrell: I would say this as simple I know when I need this thing right and I can figure out which had I need by looking at the screw.
Jeff Terrell: That I'm trying to screw in are screwed unscrew but
Jeff Terrell: But I know when I need this right. It's a very simple thing for me to understand
Jeff Terrell: I need a screwdriver. I'm gonna go find my screwdriver
Jeff Terrell: And it's also it's pleasantly compostable because it has these different heads and you can take one out, put a different one in, and then you can use your the same tool to
Jeff Terrell: Work with a different kind of screw.
Jeff Terrell: So the composition is really easy to understand, too, which is nice.
Jeff Terrell: All right. I've been hammering this point home, but the simple physical tools that I've been describing a saw a hammer or screwdriver. They have a unity of purpose and of mechanism. There's not multiple things happening here.
Jeff Terrell: They, they have a single purpose. They have a single mechanism you understand them and you understand them deeply you understand when and how to use them.
Jeff Terrell: Maybe you need to develop skill I using them. And it's not easy to drive a nail into wood with a hammer without missing the hammer unless you have practiced it but you understand it, you understand the concept of it. You understand when to use it.
Jeff Terrell: Alright, so, Nathan added a link for Sarah from Joel on Software.
Jeff Terrell: Classic blog.
Jeff Terrell: For complex physical tools, though, you must read the manual alright you hope nothing goes wrong because debugging require some understanding of the entire system and
Jeff Terrell: That can be challenging depending on how complex the system is, you're probably also not going to try to compose a complex tool with anything else.
Jeff Terrell: So here's an example of something that I think I would call complex riding lawnmower. In fact, zero turn riding lawnmower. This is a lot like the running lawn mower that I had up until this past summer, and I got so tired of fixing it.
Jeff Terrell: But you know this thing. I mean, it wasn't really the most fault but
Jeff Terrell: We just have some some rough ground and this thing would break for me a lot. And it was incredibly frustrating because especially when I started out, I didn't know anything about how this worked
Jeff Terrell: And I could kind of see as I got under it and looked at it and stuff. I mean, it had a fairly relative lead to like a modern car with a bunch of computers everywhere.
Jeff Terrell: I could kind of see what was going on. Even though the engines, kind of a black box and whatever I can see that there's a belt that's driving these poles. It's making the blade span underneath the deck.
Jeff Terrell: So I can kind of see pieces of it. But, um, but I had to go and like really work on understanding the system in order to understand, Okay, what broke this time apart, do I need, how do I get that part out and put a new one in. Oh my goodness.
Jeff Terrell: Okay.
Jeff Terrell: So, so yeah debugging these kinds of things. It's not fun.
Jeff Terrell: Okay, here's a case study Ruby on Rails.
Jeff Terrell: This I first heard about Ruby on Rails. This is a framework for creating web back ends.
Jeff Terrell: And it really is intended to be easy, people love it. In fact, I saw this for the first time, maybe like oh six I saw it in an apartment. When I was a grad.
Jeff Terrell: Grad student
Jeff Terrell: And it was like, wow, you can build a web back in that quickly and easily. That's amazing.
Jeff Terrell: And so people really do love it. It's a great tool. Other things that come along since then, like, Django in Python that are pretty similar and inspired by Ruby on Rails, but this was kind of the first big framework that made a lot of this stuff easy
Jeff Terrell: I've used this extensively. I got I've gotten consulting work for many years from knowing rails.
Jeff Terrell: Not so much anymore but
Jeff Terrell: And then once you once you know it you can develop a web back end pretty rapidly. So you got to know how it works and everything, how to use it. But once you know it you can be fast.
Jeff Terrell: But Ricky gives kind of a relevant warning here, emphasizing ease gives early speed. But ignoring complexity will slow you down over the long haul.
Jeff Terrell: Alright. So Rails, I would say has definitely emphasized ease and they
Jeff Terrell: They have a bunch of people who love their software because of that. So, that ain't nothing
Jeff Terrell: But if we ignore complexity. We can slow down over the long haul. Once we've gotten into the system a little bit
Jeff Terrell: And that's exactly what I found with Rails is once you got into it farther and these are my my opinions, different people are going to disagree with me but
Jeff Terrell: For one thing, there's a lot to know. All right. They have this
Jeff Terrell: Value that they like that. They say convention over configuration. And that was a reaction to a lot of things that required a lot of heavy configuration to get to the web back end working in some other system.
Jeff Terrell: And rail says I don't worry about configuration. There's just consume conventions and we'll, we'll kind of do the expected thing for you automatically. And you don't need to configure anything
Jeff Terrell: The problem is that there's a lot of conventions and you have to know a lot of these before you can really be productive in Rails.
Jeff Terrell: So, for example, the MVC paradigm and knowing that you know app models is going to be where all of your models live and a model is what talks to the database. And there's an RM and there's, you know, there's a lot of different things you have to know about this.
Jeff Terrell: And even when it's productive it's, it can be hard to know how different things fit together.
Jeff Terrell: So it can be difficult to extend things in new directions. If you start to kind of go against the grain and Rails or do something that's a little bit unconventional, it could be really hard.
Jeff Terrell: You have to dig deep into Rails to understand all that it's doing
Jeff Terrell: So the ugly side of Rails, I would say is when you have to upgrade an app that you've already created to a new version of Rails that came out.
Jeff Terrell: And you will have to at some point. Otherwise, your, your app is going to be vulnerable to security threats.
Jeff Terrell: And this is where what Richard, he says is really true ignoring complexity will slow you down over the long haul, because now you have to stop and read all the release notes and understand what kinds of things you need to change in your code in order to upgrade to new version of Rails.
Jeff Terrell: We have to do that, you're not adding value to anything. When you do that, you're just running on the technological treadmill, trying to keep pace.
Jeff Terrell: You could be working on features, but instead you have to go read rails release notes and follow all of their instructions for how to upgrade.
Jeff Terrell: And you might break a lot of things when you're trying to upgrade your app. So I hope you have a test suite.
Jeff Terrell: This can get into some tricky conversations with clients, you're like, I really do need to do this and they're like why I don't understand. You're trying to explain
Jeff Terrell: Rails comes out with new versions. I have to upgrade that it's like what value does this bring to me. It's complicated. I don't know. So there can be kind of some dicey conversations that you can get into there as well.
Jeff Terrell: Okay.
Jeff Terrell: got a few minutes left, so I'm gonna I'm gonna start out and explain a little bit
Jeff Terrell: Um, any questions so far.
Jeff Terrell: All of this is intended to be talking about why simplicity is something they should pay attention to.
Jeff Terrell: For example, in a six assignment six when you're describing your application architecture and justifying the decisions you made for your
Jeff Terrell: Technology choices. So if you're describing, you know, if you made a choice based on simplicity and hopefully that's a good choice that you don't regret, but that would be a good justification for why you and your team decided to pick one technology over another.
Jeff Terrell: Don't see any questions. So I'm going to keep moving. Alright framer frameworks versus libraries rails, by the way, is an example of a framework which is code that somebody else wrote that invokes your code in certain ways.
Jeff Terrell: And you have to not just understand the code that you're writing, but you have to extend your understanding to include at least a little bit about the framework to understand how that framework is going to be calling your code so that you can conform to its expectations.
Jeff Terrell: There's lots of examples of frameworks rails and Django. I mentioned already Angular JS Ember JS flutter React Native Android Java spring, etc.
Jeff Terrell: You, you might have a hard time trying to create an app that doesn't use frameworks at all.
Jeff Terrell: Frameworks. By the way, are related to architecture architecture, remember, is the structure of your application at a high level structure of your system at a high level, and a framework is almost like a alluding to, just in the in the word itself. It's alluding to structure talking about
Jeff Terrell: Maybe the trellis that the vine climbs or something like that. But it's the framework is designed to give structure. And so a lot of times when you're using a framework.
Jeff Terrell: A lot of choices about architecture have been decided for you and all you're doing is plugging into these predefined places to use their architecture and let the framework call you to get the job done so.
Jeff Terrell: I'm a library. On the other hand, is code that somebody else wrote that you invoke to help you with some aspect of your program.
Jeff Terrell: So a framework calls your code. But you call a libraries code.
Jeff Terrell: So an example would be a great canvas to let you draw lines and points. Maybe you you're making a game of some sort and you have a canvas that you want to draw things on and you use a library to draw those lines and points and style them in different ways and things like that.
Jeff Terrell: Or maybe you use a library to play occasional sound effects.
Jeff Terrell: Yeah, you probably could understand some low level API that you could use to actually create sound. You could manipulate waveforms yourself with Fourier transforms and blah, blah, blah. But somebody do that work for you.
Jeff Terrell: And you can just use that work and use these higher level API's to get your job done more easily.
Jeff Terrell: So let's talk about kind of frameworks versus libraries and why you might pick one over the other.
Jeff Terrell: Frameworks tend to be a little bit difficult to understand.
Jeff Terrell: They are, they do encompass architectural decisions. Most of the time, at least at some level. And so therefore, you're probably dealing with something that's somewhat complex
Jeff Terrell: And for that reason, it can be difficult to understand. And you have to understand it, at least at some level, because you have to understand what rules you need to follow for your code to make it work with the framework and conform to the frameworks expectations and requirements.
Jeff Terrell: Sometimes you can get started relatively easily if you just understand the rules, but not anything behind them. The rules that a framework it poses on your, your code.
Jeff Terrell: You can get started. Sometimes that's something that can be really easy because a lot of these architectural decisions have been made for you.
Jeff Terrell: But then if you need to debug something like it's not working. And I don't know why. Maybe you need to start to appear behind the curtain, a little bit to understand how the architecture of the framework is forming what's happening.
Jeff Terrell: So that can be difficult. Or maybe you need to extend the framework to make it do something that maybe wasn't specifically decided specifically designed to do. So that can be challenging.
Jeff Terrell: On the other hand, a library. If it is sing like has a unity of purpose about it. It's like a physical tool like we saw before, like a hammer or a saw. You know what it's for. And you know when to use it.
Jeff Terrell: So that sound generation library that I this hypothetical library. I talked about
Jeff Terrell: You know when you need it and maybe you need to go learn a little bit about how to use it. But you know what it's there for. And you know that you know what you can accomplish with it. And that doesn't require a lot of work to understand
Jeff Terrell: You might need to be responsible for architectural decisions if you tend to more towards libraries and frameworks, but you might have a better understanding of the entire system because
Jeff Terrell: You are in control of how things are connected together and you are composing these simple pieces into the system.
Jeff Terrell: So frameworks are more like starting a new job. You've got to figure out what's expected of you. And although you might function. Okay. On day one really getting it takes time.
Jeff Terrell: Okay, I've got some more stuff on dependencies that I think will be worth talking about like next time.
Jeff Terrell: But for now, let's go to quiz one. So one thing I forgot to mention about quizzes last time is that you can use.
Jeff Terrell: Like slides and stuff online for or even the debugging book to answer the questions on the quiz. Sorry, I forgot to mention that last time.
Jeff Terrell: You cannot, as I said in the syllabus day first day of class, you cannot collaborate with other people on these questions.
Jeff Terrell: So don't be sharing questions. Don't be sharing answers. Don't be chatting at all with anybody, while you're taking this quiz. I hope
Jeff Terrell: That like I've been aiming for that this is a good check that you're actually paying attention in class, but not anything that you need to study for if you feel like you can't
Jeff Terrell: Get a good grade on this without studying for it, let me know. That'd be good feedback for me.
Jeff Terrell: Right, I'm gonna
Jeff Terrell: Start this quiz. I'm gonna, I'm gonna go ahead and stop recording in just a second.
Jeff Terrell: I will be around for questions as they come up. If you have like a clarifying question on any of these questions on the exam or the quiz rather
Jeff Terrell: Send me a message, maybe privately or
Jeff Terrell: Yeah, maybe privately and if there's something that I want to share with the whole class. I'll do so on this zoom meeting in the main chat channel here. So you might keep an eye on the chat while we take this, but some
Jeff Terrell: Just be careful that you're not sharing information with other students.
Jeff Terrell: Through the chat and I'm going to stop recording, but I'll be around to look at questions and things like that.
Jeff Terrell: stop sharing stop recording