OK, so my title of my talk, which you'll see any moment now, software development in the 21st century, is a completely meaningless title. It's a title I give to all of my talks that I give wherever I go because it's a nicely vague phrase and I can actually talk about whatever I like in the course of a talk. And in fact, I'm not actually going to give you one talk. I'm going to break it down into separate talks because I think that rather than listening to one long boring talk, you can listen instead to free short boring talks instead. And meanwhile, we're having some projector problems. I've got something. It's up. We're in action. OK, so instead of one long boring talk with a long period of fiddling around with the thing at the beginning, I'm going to give you free short boring talks. The first of which is about agile in general. A talk I call Essence and Fluency. And I give this talk because agile's in a kind of a curious state in many ways at the moment. When we started with agile back all those years ago, we were very much working against the tide. I remember in the early days, in the early zeros, when we were working at Fortworks on agile projects, we had to be very wary about mentioning we were using these weird agile techniques. Clients would come to us and say, we really like how you do your software development process. But you're not doing any of that agile stuff, are you? But now, of course, agile is suddenly very mainstream. Big companies who poo-pooed a lot of the agile stuff 10 years ago are now coming out with their great agile programs and agile methodologies and certifications. You know you're in a bad state when certifications are dominating the landscape. So I think it's important to remind ourselves what is the essence of agile software development. And to do that, we need to go back to where we were when all this started, which was back in the 1990s, where we saw lots of projects that had a great deal of problems. And the problems to some extent, and well to a large extent, are still there in the industry. I think they've been attenuated a good bit, particularly by effective teams, but they were very much in people's minds in the 90s. And at that time, people also felt they knew what the answer was V. They knew what the cure needed to be for these kinds of problems. And that was the big plan-driven processes.  That was seen as the professional way to develop software. We're not only wanting anybody not doing this stuff because they're clearly cowboys, incompetent, et cetera, et cetera. That was seen as a future. That was the world as it was seen in the 90s. But then you get this unusual bunch of people who got together and said, we have a different approach. We've been building software, we've had a good deal of success, and we've done it with a very strikingly different attitude to how we do this. To me, the important thing about the agile movement and the successor to agile manifesto, it's not that I want to see agile methods dominating the world and everybody doing everything agile. What I want to see is those teams that want to work in an agile fashion should be able to do so. And not seen as some kind of unprofessional people just because they work in a different way. So in many ways, agile has had a bigger impact than certainly I was hoping or expecting. But at the heart of what this shift is, this difference between the plan-driven approach and the agile approach, I think are a couple of very simple core ideas. And these are ideas that I sort of worked through in my own mind when I was writing an essay that I called The New Methodology. Still out there on my website, still a very popular essay, and I wrote it because I was very much steeped in one of these agile approaches, although it wasn't called agile at the time, and that was extreme programming. I worked with Kent Beck and Ron Jeffries, I wanted the very first, well, I put the birth extreme programming project, and I really liked what it was done. And I looked around and I saw Alastair Coburn was saying, I saw what the scrum people were saying, and I thought, there's a lot of similarities. There's something very much in common between extreme programming and these other approaches. What do those boil down to? And I thought to myself, well, what we're seeing is a contrast between these new methodologies, the ones that would become called agile, and the traditional approach that everybody said was the way of the future, which was the plan-driven approaches. And I boiled down to a different attitude towards planning and a different attitude towards the relationship of people and process. And to me, these two differences are the essence of agile thinking. And I'll go into a little bit of detail on each one, starting with the planning approach. If we look at the traditional approach to planning, it's seen as something you do before execution. You wanna work things through, come up with a detailed plan, and then execute on that plan. The model is often taken from traditional engineering, particularly things like civil engineering. You wanna build a building or build a road, you first have the engineering people come up with great detail, exactly how the building is to fit together, do all the figuring out of the structure and all the rest of it, and figure out how the building should be built, what pieces should be built in what order, and then you take that plan and you hand it over to a construction company, but actually does the work of building it. That is the model of the plan-driven approach to planning. Plan first, then execute. I think of this as a predictive planning approach, because what you're doing in the plan is you're coming up with your prediction of how things are gonna go in the execution phase. And that is also a crucial factor in judging success, because if you're successful, then things go according to plan. In fact, the whole notion, whenever you hear people saying, oh yes, our project was a success, it was on time and on budget, what that's saying is they're thinking of a predictive planning mindset, a mindset that says, success is things went according to plan. In an agile context, that actually doesn't make much sense, as we'll see. Now, this engineering approach was very appealing to people because of the fact that they saw all the problems with software development, and they felt this is how we become professional, this is how we become organized.  You have to have a good set, well understood, stable requirements, because otherwise, your plan is built on sand. And that of course means that because the plan is such a central part of your software development approach, it means your entire software development notion depends on having stable requirements. At this point, I have to ask you a question to see if you've actually woken up yet this morning. How many people on their last project that they did saw significant changes in the requirements for that project? Exactly, a large amount of people. We have to question, can we actually get stable requirements? And to be fair, the plan driven people understand this and they talk about the dangers of requirements churn. And they said, we have to come up with stabilization techniques, but we can use to try and prevent that churn. We want to prevent that change. We have to stabilize the requirements. I remember someone saying, if your requirements churn by more than 15%, you're doomed. There's no way that you can be successful in software development.  Now, the agile thinking looks at this combination and says, hang on, what happens when we in software have a really awkward dependency? What do we need to do? We need to get rid of that dependency. And so what we do instead is we come up with a process that's tolerant to changes in requirements. And that's the essence of things like, for instance, taking iterations and building things in small pieces, looking for feedback, actually expecting that requirements will change and giving us a way to handle that in a controlled manner. That's the central attitude, the little shift in planning with the agile thinking. And it goes even further. I'd summed up really well in this phrase by Mary Poppendick. Change, like changes, are actually a good thing. It allows us to do things more quickly than our competitors do. We actually not just respond comfortably to changes, we actually expect them and we take advantage of them. And that's an important mind shift that is an underpinning one to agile thinking. So that's a shift from adaptive planning to some predictive planning to adaptive planning. It says, we don't register success on the basis of things going according to plan. We look at other measures, such as have we made a positive impact on the business or things of that kind? Because in the end, if you things haven't gone according to plan, that could just mean your plan's wrong, right?  There are plenty of projects that went according to plan but still didn't yield any business benefits. Now, the other part of this, you have a shift, is that of the shift to, in the way between people and process. And if we look at where the attitude to process in the traditional world begins, it really begins with this guy. Anybody recognize him? Yeah, there's always some Agilists who do. This is one of the most influential thinkers, men who's had the biggest influence upon human society in the 20th century. His guys, the name's Frederick Taylor, he was involved in America, involved in manufacturing, and he is the one who came up with this lovely little phrase. He looked around and he saw what was going on and he said, at the moment, the problem with manufacturing in the late 19th century was that the workers were deciding how they should do their work.  And instead what you needed to have was professional planners who came up with a system and then the workers would follow that system. It's an approach called scientific management and it underpins a great deal of industrial and administrative processes that you see in the world in the 20th century and indeed through to today. His influence has been enormous, much greater than sort of famous politicians or general's or things of that kind. He's had a huge impact on the way we work. And he had this impact on software development as well. So when people talked about how should we do this professional software development stuff, they would do it by typically coming up with some process of various activities that need to be done in certain order with various deliverables that are handed off from process to process. Now you look at any of these process things and the sure sign of this kind of thinking is we have this process diagram. And then if you want to use that process in practice, you look around at the people that you've got and you say, well, I have a bunch of people here. I have five programmers, three testers, two analysts and a project manager in a pear tree. And I take these people and I look at my process and I just slot them in. And that's how I go about planning out how we take people through this route. The process is first. Now, of course, I have seen some people do talk about agile processes this way. Say, hi, we have an agile process. Here's the various steps and the arrows and the diagrams connecting them. You know that somebody doesn't get agile when they show you that kind of thing, right? Because when you have some clever little diagram like that, you're missing the point. Anything that talks about steps and deliverables and stuff. I mean, that's off the thinking because what the thinking behind agile is about is to say, well, actually, the people that develop software, they're not lazy, venal, 19th century manufacturing workers toiling in factories. They're actually programmers, analysts, user experience people, but they're actually pretty intelligent because I mean, they wouldn't be doing this if they weren't pretty intelligent. And they need to come up with their own process. So we reject the idea that put the process together first. And we say, no, it's most important that the team of people themselves decide what process they follow. Now, it may be that they'll go out for inspiration to the processes and things that have been published. They might look at extreme programming or Scrum or something like that and say, oh, that's some good ideas. They might even, and it's often, can be a good thing to say, we're actually gonna do extreme programming by the book at the beginning just to learn how it works and to get a feel of how it operates. But very rapidly, they should start kicking in and saying, well, this isn't quite working for us. Let's try that and see how this works. And the process evolves over time. And the people in the team direct that. They choose how they wanna work and they choose how they're gonna move forwards. And the important corollary to this, of course, is if you've got a team of people who don't want to work in an agile fashion, it's pointless to try and impose it on top of them. The team has to decide they want to work in that way. I mean, if there are, can be external pressures that will kind of push you in that direction. For instance, the increasing desire to have regular delivery of software into production tends to push you this way. But in the end, it has to be the team's choice how they work. And this really boils down to the observation made by all of us in the agile community that when we saw the difference between successful projects and unsuccessful projects, it had nothing to do with a process drawn on a board. It all had to do with how good were the people on the team and how well did they work together in a human level? And that's why the very first value statement in the agile manifesto says, individuals and interactions are more important than processes and tools. And remember that was written by a bunch of people who were either process weenies or tool weenies. I mean, that was what we did. We got involved in processes or tools, all of us. But we knew that the processes and tools we were advocating were second order. What matters is a good group of people who work well together. And if you've got that, then they have to decide what process they're gonna follow. So that's the essence of agile. I wanna now move on to talk about a model of agile called the agile fluency model. It was developed by Diana Larson and James Shaw a couple of years ago.  And I saw it and I really liked it. And I said, I would love to publish this on martinfowler.com and they went for it. And so it's on my site, but it's their model. I'm just a publisher. And what they did is they said, well, in our observation, we've noticed that teams operate at a certain levels of fluency. Fluency meaning what teams do when they're under pressure and they have to just operate. They were very careful to avoid saying maturity model here, although it does kind of feel like it in a way. And they had these four star levels that talk about to work through. And I said, I find this a very helpful way of looking at it. The first level that teams typically operate this is really can be, I think explained by saying, it's focusing on the management, organizational practices of agile. It's things like doing things in iterations or sprints or it may be using a Kanban board. Particularly importantly, the idea of using retrospectives to be able to tune and adapt your process. The benefit of this first star level is you begin to have a team now that's able to redirect, be able to change direction, to absorb change. Also gives you a great deal of visibility because you're thinking now about how do I focus on business outcomes rather than just following plan points. And that's that shifting core metric. Most teams that they saw operate at this kind of level. And it's relatively easy to get here. It takes relatively small amount of time, matter of a few months. But many teams actually never get beyond this point. And that's not necessarily a bad thing. I mean, they're doing better often than they were doing before because they have greater visibility, greater ability to change direction, but they aren't really getting the advantages that agile has to bring. Because although the management practices are valuable, in order to really become effective at agile software development, you have to bring in technical practices, the engineering practices, things like refactoring and continuous delivery and think about how to design software in an evolutionary way. And these, of course, are the kinds of techniques that I'm familiar from because extreme programming did a really great job, I think, of combining both these management and technical practices. In the early days of agile, extreme programming was the dominant, most visible technique. Over time, it has become much less visible because strung became more visible. But I always have a strong fondness for extreme programming, not just because it's where I started, but because of the fact that it very firmly combined management and technical stuff together. Now, when you do that, what you get is you get the high productivity and low defects that really begin to see a lot of the benefits of this approach. Because the problem with only using the management techniques and neglecting the technical stuff is you tend to have a poorly designed code base that's not able to react well. You're not able to change direction as quickly as you might do because you've got a poor code base to work on. With good technical practices, however, you can begin to respond to change very effectively. So this is really, really valuable to try and reach this point. The disadvantage, though, is it's a big investment to get there. It takes many months to learn these technical skills, to learn how to do test-driven development, learn how to refactor, to get a good continuous delivery pipeline up and going. There's a significant investment in time to be able to do that. And that's, of course, why significantly less teams tend to operate at this level than at the earlier level that we saw before. Because it's more of an investment to get here. It is one, I think, that is worthwhile for most outfits, but it's important to remember to do this. And you need to begin that technical practice stuff at the beginning. One of the comments that James and Diana say is you need to decide where you wanna end up on that star scale and start planning for that from the beginning. So if you want to aim at two-star, start with the technical practices from the very beginning. Don't begin with the management stuff and add the technical stuff later. Do both at the beginning. So what we see here as we shift, as we adopt these things, is the first level is about shifting the culture of a team to think about how do we do this visible approach. The second is a big shift in the skills of a team to be able to take on these technical practices. So what does the third star bring us? The third star is a much bigger shift. I mean, again, look at the amount of time it takes teams to get there. Look at the very small amount of teams that they've observed that operate in this way. But teams that are doing this are shifting in terms of not necessarily just responding to what people are asking them to build and building it very quickly and effectively, which is kind of the essence of the two-star approach, but actually taking a more proactive role. I'll talk about this a good bit later on. And in that they're actually deciding what should be built. What are the best things to do? And they're taking a much more directive role in where they're going. And that means the team has to become much more knowledgeable about the underlying domain that they're working with to bring in the business expertise. And they're taking much more of a directed approach to what we're gonna be doing. It means we're shifting from just a change in the team's perspective to a change in the organization's perspective. And that's one of the reasons this is hard to pull off because you can't do this just within a team's bubble. The organization has to change in order to let the team take this amount of direction on. And that's of course part of the reason why it's so rare. But this is where you can really see some very significant effects. And this is where a lot of the stuff around lean product, lean enterprise and things, it's this three-star kind of level. Now they have a fourth-star level as well, which is a much more broader use of the three-star level, but it's not one that they say that they've actually seen very much. And so it's really a bit speculative. Have a look at the paper, it's worth reading, but I'm not gonna actually talk about that. So that's a quick sense of where we are with how I look at the agile world. It's essence and I think a good model for thinking about how fluent you can be within agile projects. And that's the end of the first talk. And now I'm gonna move on to one of these technical practices that I mentioned earlier on. So now I'll be talking about continuous integration and delivery. So I always like to think about this by thinking about the very first software project that I ever saw. I was a student doing a small industrial placement in between university. And I went to this industrial complex in North of England and I was taken to showing this big software project. It was a huge warehouse, probably about four times the size of this room, full of cubicles. And the people said, oh yes, we're doing this critical project for the future of our company. They've been working on it for two years. They ought to be done, well actually they should have delivered a few months ago, that was when the plan was, but they spent a lot longer in their current phase, which is integration. They've been integrating for several months now.  And the lesson was integrating big software projects or even small projects is quite difficult and therefore you don't wanna do it very frequently. And we see this notion appear both at large scales and at small scales. So a common statement of how you should work if you've got say two or more developers on a team is something like this. Well let's imagine we've got a two person team with Professor Plum and Reverend Green and they're away working on their pieces of work. And they do so in isolated branches of the code, isolated code lines. And maybe from time to time they'll bring in any bug fixes from the main code line, but they keep themselves relatively isolated. This is an approach called feature branching or topic branching.  And that time can be considerable. It's not uncommon when we've come in, gone into organizations to see people doing feature branches that last weeks or months in this area of isolation. And the nice thing is you work on your isolated piece and you don't have to worry about what the other guy's doing. Until of course you need to combine both of those pieces of work into the main project. And then you have this ugly nasty integration to do because you've got two people who've been working separately and they've made all sorts of assumptions that aren't compatible and now you've gotta make them compatible so things get tough. Now some people say well this is actually no longer a problem because we have powerful merging tools. Git can do wonderful merges. It can do all sorts of different things and figure out how they fit together. And that is true but it misses the point that merging has got two parts. There is the textual part of merging bits of code base but there's also the semantic part. If I'm working on my code and I decide all this core library isn't really organized in the way that I need it. Perhaps I need to change some names of methods or organize things in a slightly different way and Jesse's working away on his branch and making similar changes. They could merge quite cleanly at the textual level but the whole program doesn't work on a semantic level and that's where things get more difficult. Now testing can help us spot these problems but we still have to go through and solve them. So again the notion that we have is integration is difficult so we don't do it very frequently. Now I think at the heart of all this is a misconception. And I think of it like this. I'd like to draw this little pseudograph and say let's have a look if we plotted the amount of pain involved in integrating versus the time between integrations we end up with some kind of plot like this. The longer we leave integration it grows exponentially harder for us to be able to merge. And if this is the case which my observation in experience says that it is it leads to a very intriguing cororally. It says that if it hurts you should actually do things more frequently because if you do a very rapid frequent integrations then they don't hurt so much and the overall aggregate becomes much much smaller. And that is the principle behind continuous integration where at every change that you make you integrate it into the main line of the project. So if we compare the two here you see that the continuous integration has more frequent integrations but they're all small. And as a result the overall amount of pain is kept smaller. And of course you have a really bad thing about the delayed integrations that you see in feature branches is not just you get more pain but you get it at the end when you're under the most pressure. Now getting rid of complicated nasty merges is one advantage of continuous integration but there's a potentially more important one. And that is if you wanna keep your code base healthy you need to constantly refactor the code base so that as your understanding and your design changes you can work with that. If you're working with feature branches though and you do an incompatible refactoring on the two branches when are you gonna find out that you've done that?  The important thing about continuous integration is that if you make an incompatible change you find out right away because you're both integrating all the time. And well, again the observation we seem to have is that generally in general teams don't refactor enough but in particular feature branching tends to discourage refactoring because you say, oh I don't wanna change that bit of common code because that's gonna lead to merge problems. So I'll work around it in my code that I'm adding in my branch. And so as a result, the software structure tends to degrade. For refactoring to really be effective you have to do the continuous integration so you can spot the anomalies as soon as possible. So that's about a very brief introduction to continuous integration and why it matters. There's a paper on my website, you can find out more. There's a book, you can find out more about that. But as well as continuous integration I also want to talk to you about how we move on from that and talk about continuous delivery. No, I can't do it. I mean I can't talk about continuous delivery when you offer the book. He's right on the front row of the audience.


