[MUSIC] Software engineering is really kind of a misleading term, because it gives us the impression that building software is something that is sort of formulated, can be engineered from a set of principles. And that given an arbitrary problem, we can come up with a solution for it. A lot of times people try to use the analogy of building buildings for software engineering. That doesn't really capture the complexity and really the creativity and artistic nature of software engineering. It's much less of a known thing than we think it is. So a more apt description that gets used for software engineering often is that it's a creative process. That we get people together, and they use their creative ideas to come up with ways of solving a particular problem. Building software that can help us do things that we need to, be it building software for our car, or building software to help us keep in touch with our friends, like Facebook. But I still think that there's some things that are missing when we just think of software engineering as a creative process and we leave it at that. I like to have a slightly different analogy. Because I think there's one aspect that when we just say it's a creative process that we don't emphasize enough, and that is the aspect of measurement. So when I think of software engineering or creating software, I like to think of creating software as a search process. We start off with a clean slate, or maybe we don't have a clean slate, maybe we have some initial solution that somebody else created that we are starting from. But at any rate, we have some problem we're trying to solve and we're searching for a solution to that problem. We're searching of ways to write software, to produce the correct instructions and configuration that will solve that problem in a meaningful way that satisfies our users, satisfies our time constraints, satisfies all kinds of pressures that the software development team may be under. So why does thinking of software engineering as a search process change the meaning to some degree? Well, I like to think about it like the hot and cold game. So let's say that we're in a room and you're standing right here. And somewhere in the room your friend has hidden your car keys, or maybe your cell phone, or maybe your laptop, something. And you desperately want to find this thing that's been hidden. So if you've ever played the hot and cold game, basically you are standing somewhere in the room, you go and you move a little bit to a different location. And then you ask your friend, did I get closer or farther away? And they say, well, you're getting hotter or you're getting colder. When you're getting hotter you're getting closer to the solution and when you're getting colder you're getting farther away. And software engineering in many respects resembles this process. We go and we build some initial software. We show it to the user, or we test it under some circumstances. We see what the result is, and then we plan a way that we're going to improve it, or modify it. And so we go and move again. And then maybe we move again. And we modify the software some more. And we keep being told, you're getting hotter. And then we move a little bit more, and we're told, well you're getting colder. So our colder might be we're failing tests or our users are unhappy with the design. And eventually after we bump around enough times, we may arrive at a solution that is considered a success. Or we may just bump around for a long time and waste a lot of money in the process and a lot of time and never satisfy the constraints that we're looking for. But this idea, the hot and cold game, it's really a lot like what we seen in software engineering, a search for something. We don't know the exact place that that solution lies, but we have an idea of where it is and we are heading towards it. And as we head towards it, we build something, we test it, we test it with users, we performance test it. We do all kinds of tests and evaluations of that solution to see if we're getting closer to where we want to be. And this why I think it's a good analogy to use search and searching for something as what software engineering is very similar to. Now the big thing that I think is important about this process is, and particularly thinking about it in terms of the hot and cold game, is with software we're going in and we're trying something. And then we're measuring. So I think this is one of the most important things is that we're going to go and build or change something. We're going to build something new or we're going to change some aspect of the software. And then once we've done that, we're going to go and measure and evaluate where we are. And see if we've gotten better or if we've gotten worse in the process. And then eventually, we have some termination criteria where we stop. So we basically do one and two until we've decided that what we've got is good enough for some point in time. Because many times if we're building software and it's really useful, we're going to repeat one and two. We're going to launch that software. And then we're going to keep repeating one and two for a long period of time. That is the maintenance of that software. But the really important piece that we miss when we think of software engineering, it's just a creative process, which it absolutely is. And I come from an art background, so I think of software as an extremely creative process, just like painting or anything else. But I think an important aspect of software engineering as opposed to software development and the art of software development, is that in software engineering a very important piece of that. Well, this is an important piece of software development in general, too. But this is a really critical piece in software engineering, is that we do things, we make changes and then we measure them. And then based on the outcomes that we see, the measurements, then we make a decision as to what to do next. And this is a fundamental piece. Of course, we're going to build and change things in order to create a piece of software. But not only are we going to build it and not only are we going to change things over time, but we need to measure those things as we go. And some people may say well, I don't measure software when I build it. But the truth is, is you always measure software when you do it. Even if your measurement is you build it and you hand it off to the intended user and see what happens. That's still a point of measurement. Now it's maybe not the best way to do it, if we hand it off to them without ever testing anything, but it's certainly a type of measurement. And so when we think about software engineering and we build a mental model, we really need to think of things in terms of how do we build and change things over time? And how do we measure the effect of the changes that we're making as we make them?