Hello everyone, this is Amit Dan of AmitDan.com, you're watching one of my Australia travel videos in the Great Ocean Road playlist and today I'll be sharing the 12 apostles on the Great Ocean Road day trip. This segment of Great Ocean Road trip features scenes from Port Campbell, Victoria Australia where the 12 apostles are located. One of the most world recognized tourist attractions, the Great Ocean Road leads you to the 12th app. The magnificent massive limestone structures that rise up majestically from the tempestuous southern ocean alongside Victoria's windscept coastline. In the past these limestone pillars were connected to the mainland cliffs, then these pillars curved into caves by wind and waves then arches and then eventually turned into 45 meters or 150 foot rock stacked battered by nature. The whole process, constant erosion of the limestone cliffs of the mainland and then blasting winds turning them to caves, arches, finally rock stacks took 10 to 20 million years to complete. The 12 apostles eventually got separated and left isolated from the shore. Only 8 apostles remain now and the 5 have fallen since their discovery. There may be more in the process of making. Let's wait another few million years and see. The 12 apostles have known to change colors throughout the day from sunrise to sunset, from dark to foreboding in shadow, to bright sandy yellow, when the sun is full, force. The 12 apostles are located in the Port Campbell National Park 275 kilometers or 171 miles west of Melbourne along the Great Ocean Road at 4 hours drive. Thank you for watching. Forget about subscribing to this channel, forget about liking this video, I'll see you shortly.


Today we are going to continue from previous lecture properties of pure substance. At the end of this session, student will be able to apply knowledge of basic thermodynamic concepts such as specific heat, sensible heat, latent heat and dryness fraction. Students will be able to calculate the heat required for wet, dry as well as saturated steam. These are the contents we are going to discuss in this session. First, we will define what do you mean by specific heat, sensible heat and latent heat. Then we will move towards the quality of steam that is wet, saturated, superheated steam. Then what do you mean by degree of superheat and dryness fraction. Then we will go into the module diagram and references. Definitions before moving towards the definitions. In previous lecture we have studied the steam generation at a constant pressure which takes place at 1 bar. Here that 1, 2, 3, 4, 1, 2, 3, 4, 5 line represents the steam generation at a constant pressure. 2 is the saturated liquid point, 4 is the saturated vapor point and 4 to 5 is the superheating. First one that is specific heat that is denoted by Cp. How you are going to define the Cp that is nothing but let us take one example. If you are having in a container 1 kg of water which is at 20 degree Celsius and suppose if I supply Q amount of heat whatever it may be Q amount of heat if there is a change in 1 degree Celsius temperature of that water means the temperature of the water starts means change from 20 to 21 that quantity of heat is called as specific heat. Now specific heat of water is 4.187 kilo joule per kg Kelvin means for unit mass and for unit degree Celsius if you supply 4.187 kilo joule amount of heat to water then there is 1 degree Celsius or 1 degree Kelvin change in temperature of that water that is called as specific heat of water moving towards the next definition, sensible heat. Now if you consider this 1 to 2 line if you consider this 1 to 2 line that is called as sensible heat. Sensible heat is simply defined as when you are going to supply the amount of heat if there is a change in temperature but there is no change in the phase that type of heat is called as sensible heat means what if you are going to heat the water from 0 degree Celsius to 100 degree Celsius which is at 1 bar whatever the quantity of heat we have supplied that type of heat or that quantity of heat is called as sensible heat because there is change in temperature but the water will remain in a liquid phase itself means there is no change in the phase that type of heat is called as sensible heat and the sensible heat is denoted by Hf. Moving towards the next definition that is latent heat now if consider at 0.2 all the what you can say in previous lecture I have studied all the points are at a saturated level and all the molecules are in liquid state and whatever the heat you are going to supply to convert that heat from liquid to vapor that type of heat is called as latent heat and the unit of the latent heat is joule per kg and that is denoted by Hf in latent heat there is a change in phase but the temperature remains constant means that is a exactly reverse in sensible there is change in temperature but no change in phase in latent heat there is change in phase but the temperature remain constant means this 2 to 4 line it will takes place at the constant temperature of 100 for normal atmospheric pressure that is of 1 bar dryness fraction dryness fraction it is nothing but it is denoted by x which is equal to the ratio of if you consider given quantity of mixture in it suppose for example out of 100 molecules 40 molecules are in steam and 60 molecules are in water then you can define the dryness fraction it is a ratio of amount of steam molecules divided by total molecules contained in a mixture means as I have given example out of 100 40 molecules are steam means 40 divided by 40 plus 60 you will get the dryness fraction x equal to 0.4 considering this example at 0.2 dryness fraction x is 0 and at 0.4 the dryness fraction is 1 because all the molecules are in vapor state and in between 2 to 3 at 0.3 dryness fraction is greater than 0 and less than 1 now quality of steam the quality of steam can be bifurcated or classified as weight steam superheated steam and saturated steam now total heat contained by the weight steam is given by h f plus x h f g at 0.3 weight steam is there h f is the sensible heat contained by the water plus x is the dryness fraction and h f g is the latent heat if let us say suppose for example x is 0.5 means that is absorbed half of this latent heat therefore h f g multiplied by 0.5 that will give you the quantity of the latent heat and whereas h f is the sensible heat contained by the water at a given temperature at a given pressure now pause this video for a moment and try to write the equation for total heat contained by the saturated steam now the total heat contained by the saturated steam is given by the equation h f plus h f g and whereas for dry saturated steam the value of x becomes 1 means at 0.4 and the value of x becomes at 0.3 the value of x is in between 0 to 1 similarly if you want to write the total heat contained by the superheated steam the equation is given by h f plus h f g plus m c p delta t whereas m c p delta t is the heat contained by the superheated whereas that delta t is called as the degree of superheated how you are going to find out the delta t that is temperature of the superheated steam minus temperature of saturation temperature at a given pressure now we will move we will take one simple example so that you will get the brief idea how to calculate the total heat required now here the question is determine the amount of heat which should be supplied to supplied to 2 kg of water which is at 25 degree Celsius to convert it into steam at 5 bar and 0.9 percent dry now what will the first we are going to write down the given things and as the pressure is given as 5 bar we will use the steam table and we are going to find the value of h f and h f g at 5 bar by using the steam table we will get at 5 bar h f equal to 640.1 kilo joule per kg and h f g is the equal to 2107.4 now I want to calculate the total heat required which is at a superheated let us see at 5 bar now you know the equation as the 0.9 percent dry means that is weight steam the equation to calculate the total heat required by the weight steam is given by h f plus x h f g now you know the values now this equation is given by h f plus h f is applicable for 1 kg of weight steam which is given by h f plus x h f g we are putting we will put the values and we will get the total heat required for 1 kg of steam and whereas as the temperature whatever this h f is there that will give you the total heat required from 0 to 100 degree Celsius or from 0 to saturation temperature but already that water is at 25 degree Celsius we are going to subtract the total heat or sensible heat contained by the water which is calculated by which is given by m c p delta t then this equation is for unit mass and the net quantity of heat to be supplied per kg of water is total heat minus sensible heat therefore this will come as 2432.26 and this is for per kg now as the total mass is given as 2 kg we are going to multiply by this by 2 and we will get 4864.52 kilo joule amount of it means what if you want to convert the 2 kg of water which is at 25 degree Celsius into 5 bar and 0.9 dry we will we have to supply 4864.52 kilo joule amount of heat these are the references thank you.


Regression analysis is a basic tool for making causal claims from observational data. To understand regression analysis you need to understand what the technique does, when it is useful, and also what kind of results it produces and how those results are interpreted. In this video I'll take a look at the results in the presentation. Regression analysis results in a research article are typically presented in a table like this. These tables follow certain conventions, and understanding the conventions makes it easier to understand what the table is about. So let's start from the top and go to the bottom. On the top there's the explanation of what the table is about, and particularly what is the dependent variable in the regression model. So that is in the table title, typically says the purpose of the table, and then at least the dependent variable. It might say some of the independent variables as well. Here we have age, gender and objective performance. Then when we move down we can see that this table contains four models. They are labeled model 1, model 2, model 3, model 4. That's fairly typical. Sometimes they have more descriptive labels, or if we run the same model using different subsamples, we might have the subsample description as a table, as a model heading. Then come the regression coefficients. So these are the values of the betas. If we want to do a quick and dirty interpretation of the regression coefficients, we can look at these stars that are typically till the significance levels as shown in the table of footer, and check which ones are significant. If a coefficient is significant, then we conclude that we have enough evidence to conclude that there is an effect of that variable, and then we look at the sign to determine the direction of the effect. If there are no significant results, then we conclude that we don't have enough evidence to say that there is an effect of, for example, our productivity. Non-significant result does not mean that there is no effect. It just means that we don't have enough evidence to say that there is an effect. Then we have model indices. So these model indices quantify something about the models as a whole. They are not about individual variables, but they are about how well the model explains the data. If we have different subsamples or different sample sizes for different models, then we would have the sample size information here. Finally, we have table footer here, or table note, that tells some useful additional information about the table. For example, here it tells a sample size, and that these are 100 white person and 13 non-whites. For a paper that talks about gender bias, it is relevant to know that there are only 13 minority race people. And there is a legend for p-values. The one star means significant at 0.05 level. Two stars means significant at 0.01 level. So this is the table. Let's take a look at now. Can we interpret these actual numbers? The first thing that we look at the table is the model quality indices. So we look at this, and in this table the indices show us R-square and adjusted R-square statistics. The R-square tells us how much the independent variables together explain the dependent variable. 0 means that independent variables are linearly independent from the dependent variable, so they don't explain the dependent variable at all. Value of 1 means that the independent variables completely determine the value of the dependent variable. So if we think of regression as a line, then all observations are on that line. The R-square has a problem that it tends to be too large in small samples. So there are some correlations that occur by chance only, and then R-square capitalizes on those correlations. To address that issue, there is an adjusted R-square statistic. So adjusted R-square statistic is a bit more realistic of the amount of variance explained in small samples, in large samples, adjusted R-square, and the R-square will be the same. Then we also have something that does not really quantify an individual model, but that is used for model comparisons. So we have this delta R-square from model 1. So how much the second model explains data better than the first model, and how much the third model explains the data better than the first model, and so on. These stars here are significant tests for the delta R-square to be exactly 0. So we have statistically significantly different results from 0, which means that model 2, model 3, and model 4 explains the data statistically significantly better than their first model. So what's the point of having four models then? The point of having four models is that we want to have a baseline. So the first model is always a baseline that only includes the control variables and not the interesting variables. Then in the subsequent models, we add more interesting variables to the model, and if a model with interesting variables and the controls explain the data a lot better than the control variables on the baseline, then we can conclude that the interesting variables have an effect. So the objective with this kind of R-square comparison is to address the question, how much the independent variables explain the data beyond the controls only. R-square is also useful for quantifying the size of the effects. And this strategy is used in the Heckmann's paper that I use as an example here. So in Heckmann's paper, in the conclusions section, you can find this part in yellow that states that across the three studies that they conducted, our example comes from study one. There are interesting variables explained 15-24% of the performance variation in customer satisfaction scores. Where does the 15% come from? Well, it comes from this table here. It is the delta R-square value of the most comprehensive model and the baseline model. So when they add these interesting variables all together in the model, the model explains the data 15% more than the baseline only. So that's the 15%, 24% comes from another source. So this is where you get the 15% to 24%. Is it a large difference or not? So is 15% a lot or a little? There are two ways to answer the question. One is that we can use our understanding of the phenomenon without any other reference to any other statistics. I would say that 15% is pretty large effect of bias. So if something is 15% biased, that's a really big deal. Another strategy that people commonly apply, which is a bit more mechanistic, is that they look for benchmarks. And one commonly used benchmark is given by Cohen's 1980 book. And you can also find that in 1992 article where this psychology is just determined that certain levels of R-square correspond to weak, medium and large effects. But that's a pretty context-free benchmark. You can find more relevant benchmarks for management research, for example in this Bosco's article where these authors review existing research, how large R-square values they produced, and then make judgments on whether effects are considered large or not. But ideally you would look at this number 15 and tell what does the number 15 mean in your context. So that is the R-square interpretation. Various between 0 and 100, the more, the bigger effect. Then we also want to interpret the coefficients. I also talked about the quick and dirty interpretation by looking at what is significant and to what direction. But we also want to understand what the coefficients mean. So let's take a look at this regression model. So our model contains COS female, firm revenue, and manufacturing firm. The interesting variable is the COS female. We want to understand the gender effect. We use firm revenue and whether the company is a manufacturing firm or not as controls. So what is the interpretation of beta one? We get some estimate, let's say, for, and then the interpretation would be, say, terisparibus or everything else held constant. One unit increase in COS female is associated with beta one increase in ROA in this example. And what that means is that if two companies are of the same size and operate in the same industry, the one led by the woman would be four percentage points, more profitable than the one led by the men, led by a man if the regression coefficient was four. So the coefficient tells us one unit change. And this is easy to interpret, because we have ROA has a meaningful unit and the independent variable is one or zero. So we can just compare one is female, one is woman, zero is man, and the coefficient gives us the difference between man and woman led companies. Quite often our independent variables are continuous. So let's take a look at another example. Does education pay off? Let's say that our regression coefficient is one. The interpretation would be that one unit of education increases your salary by one unit. So is that a large difference or not? To understand it, you need to understand the units. So for example, if we have one year increase in education leads to one euro increase in annual salary, probably there are no context in which this would be important finding. We would say that the effect is trivial for any context that we could think of. Things become more interesting if we say that well, the unit of income is not actually one euro, but it's thousands of euros. So one additional year of education leads to one thousand euro increase in annual salary. Would education pay off? That's a more interesting question, because it depends on the context. If you make few tens of thousands of euros per year, then maybe not. Maybe you don't want to go to school to get an incremental increase in your income. But if this was the context of a developing country, where the salaries on annual level are in the thousands, instead of tens of thousands, this would be a huge effect. If you make two thousand euros, and someone says that you'll get another thousand euros for one year of schooling, I would go. Probably many other people would go as well. So when we understand the units, it's easy to understand if the effect is large or not when you consider the context. What if we have one year increase leads to one bitcoin increase in annual salary? The problem here is that bitcoin is not something that we have any idea of a value of a bitcoin. So if someone tells me that I'll pay you a bitcoin, I don't really know what to make of it. I would have to ask him how much is bitcoin in euros. And then I convert it to euros, and then it makes sense to me. Someone tells me that bitcoin is three thousand euros. I'll say, okay, now it makes sense. So if the effects are in a unit that you don't understand, sometimes the units can be converted to ones that they do understand. Someone tells me that the temperature outside is 80 Fahrenheit. I'll have to convert it to centigrade to understand if it's hot or not. The same thing of course works the other way around. If I tell an American person that is 20 centigrade outdoors, they will have to convert it to the Fahrenheit that they know. So conversions can make things easier to understand. What if the increase is one bugasoid? Bugasoid is a fictional currency, and I don't know of any exchange rate between bugasoid and euro. So we need to deal with a unit that we really don't understand at all what it means. This would be, for example, if we have some kind of scale, rating scale between 1 to 7, we don't really understand what the one point difference between 4 and 5, for example, means, or if we have some kind of performance rating that is, let's say 300. We don't know what is the unit. When we don't know what the unit is, we need to consider the standard deviations. So this is our incoming bugasoid in a hypothetical population. So we have a normally distributed incoming bugasoid in this fictional universe, and what we want to know is how, if we go from mean, how far do we have to go until we are in the top third or two and a half percent, or top one in 1000 or something like that? Standard deviation tells us that. So we know that one standard deviation gets us from the mean to about the top one third. Another standard deviation gets us to about top two and a half percent, and then another standard deviation gets us into the top 0.1 percent approximately. So we know that one standard deviation is a pretty big difference. Two standard deviations takes you from the bottom to the top. So one standard deviation is a lot. If you consider human height, the standard deviation of average of male height is 8 centimeters. If a person is 8 centimeters taller than another one, we would consider that other person, the taller person to be considerably taller than the shorter person. Two standard deviations, 16 centimeters, that would be a very big difference in height. So one standard deviation is a lot. When we don't know anything about the units, like bugasoid does not have a meaningful loss, meaningful meaning for us, then we can think about the phenomenon as standard deviation. Let's go and let's get back to the Hekman's paper. So now we have to make a call whether these are large effects or not. We already did that using R-square, and I would say that the effects are pretty substantial. So how do we interpret the individual coefficients? For example, our physics and productivity is also the beta one increase in patient satisfaction. We need to understand the units. But the productivity unit doesn't really have any meaning for us. The quality and accessibility units don't really have any meaning for us, and neither really does the customer satisfaction scores. So in this case, it might make sense to convert these to standard deviation units instead. And this is what we do when we use standard as regression coefficients, which this paper applies. So how we interpret these, that one standard deviation increase in physics and productivity is associated by 0.9 standard deviation increase in customer satisfaction. It seems quite small effect to me, and it is non-significant so we can't really claim that there is an effect at all. And this is a useful way because it makes the interpretation easier. So you can, with some serious limitations that I will not get into in this video, we can basically compare if, whether 10-year or age is more important. So age is a negative effect of minus 13, 10-year has a positive effect of 0.34. We could say that the effect of 10-year is roughly three times as large as the effect of age, and it's in the opposite direction.  But it's a starting point for understanding with regression analysis and how they are interpreted. One rule of thumb is that if your units have naturally meaningful scale, then you probably should not standardize. For example, age, we know age in years, has, it has meaning for us. So now, because these coefficients are standardized, we don't know what is the effect of increasing age by one unit. And that would probably be useful. If I'm behind the best person or the best doctor in customer satisfaction by 10 points, I would like to know how much of that is due to me being five years older than the best doctor. With these coefficients that are standardized, we lose the natural interpretation. So that's the downside. So whenever possible, using the raw coefficients, thinking about the raw units instead of standardization would be better. But in some cases, using these standardized coefficients is easier because it, in a way, allows comparisons with some reservations. So summary of regression analysis interface. What do we do in a regression analysis? We look at two different things. We look at the R-square. How much does the model, all the variables together in the model, how much do they explain the dependent variable? The R-square tells how much variation it is. It's explained between 0% and 100% or 0 and 1. Adjusted R-square is better because in small samples it's more realistic and often we want to compare models in their explanation. So we have the control models only, control variables model only, the baseline, and then we add the interesting variables and we compare how much R-square increases. This is done in the HECMA spectrum. Then we also look at the individual coefficients. A quick and dirty co-interpretation would be check which are significant and to what direction. Then we conclude that effects exist either in positive or negative direction, but we can't conclude what is the magnitude of the effect just by looking at the significance. So these coefficients tell us about the individual effect if all the other variables stay at the same values. Important to understand what is the metric because beta 1 quantifies one unit difference. So one unit change if the effect of one year of education on income is one, then it makes a big difference whether the income is measured as euros or as thousands of euros. So ideally when you start looking at Richardson coefficient, Richardson analysis results, you go in three stages. So you first look at the R-square. Does the model explain the independent variables at all? If it doesn't, then no further interpretation is needed. Then you look at which coefficients are significant to what direction and then you evaluate the magnitudes of the interesting coefficients taking the units into account.