Jason here for Jasper's case breaks dot com live here from the national and Atlantic cities is day four Saturday this is another NSCC break so everybody that buys it no matter what will have a chance to win some money backs and prizes up to thirty thousand dollars in prizes and this is a chance to win a spot in our twenty seven twenty hundred dollar I believe it's twenty seven hundred dollar eminent spot so paying a fraction of the price eighty three ninety nine to give it a shot there as you can see we already uploaded number twenty two so this is number twenty one that sold out last night and this is a one-pack break of twenty nineteen prison football hobby number twenty one so again guys first we do the break we're gonna randomize customer names teams distribute the hits out of this pack and at the end we'll randomize the original customer names got the list ready to roll and one person's gonna win that spot in the eminence break so good luck guys here we go so let's do the break first click the dice roller it's a five and a six eleven times one two three four five six seven eight nine ten eleven morning Nancy how are you eleven times down to Arthur packet all right that's eleven times there let's go eleven times on the team down one two three four five six seven eight ten eleven I'm holding up you know just a little exhausted like you know these shows obviously what we do is not super tiring in the sense that we're physically doing a lot but here's the show you know lugging stuff back and forth from there B&B finding the parking walking you know from the parking lot breaking for a few hours out of the day then going to do the same thing and then you know kind of want to go out right enjoy ourselves here so end up staying out super late waking up super early so I'm starting to feel the exhaustion now that we're getting towards the end of the week alright so this is just the straight-up list like that off the ties I'll let you see your team but no trades yeah so I think today might be our last day I'm actually heading out tonight I'm gonna actually go to New York tomorrow for the day I'm gonna be covering Joe this week because he's taking a little mini vacay again and so he's gonna be out Tuesday to Saturday basically or Tuesday to front Thursday and then he'll be back Sunday so I'm basically gonna cover those couple days in the shop for him on Tuesday so I'm gonna get tomorrow off and Monday off and then go back to work Tuesday but yeah I'm not gonna be here tomorrow so I think we'll be a little short staff if something is really close I don't think Joe minds to break it but I don't believe we're gonna be live for that long if anything if nothing's close to selling out then maybe not live at all and then I get I think it's kind of the same thing Teddy's gonna stay here in the New York for like a month visit his family and stuff like that and so today's pretty much the last day to kind of get into some breaks and then we'll go back to the shop and break them on Tuesday basically we got an autograph Lonnie Johnson Jr. Houston Texas so yeah it should be fun so today guys it's really the day we want to get as many breaks in as possible and we're gonna try to stay live until like actually six o'clock tonight so that way we give you guys more time to really get into those breaks all right so here we go let's switch scenes now and let's do the giveaway guys the number one name is gonna get the spotting evidence here we go here we go roll it three times small randomizer here one or two three times the lucky winner after three one two three phone three times I kind of slow rolled it there so I don't know someone might have seen their name already so 31 sad people one happy person I'm sorry guys who's it gonna be a little extra sad for Shawn Shawn H is a little extra sad I'm sorry but extra happy that was what that was three times right yeah extra happy is Joshua Jones congratulations you are the lucky winner and I believe you've got the couple spots there so give yourself some better odds so you're actually the first spotting evidence because no one else has bought in to the break itself straight up so there you go appreciate it thank you man congratulations so again we have another filler on the website we didn't have to do two yesterday but I know the price went up just a little bit but again that's just what happens with a product like evidence I would not be surprised guys by the end of this weekend starting next week evidence would be over $3,000 a spot for random hit meaning it'll be over $30,000 a case it's gonna hit it's gonna do so well people guys is the first year of eminence it's a beautiful product so like I said even though this is a couple hundred dollars more a spot from yesterday I guess it's just we had to pay up to get another case and I can say I continue to go up it's just gonna go up like crazy like that's cool dude so get in on that guys random hit your guarantee to hit with some beautiful stuff and I still think our case here is gonna have some pretty nice stuff it also is this is actually 10 promo spots holy shit alright so this one's 10 promo spots now probably because the price went up but like I said everybody's gonna get an opportunity to win some money or some prizes in our $30,000 giveaway just for buying into this break so here's the list I'm gonna add your name right now and if I lower it down to 100 you might be able to see the break so we're actually doing pretty well you know a little bit we didn't do too many breaks yesterday but technically the first eminence counted as five promo breaks and technically I think we're like in the 30s now so you know we're pretty much almost halfway there if we have to continue this over there at the shop in Hermosa it's all good but this is prism there you go and this is break number 30 on the promo list so there you go guys appreciated jaskiescasebreak.com


Going forward, what are you seeing as the key thresholds or linchpins for success or deployments? Well, first of all, I think that there's a tendency when we try to deploy cloud, we try to apply all the principles that we've been using in the past, and we've got siloed environments that are specifically aligned to particular business functions, things of that nature, and they want to come in and apply the design principles specifically to that. What we've found is that there really needs to be a change in approach to build the environment from an architectural perspective. There has to be a strategic focus looking at more than just a technical dimension. So one of the things we did over the years, we created a transformational model that helped address those components. We look at the architecture and technology piece. We look at the management infrastructure around software. We look at the governance, the finance, the security pieces, culture and staff, operations, and the portfolio, the actual portfolio offering to make the transformation. What did you say, portfolio? You're talking about the application portfolio? Well, the service catalog, the self-service portal, and the way that the cloud offerings are presented to the business. How they're packaged and presented to the business. And what about the application portfolio? Where does that fit in? Well, obviously, it's the notion of everything delivered as a service, right? So the whole idea, the promise of cloud, is having a particular service that meets the business's demand, whatever that is, a Salesforce automation service, a CRM service, you know, whatever, and packaging that up in such a way that they can gain access to it easily and simply and have it immediately. HP is known out there. Well, I've been impressed. I think may or may not be known by many people out there watching, but I've been impressed by HP's ability to integrate. You've got the networking group, the ProCurve. You've had the acquisition of 3Com. You guys have been really integrating in. Your blades, you've got management software. I mean, that's not easy to do. You guys have done that, and that's something that's taken a lot of work. Larry Ellison is talking a lot like that right now. So what I'm hearing with Fusion and, you know, fully integrated solutions, how hard is it to do? And what's your, you may or may not comment on what you think Oracle's prospects are for doing it is.   How do you talk about the challenges around integration, specifically those key integration points? Let me share with you. I think that is the key factor of why HP is a leader in enablement of cloud right now. We have been strategically over the years acquiring companies, delivering solutions that are cloud-like. I mean, I've been in the trenches nine years doing next-gen computing. We've had a variety of different at point in time names for these solutions. Call what you want. Power plant, shared infrastructure utility. I mean, you name it. And what's happening is that's delivering a self-service function quickly to the business, scalable, elastic, all those cloud-like capabilities. And you hit right on. All of these pieces and parts you see coming together are software portfolio, our conversion infrastructure message, the acquisition of the networking piece. All of those fit together to deliver on the automated supply chain necessary to deliver cloud computing. HP is number one in that space. I'd like to, well, hold on Dave, I just want to drill on that a little bit. So let's talk about what that, what you just mentioned, but multi-vendor. Okay, Larry Ellison's putting forth a vision of Oracle, my way, or the highway. Okay, okay, that's cool. If you're an Oracle shop, that's great. You know, core business plumbing, it's like moving water from one side of the building to the other. Okay, you're going to run Oracle, great. But businesses aren't run that way anymore. They run with a lot of other stuff. Emerging data formats, different databases. How do you drop in in that multi-vendor environment? And what reference architecture in particular are you seeing emerge from that? And how do CIOs figure it out? What proof points or any data you can share there? What? Great questions, I mean, did they give you a cue card or something? I mean, this is just right down the pipe for me. We didn't even know you worked for it. No, that's great. I don't know, I just don't know anything. We follow HP, we know a lot of it. We have inner secrets about HP. That's right, that's right. Well, one of the things we recently launched was our various services around cloud. One particular was the reference architecture. There is a need for a holistic architecture regarding cloud. So what we realize is that cloud is going to be delivered often in a heterogeneous environment. It can't totally be one particular vendor. It's just, it's not even applicable to the cloud vision, right? Because IT is going to function as a service broker. They may select services from outside of their company. They may select them in an outsourced venue or even deliver them themselves. So it's going to be heterogeneous. The key is applying the right architectural principles to that. So we've created a reference architecture that allows our customers to apply our learnings so that they can actually design their cloud architecture and leverage that and move into the role of a service broker. What are some proof points you can just share with us around that architecture that you're seeing that are clearly nailed down and they're going to say this is a no brainer, it's done deal. Things that have to happen? Well, number one of the big things that you go into an environment is this notion of self-service portal, right? A lot of times clients, their heads are on virtualization today. And they're thinking, oh, I want to cloudize my infrastructure, right? So it sounds good on paper. But in order to do that, you have to look at a different life cycle. And you have to look at the idea of saying, okay, if it's going to look like the outside world, what do I have to do to make my environment look like that? So this goes back to service portfolio, having a self-service portal, setting that up so that someone can go to it, select the service they want, push a button and put the request in and allow it to be delivered in an automated way. A lot of clients fight that on the front end, but it's necessary to deliver on the cloud like this. Yeah, take the medicine. That's one. Another one is this notion of the networking piece. And I really love where HP is now in this space because we have the ability to address the network at the core, at the distribution layer, and at the edge. So when we look at that holistically, we want to be able to orchestrate the workflow across that, to deliver, move the workloads around, do the provisioning in a very, very rapid way. And the networking often is a breakpoint when you look at the orchestration today with a lot of the design models. So three weeks ago, we had one of your customers on, Carnegie Mellon, and they talked about how they essentially spun up a cloud within 30 days. Absolutely. Our cloud started offering. Yeah, that's right. So I wonder if you could compare that with what we saw from Oracle, the cloud god box that Ellison announced. I mean, how should our audience be thinking about those types of offerings? Well, the first thing is, I can't specifically talk about his offering because I haven't been under the hood. I haven't looked at it. I just flew in today, so I don't have the details on that offering. But I can talk about it. Good answer. Very good cooperative. It's basically cloud start, but he's offering fully integrated box. Well, let's not go as far as saying it's cloud start. We don't know yet. It might actually be better. Okay. Oh! Now you're hurting me, now you're hurting me. Well, that's the hype. Those that's the rumor. Oh, well, I'll go back to what I said. HP is the leader in cloud development. Okay, I'll go back to that. But no, what cloud start is, cloud start leverages the best of what HP has to offer. It takes our converged infrastructure. It takes our software portfolio. It takes the services and the experience we've had over years. I mean, my cloud advisor friends have been in the trends. We were a group that had been working together for 10 years. We've been bleeding together. We've been working with the clients. And we've packaged these things up into real world architectures that can turn it into a real offering inside the business. But your point is it's not just a box. It's not just a box. Absolutely not. Which is what we saw on stage, on Sunday night was a big honking box. We'll talk about database then. Let's pick up the database. What about database? The database is obviously a key piece of the chess game. SAP buys high base. Oracle has their database. We all know that. And there's other database emerging. There's no sequel. You got the Hadoops of the world out there growing. These environments and storage. Honestly, we know three parts.  Data is the key to the future. Mobility and it's powered in mobility. It's powered in all kinds of enablement. The database is the central engine. How do you guys look at that? And tell us about what HP's integration and cloud vision around databases. You remember I said we've been after this a long time. So as part of our IT transformation, in the mid 2000s, the IT organization came up and said, I want to create a shared database utility. They actually started with shared application utility. That was put in place and was operating from a self-service perspective before those tools and functional offerings really existed because we were innovating them. We wanted to drive better agility. We wanted to have better results from sharing. So the next iteration of that was the database. So we created a shared database utility. It gave us the efficiencies and the economies that we needed. We were able to share infrastructure to deliver them. Licensing costs were reduced. We were able to provision them much, much quicker. You know, it really, the database is there. It's a component in a multi-tiered architecture. The key is how do you deliver it in an efficient, economical way that's shared and gives traction to the business from a financial perspective and a business value perspective. On a scale of one to 10, 10 being super hot. Okay, where are we on cloud deployments? Are they still in the emerging proof of concept stages? I mean, everyone is talking about virtualization. It's a lot of sexy, it's intoxicating for IT guys. When they look at virtualization, new things can be developed around there and whether it's in a production environment. But, you know, people have been talking cloud as dev ops, test and dev. How do you want to look at it? On a scale of one to 10 being super hot, where are you seeing the market on a deployment basis? Real deployment, virtualization, so on and so forth. Well, you know what? We can look at the industry statistics with virtualization. There's a 30, 35%-ish, if you will. I mean, in the virtualization state, I think one of the reasons why we're at that percentage is because in order to go to the next level to have higher levels of saturation, you have to deal with transformation. These are things that we've recognized inside of HP. Just like we went through a transformation, you have to go through a transformational type offering. So it's more than just virtualization. But what we are seeing, I will say this about cloud today, and I'm excited about it. A number. A number, a number. I would say, now, actual deployments are people engaging the game. Engaging into the game. Jumping into the game. Engaging to actually do real deployment outside of dev ops and testing that. I would say we're six and a half, seven, and people jumping on the wagon right now. I have crews that are going around the country that are doing workshops and in customers' offices and every major enterprise that we're talking to wants to understand how to embrace cloud. One of the things we've talked about on Wikibon and SiliconANGLE is that we think the downturn in the economy last year accelerated cloud adoption by probably nine to maybe even 18 months. Do you see that? You know what? There was a need to share. And the economic condition drove it. But you know what else I think drove it? Tremendous offerings like the Salesforce.com, the Google, the Amazon type, global offerings where customers had an opportunity to actually take their credit card. And when IT said, no, I can't do it quickly, they could go right out and get the infrastructure, pay for it, use it, that has become a tipping point. The consumerization of IT. The consumerization of IT. Absolutely, that was the trigger in my mind. That's the tipping point. So being in the trenches, obviously on the cloud side, HP is a consumer company, so I don't think you can speak about the printers and the PCs and whatnot. You probably could, you know, the web OS, love to share your vision on that. But you're seeing it from the enterprise side. That consumerization, tell us your view about where we're at around that consumer expectation. Because the consumer market is leading the trend. iPad is number one on customer satisfaction right now. Off the charts, that's the user experience. How is that impacting the enterprise and how do you see that? And what's your angle on that whole consumer thing? You know, it's interesting. First of all, HP has a really unique place in the industry because we play across all those fears. So we have consumer products that we have to deal with as well as the enterprise and all the rest of it. So what do we go from nonstop to the palm top? I guess it's a way that you could say that we deliver it. I remember that. Yeah, yeah, the old palm top, right? So that was, maybe now it's the palm, I don't know. But anyway, the idea there is, oh, now I've lost my train of thought. That's what's 80s. Consumerization, the consumerization. Consumerization, oh, gotcha. Yeah, yeah, yeah, yeah. You guys had a lot of experience. So here's what I see happening. You know, the success of the Apple, the success of the App Store, the consumerization of those types of products are driving customers and businesses to say, how come I can't deliver things like this out of my IT? How come I can't use my ThinkPad or my iPad or get at this information in like manner, right? So we're hearing more and more discussions of our customer saying, how do you build me an App Store? How can I build my App Store inside? For services they can deploy. So exactly, they're feeling this, they say, I want this experience. I want to deliver the same type of experience internally. So as part of our offerings, for example, around Cloud Star, we're talking about how is it that we can build their App Store? How can we make that happen and deliver? Because the key, the technology enablement exists today to deliver world-class types functions inside an IT organization if they choose to do it. One of the other things we talked about is, you know, this whole consumerization of IT and the cloud service providers really being superb, right? A lot at scale and low cost. And we talked about that the IT, traditional IT, doesn't have to get equal in terms of the efficiency and the scale and the cost. It has to get close enough. Do you agree with that? You know what I think? This is what I think now. I'm really excited that we're to the point of inflection that we are today. It can no longer be their opinion, right? Because there are expectations. In other words, when they talk about providing that type of functionality, it needs to look like a global provider. To your point, it doesn't have to be to the same scale. You know, maybe it doesn't have the same fancy frills on it, but the business is going to want that same type of user experience. So you can't say, I'm delivering a private cloud and say send me an email order and I'll figure out how to order it. You want to go to a portal, select your service, push a button, go get a cup of coffee and come back and get an email notice that your infrastructure is available. That's what they want. Yeah, people say that, oh, cloud is all hype. It's just IT. Well, the IT that I know today isn't what you're describing with self-service, provisioning, visibility on chargebacks and things like that. And eventually, my personal opinion is that IT eventually will become cloud. It has to. It will be in a different must, right? It has to. Okay, so we want to bring your other colleague in to talk about security, but before we do that, let's drill in a little bit about your advice. You talk to a lot of customers.  What advice do you give folks out there who are out there? We had one of your customers from the Dallas Cowboys, Bill Haggard on, and he shared some great stuff. I'd like to get your opinion. Advice to folks out there who are knee deep in, my CIO wants to do it, shit, I want to do it, but I had to do it this way. What's your advice for the folks out there on the roadmap? What to do? The journey, that's the hype that EMC puts out there, but it's true, it's a journey. What do you do? Look, so here's a story. Is there a 10 point plan? No, so first of all, we have patent pending collateral that was developed in the mid 2000s on how to move to a shared service operating model. This is what we're talking about. This is what we'll deliver on the promise of cloud. We have that, it looks at six key dimensions. I kind of mentioned them earlier in the talk, so I won't go over them again. They have to be addressed holistically. That's awkward, here or here? No, no, just here. So I can share, I'll share with it. You have to look at technology and architecture. You need to look at the software services measures. Can you share this, can you send us an email and send us a text? Sure, let's do that. We can definitely do that. Six key dimensions to think about transformationally, but one of the real things that customers need to think about is that they need to engage someone to act as catalyst. What I have found in the journey is that our clients that engage professional assistants, here's a plug, but it's real, and I'm not saying you have to come to me, I'm saying go to somebody. There are a lot of good consultants out there. The idea is gain someone who can catalyze your movement because you will not be able to apply the same principles you have applied today to make it work. Let's talk about catalyst. Wait, technical, political, compliance, all of the above? All of the above. The big issues are people, governance, finance, organizational structures. The technology is easy. Not a big deal. Not a big deal. It's people and organizational structure, governance, finance. So who's your colleague that's going to come on? He works for HP, right? He works for HP as well. Archie Reed is going to come in. He is Mr. Security and he'll be able to talk to you passionately about security with the client. How long have you been with HP? It'll be 10 years in February. 10 years. Congratulations and good luck with HP. We know there's a lot of innovation out there trying to get to the marketplace. You guys had a setback with the whole her situation. Glad that's all cleared up. Thanks for coming on, sharing your opinion and content with us. Thank you. Thank you, great to see you. Thank you very much.


I want to start out today by doing a little exercise. The exercise is lifted from a book called Nonviolent Communication. And it's called Translating Have To To Choose To. The idea is that we all have things in our lives, which we do not because we inherently enjoy them, but just out of some kind of sense of obligation. We feel that we have to do them. And the idea of the exercise is to acknowledge that there's a choice there, and once we realize that it's a choice, figure out what we're gonna do about it, and think about maybe how to re-make that decision. So you take all these things in your life that you don't really enjoy doing, you make a big list of them, and then you have to fill in one by one this sentence with each thing. So you say, I choose to X because I want Y. You figure out what's the reason that you make the choice to do that thing. And what you'll basically find is one of a few things will happen. Maybe the thing that you want is actually really important, and you'll find new meaning in the thing that you were doing. And it'll feel more like an active choice that you wanna make. Maybe you'll say, well, the thing that I want wasn't really that important, so I don't really have to do it. Or you'll say, well, the thing that I want is important, but maybe this isn't quite the right way to get to that point. Or maybe there's just a different kind of broader set of strategies that I need to really get the thing that I want in some kind of better way. So today we're gonna ask the question, why do we choose to write good code? And that's a little bit of a scary question, right? Now what do you mean? We have to write good code, right? It's ingrained into us. We go to talks at conferences, we read books, we watch podcasts, or listen to podcasts, I guess. We watch stuff online, we read blog posts, all about good code, we have to do it. That's just, you know, that's what we do, right? So I'm here to tell you, first of all, today, you don't have to write good code. You choose to write good code, hopefully. And part of today will be figuring out why we choose to write good code. That second line, because I want what? What do we fill that in with? Maybe we fill it in with, well, if I don't write good code by some kind of arbitrary standard, then I'll get fired. A sad reason to, but that might be it. But ideally, we'd find something meaningful and important in terms of why we're choosing to write good code. So why do we care about writing good code? And because this is a talk about software quality, and that's really the ultimate goal here, we have to ask, is good code actually the same as quality software? So we'll get back to that. But first I want to talk about something somewhat, but not entirely different. Dave Thomas, Bob Martin, others as well, but I mentioned them just because they were signatories on the original Agile Manifesto, have said that Agile is broken. It didn't accomplish the revolution that it was supposed to accomplish. Here's a quote from Bob Martin quoting Kempbeck, who was also there. He said that one of the goals of the Agile Manifesto was to heal the divide between development and business. There was a gap that had been created, a chasm between the two sides and a lot of tension, and the goal was to relieve some of that tension and find ways to work synergically and harmoniously. Reality check, I don't think it really worked. They don't think it did either. So at least I have some people who were involved in Agile right from the top saying, not great situation, but what it became was basically some kind of business person, project manager, whatever it is, would take a course, get certified in something, and basically tell developers, okay, now you're all gonna do Agile because that will lead to better software. It's something that developers do to keep business people happy if you could even do, in quotes, Agile. Usually the form that this takes is scrum. I forget the number, 60, 80%, something like that of organizations that claim to be doing Agile are using scrum as their implementation. Fun fact, as far as I can tell, because I've read through the scrum guide and I've read through the Agile manifesto and compared the two, it addresses maybe 50% of what Agile is and it kinda misses out on all the values. So I'm not saying that scrum is bad. I don't wanna give that impression. I think scrum has a lot of really good ideas. It's just not an implementation of Agile, it's a framework in which you can choose to be Agile or not, it makes it easier in some ways, but it's not actually agility. We don't need more processes. Sometimes processes can be helpful, but they're a tool toward something more important. And what I think that we need, and this is why I'm coming down kinda hard on scrum, is we need more trust. Scrum focuses a lot on transparency. As far as I understand, transparency is basically, we have two sides, each side sets to the other. I need to know what you're doing at all times. I need you to be transparent about it so that when I see something going wrong, I can jump in and complain and micromanage you. Trust, on the other hand, is let's have a conversation. Let's understand that there are two sides to the situation here. And let's talk about the needs of each side. Each side will express their needs in a way that makes sense to the other side. And once we're confident that the other side has heard our needs and understands them, we can rely on the other side to think about our needs and account for them in their own decisions. That's what trust is to me, at least. And that's what allows us to build effective organizations. I think we can solve this problem. I don't think it's even too complex. It's difficult, but I don't think it's complex. And it starts with communication. If we learn to communicate between developers and business people in a way that makes sense to both sides, then we can start building the trust that we need to have highly effective organizations. So we have an ambitious goal today. We're gonna create a common language for developers and business people to be able to express their needs in a way that makes sense to both sides. And the way that we're going to achieve it is by going right for the jugular, taking the thing that causes a lot of tension between the two sides, and trying to understand it again, figuring out why we write good code. A lot of times we push for good code in whatever way we define it, and good code takes time and takes investment, and it's hard to explain that to the other side, and that causes a lot of tension. So we're gonna figure out why we write good code. But first, let's figure out why do we write code? And I really mean that. Why do we write code ever? Seems like a strange question, right? We're developers, that's what we do, that's our job. Well, newsflash, controversial statement, okay? But I think it's certainly pretty clear to me your job is not to write code. Your job is to solve problems. I wanna give an anecdote from specifically another field that will help us look at things a little bit more objectively. So there's a man once came to a plastic surgeon, and he said, I need you to do some surgery for me. My ears are very large, and I want you to make my ears smaller. Interesting. So the surgeon decided to probe further, okay, why do you want this surgery? What problem are you trying to solve? And this guy said, well, it's not a problem for me actually at this stage of my life at all. I get along fine, we're all adults, right? But when I was a kid, I got teased a lot, I got bullied a lot over the size of my ears, and I don't wanna pass on that problem to my kids. I'm about to start a family, and I don't want them to get my ears.  So he clearly still had a Lamarckian understanding of evolution. I was curious how many laughs that would get. So, and basically what the doctor did was say, hey, let's talk about modern genetics, let's understand how these things actually work, and why I can't solve your problem, and the solution that you suggested certainly doesn't help. If the doctor had said, okay, that's nice, let's schedule a surgery, we would call that malpractice. But it's funny, because that's very clear to all of us, I think. But what happens when someone approaches a developer and says, hey, I want you to build a mobile app for me? And the developer says, okay, without even understanding the problem that we're trying to solve, without understanding whether this is the right solution, maybe they need a marketing director, maybe they need to just have an email campaign, maybe a lot of things. There's thousands of apps out there in the App Store that reflect this problem. They don't do anything for anybody, they don't matter. I have a hard time calling them high-quality apps, because they don't solve a problem. If you're not solving a problem, there's never a reason to write the code.  Your job is to create value. And that's kind of a loaded term, means a lot of things to different people, so I'm just gonna give a working definition that we're gonna use for the rest of the talk. Value creation, in the context of this talk, means one of three things, or more of those three things. Generating revenue, lowering costs, or reducing risk. Those are the main things that matter in business. In the specific case of a nonprofit, instead of generating revenue, you can substitute doing whatever good the nonprofit is supposed to do. But on the whole, the same pattern still applies. Those are the three things that we mainly care about. And where do users come in? Well, generally, the way that you do these three things is by meeting the needs of your users. So we're gonna use meeting business needs and meeting user needs kind of interchangeably in the talk. Hopefully they go together when they don't is a whole discussion that I'm just not getting into today. So to recap, why write code to create value? That's it. That's the only reason we should ever be writing code. If that's the case, why do we care about writing good code? I think the answer is simple. It usually helps to create value. Does that mean that good code is the same as quality software? According to this definition, I don't think so. So here's the second of two controversial statements. I would define software quality as just the amount of value that it creates. We're writing the code to create value. If it creates that value, it's fit for purpose. It is ergo high quality. If it doesn't meet the needs, then it can be really well-written under the hood, but doesn't really help because it's not actually solving a problem. So rather than asking how can we write better code, what we should really be asking is how do we target our efforts in coding to maximize value creation? And how does good code fit within that whole broad picture? So I'm gonna commit a major programming sin now, which is solving a problem by writing a framework. It's not JavaScript, it's just a human-people framework. It's only three words, so hopefully it's not too bad. I think that there are three factors that if we think about these three, we can pretty much fit anything about software quality as we've defined it into one of these three factors or two or three out of them. I call them usefulness, sustainability, and accuracy. We're gonna talk about what each of these means, but you'll notice that there's an acronym there. I didn't choose these words over the acronym, like that happens sometimes. I just want a cool acronym. It happened to be the acronym that came out, but if thinking about the USA helps you in terms of remembering the three words, all the better. All right, so let's start with usefulness. Each of these is going to have a question and target. The question in terms of usefulness is does it solve a problem effectively? Pretty straightforward, but a lot of details there. The target here is our users. Again, using users and business needs a little bit interchangeably. The question is, is it a problem that affects users, first of all? Sometimes we spend a lot of money to code up a solution that doesn't actually address a need. We have to make sure in whatever way we can that we verify that the problem actually exists and that it affects the users that we're gonna be addressing. Then, even if we've correctly identified a problem, it's important to think about, well, is this actually a solution to the problem? Or are we missing something? And it can't just solve a problem, it has to solve a problem in a way that works for the users. Because if it works, but doesn't work for them, you haven't really done an awful lot. I wanna cite a story from Tara Scherner de la Fuente, who gave a keynote at RubyConf last year, which I think absolutely illustrates this point really nicely. She was working with a user of one of their applications, just kind of seeing what they were experiencing. And it was to upload a spreadsheet with a whole bunch of rows and anything that the application could figure out, great. If not, then you had to kind of fill it in. So one of the columns was a column of dates. And most of us think like, okay, date picker, great. In the case of this application, they decided to allow inserting dates, and putting dates by a dropdown menu without sorting the dates. So there were just hundreds of dates in a completely unsorted list that they had to look through, somehow managed to find the right date and then repeat it again and again and again and again and again until the whole spreadsheet was done. And if there was an error, by the way, you had to go back to the beginning and it wouldn't save what you had done so far. That meets the needs technically, you'll eventually get it done, I guess. But it's not in a way that works for the user. It's really hard to call that a high quality product. Okay, that's usefulness. Sustainability, what's it about? The question is, can we keep building without unnecessary obstacles? And I thought about this a lot, I didn't wanna say without obstacles because there are always gonna be obstacles there. The question is, are we identifying the most important obstacles and trying to account for them, trying to limit the things that are gonna stand in our way as we continue developing? The targets, in this case there's two targets which I think are really one. The first is our software. Is the software resistant to change? That breaks down into two sub-questions. One is an issue of understanding. Is the software written in a way that we just won't understand what it does and it's gonna be hard to make changes? The other piece of it is, well, even if it's very clearly written, we understand what it does, but the certain architecture choices we might have made make it hard to change things later on. So it just takes longer, it's a lot more effort to do. The other target is the development team. We so often forget that the development team is, I don't even wanna say it's as much a part of our software as the code itself. It's more of a part of our software than the code itself. Think about how just carefree you are when the leading code, putting in new stuff. You don't do that with your team, right? The rate of churn is ideally a lot lower and you crash the development team, you basically don't have a product anymore. So it's important to be aware whether the team is unstable in some kind of way that if things are tipped a little bit, is that going to prevent future progress? Is the team gonna collapse? Or just become less effective in some way? That's sustainability, let's talk about accuracy. This is the one that we probably think about the most. The question that we're asking is pretty simple. Does the software work the way that we think it does? The target here, you think I'm gonna say the code, right? The target is ourselves. We have to ask four questions. Have we developed our understanding of the problem? Sometimes we just don't understand the problem correctly. We do everything right in the coding step, but we haven't taken the time or the effort to figure out first, is this actually the problem? Does it solve the problem? Is it, all the usefulness stuff leads into an accuracy problem? Have we developed understanding of the code? Is there something about the code that makes it hard for us to get the next step done? And we're just coding the wrong thing. Sometimes there could be issues of cognitive overload that even if the code is relatively clear but there's so much going on, too many integrated systems, microservices, whatever, that you just don't understand the full impact of your actions. And finally, our understanding of a problem changes over time. Sometimes the problem itself changes over time. If we're not updating the code to reflect that, that ultimately appears as an accuracy problem. These seem like things that are maybe a little bit like mashed together that shouldn't be together, but if you think about it from the perspective of the user, if any of these are failing, your software is broken. That's a bug report, any of those questions. So to me, that means that they're all issues of accuracy. I can't speak for anybody else, but when I think about why I write good code, why I choose, actively choose to write good code, it's because I want software that's useful, sustainable, and accurate, and good code is a significant tool in helping me get there. Here's the traditional model with the business development chasm pictured. In the right corner of the room, we have accuracy and sustainability. Those are seen as the domain of the developers to write good, accurate code. And on the left side, we have usefulness, which is the domain of designers, UX people, product people, et cetera. And never the twain shall meet. We really subdivide those responsibilities, and it's not surprising that each side advocates for the things that it cares about. Well, we said never the twain shall meet, but today, the twain shall meet. What we actually need is to think about quality as all of those factors together. We need to have, we can't leave out any element of that. And we have to be part of that usefulness circle as well. So this has all been pretty abstract, I realize. And I don't wanna leave you with just kind of abstract floating in the air ideas. I wanna take this down to a very practical level. So what we're gonna do, clear out the diagram, we're gonna ask the question, is it quality software? And we're actually gonna fill in the things that we do on a much more granular level to address each of these three points. Usefulness, accuracy, sorry, sustainability, and accuracy. Now this is a Venn diagram. There is gonna be some overlap on occasion. Practices might contribute to more than one of these circles or to something that we might think of as maybe the confluence between those two circles. So I'll just give a little more definition in the middle. We have between accuracy and usefulness, the question of does it work in the way that the users expect. Less thinking about ourselves, starting to think more in the direction of our users. Between accuracy and sustainability, we're asking the question, can we keep building our system without breaking our system? It's future focused accuracy. And up top, between sustainability and usefulness, we have the question of, are there obstacles to future usefulness? Essentially things that aren't threatening usefulness right now, but we're aware that the choices that we make now might have some kind of impact in the future on how useful our product is. All right, so I titled this talk, What Comes After Solid? I thought it was a nice juicy title, but I also think it kind of makes sense to start by talking about solid because it's just this traditional metric of software quality and we think a lot about it, we talk a lot about it. I'm actually not gonna talk a lot about it. I'm actually gonna run through it really, really fast. So if you aren't familiar with all of the details of solid, that's okay. I could spend the whole 40 minutes just talking about that. So you might be bored for about a minute, but we'll be fine after that. There's tons of stuff that you will understand. Fine, so solid stands for five different principles that are related to creating whatever we might define as well-crafted software. The single responsibility principle, the idea that every element in your system should do one thing and do it well. The open-close principle, which is short for open for extension, close for modification, meaning that you should be able to add new features without modifying existing code. How you do that is, again, a long story. So I'm not gonna get into it. Liskov substitution principle. Basically use inheritance properly. Don't inherit from a superclass because you need a method. Inherit because it's actually a specialized instance but it should fully implement the superclass and all of its functionality. Interface segregation. This is not that relevant for Ruby because we don't really have interfaces in the traditional sense, but I think of it as, ultimately it's about limiting the surface area of how objects depend on other objects. You can do that with adequate interfaces. Technically I don't think it matches a principle but it's close enough. And finally dependency inversion. Depends on abstractions, not concretions. You're basically pushing dependencies to the outside of your system and then the core elements, the units are depending on sort of a theoretical idea of what the dependency is doing without relating to too many of the implementation details. So let's run through, we'll do this very quickly. SRP I think is a big winner. If every item in your system does one thing and does it well, it's easy to tell if it's doing the thing that it's supposed to do. It's much easier to change later because you know exactly what to go back to and modify. And this is sort of a personal opinion. There's gonna be a lot of personal opinions here so I apologize but kind of sorry, not sorry. The main thing here is not to learn the details. It's to see the way of thinking and ultimately you're gonna apply it yourselves. But back to right here. So usefulness, I think that single responsibility means that each part of your system has a very clear responsibility and that lets you start thinking about is this the right responsibility? Is it something that actually creates value for people? Is this something that should or should not exist in our system? It opens up a pathway to those conversations. So I think of it as a very, very central practice. Open-closed is really just about the future so I put it all the way over in sustainability. Liskov substitution is about avoiding certain classes of errors. So I think about that as avoiding errors now and avoiding errors later, accuracy, sustainability. Interface segregation and dependency inversion again are really about the future. So those go all the way in the sustainability camp. So that's where solid falls out in the way that we've expressed it. It's all in the sustainability camp. There are a few that get into other places and again SRP to me is a pretty central practice. Let's talk about some other stuff. Sandy Metz has her four principles which get the acronym true. You can read about them in the first chapter of Puder. Four principles that are meant to create systems that are much more robust in terms of their ability to accept change. Makes it much easier to change them in the future. Transparent meaning that the consequences of changing code should be obvious. Reasonable, the cost of change should be proportional to the benefits, if it's a small change then it shouldn't be, or sorry, if it's not that beneficial change versus if it's a very, very beneficial change the cost of change should be proportionally related. Usable basically is the code reusable in other contexts. An exemplary, your coach has had a good example for coders to come because of course we all kinda look at the system, see that oh, it is the way it is, therefore let's just perpetuate those qualities in the future because obviously whoever was here before did it right. Those are all explicitly about the future so I put them right into that sustainability camp as well. So we're pretty heavy on sustainability but let's try to diversify our strategy for quality just a little bit. Let's talk about testing. The first thing that very often in our community we forget is even a choice, is testing at all. You could not test, there's a lot, a lot of places and teams that don't test at all so choosing to test at all is a practice. Code coverage, the attempt to make sure that every piece of your system is exercised in a test. Different types of tests that we could talk about, there's unit tests which test a small piece of your system, integration tests which are testing how pieces of your system interact with each other, a much broader perspective and manual QA which is even further out, you have a person who probably hasn't worked on your system themselves thinking about a user perspective, trying to use it as a user, trying to break it, et cetera. Okay, then we have TDD and BDD. I'm not going to offer my own definition of it, I'm just going to try to give my understanding of how the R-spec book defines them.  With BDD it's the opposite, you start out with a broader perspective of what you're trying to do for your whole system and then work your way down. So how did those fall out? Well, not surprisingly, they're all in the accuracy camp because they all help you write more accurate code. Coverage helps you out with the future as well, it's explicitly designed that if anything about your code changes in a way that's going to break it, you have a test alerting you to that fact. You have BDD, manual QA and integration tests, I think actually do relate a little bit to usefulness because they're making you think about your system not in terms of is a code, right? But what is the purpose of writing this code? And testing I put in the middle because I think that all of these actually provide a pretty strong signal in a bunch of different directions. So I think of testing as essential practice as well. All right, so that was a little dry, let's talk about some hot new buzzwords. Everyone's talking about functional programming. DHH seems to be, I'm not sure if he's in Twitter or not based on the keynote this morning, but everyone's talking about it, type systems, everyone's talking now about gradual typing, soft typing, type script, type, type, type. Immutability, creating objects that should not change after they're created and scalability. Everyone's talking about now how you have to be Facebook style, you have to be Twitter scale, you have to be, I don't even know. So most of these are actually really in the accuracy camp. You could make an argument to push over some of them into sustainability just a little bit, but ultimately they're about writing code that's accurate, that doesn't have unexpected side effects. So that's most of them. Scalability is a little different, it's about future usefulness. And the reason that I say that is because if you actually need scalability right now, that's not called scalability anymore, that's called our app is down in production. That's a different problem. An important one, but not the same. Scalability is about well, one day we might need to deal with a lot more load, so let's think about that now. Which I don't know how useful that is, but for some apps, I guess it can be. All right, complexity metrics, those are fun. Cyclomatic complexity, how many assignments, branching and conditionals does your code have that make it more difficult to understand? If you use flay, it's looking at that. Low-Canasans, this was introduced to me by the patron saint of Wunder Jim Wyrick in a talk that he gave a few years back. Basically different places of your code that have to change in tandem create canasans and we wanna lower that, we wanna minimize how many things you have to change together to have your system not break. So I put that, basically the more complex something is the harder it is to write correctly the first time and the harder it is to write correctly the next time also. So that's where I see those falling out. Okay, now we get to something that's, for me a lot of fun, something I care about a lot, which is team-oriented practices. Organization conventions, if you have something like, we all use the same, we all use Rails, we all use a certain tech stack, a certain process tool, anything that is consistent across your organization that makes it easy to move across teams if need be, that's one team-oriented practice. A style guide, and ideally, unfortunately that style guide programmatically with Rubikop, JS, whatever's the appropriate tool. Something that keeps your code consistent so it's much easier to navigate and understand.  Fun fact, most teams have a bus factor of one. Which is bad because occasionally, aside from dying, people also quit, get fired, take vacations, get sick. We want to ideally have room in our organizations for people to do normal people things and have our apps not be destroyed. So, mainly knowledge sharing, also upping the level of really everybody on the team rather than kind of hoarding knowledge or skill. Code review, okay? Stuff gets reviewed before it's checked into source control. Pair programming or mob programming, the sort of like code review on steroids, taking multiple developers, however many it is, and having them work on code at the same time, each providing their own perspectives. Internal documentation, readme's, stuff like that, things that help you both onboard new developers and also remind you of things that you might have forgotten or you might have forgotten to share with other people on your team. Debugging tools, stuff that helps you out a lot when things break, and you need more insight into your system. And the last thing is mentorship. Which I'm choosing to define, and it's a choice, I'll admit it, but I'm choosing to define as taking two people on your team who have different skill sets, pairing them together in a formal context over a long period of time and having them share their skills with each other. So, most of these fall into sustainability because they're practices that help you build up your team. Your team works better together, your team is more stable. I put mentorship on that crossover with accuracy because it turns out that people who are more skilled end up writing better code. So, both the first time as well as keeping your team healthy in the future. Code review, I put in the crossover between accuracy and usefulness because code review, first of all, is just a good check on whether your code is doing what it's supposed to do, but it also creates an opportunity for a conversation about should we be writing this code? Is this the right code to write right now? Is this the right solution to the problem that we're facing? And pairing and mobbing, like I said, are kind of code review on steroids. The cool thing about it is that it does all those things while also building up your team, building those relationships. I once saw something, a Quora answer by Campback, he was asked, actually someone just asked the world, does Campback believe that pair programming is always a good idea? So, Campback I guess found that and answered. He basically said when either the problem space is big, the solution space is big, or you need to build relationships on a team. Really important to remember that pair programming or mob programming also have that effect. All right, couple miscellaneous items. Continuous integration, making sure that your code passes a build before you actually deploy it. Frequent releases, frequent releases, kind of self-explanatory. Refactoring, not as a thing that you do once, but as a thing that you do constantly, always looking to improve the health of your code base. Conventional APIs, basically using things like RailsRest or JSON API, or just the normal ways of doing stuff in the language of choice, things like add a reader and add a writer rather than get adder and get set adder in Ruby or the opposite, I guess, in Java. Just kind of using the things that people expect. So those fall out kind of all over. CI is mainly an accuracy thing. You wanna know that your code works. Refactoring is on that border between accuracy and sustainability because it helps you write code correctly, because usually you're refactoring in the context of writing new code. It helps you make sure that you got it right. It also helps you keep your code base healthy in the long run. Conventional APIs, I put on up top because I think that they are usually well designed and they leave you room to grow in the future. And frequent releases. So, I did not think of frequent releases as a central practice for a long time, so it's kind of a recent revelation for me. But the truth is, when you release things frequently, first of all, you figure out that things are broken really fast. So that, I guess, helps your accuracy. It helps your sustainability, because you're not building castles on top of foundations which you only later find out when you deploy are actually broken. And it helps out with usefulness because until you've actually shipped, any changes that you've made, you could think of as inventory, right? You haven't actually created value until you've shipped. And the faster that you ship, even a small bit of functionality, the faster it's gonna create value. Okay, so we've covered a lot of ground. We have a pretty diverse strategy, but we're kind of missing something. What goes in that red area? What's going in that usefulness section that we can use to balance out this picture of software quality? To me, it's practices that are centered on user-oriented thinking. The main one, which kind of leads to all the others, is a focus on delivering value. Rather than thinking about what's a cool thing that we could do now, or thinking about it from a very technical, like okay, let's build it up from the ground up, just focus on what's the next thing that I can do that will create value for our users. To understand that better, you have to actually talk to your users. You have to research their needs. You have to, if you can collaborate with them, the closer collaboration you can do, the better you'll be able to actually solve their problems because you'll understand what their problems are. Prioritization, it's really easy to get caught up in what's a cool thing to build, but if you're focused on delivering value, you'll prioritize the actual most important things for delivering value. Discoverability, if you create a really cool feature but nobody can find it, then you might as well have not done any of that coding because it's useless. Empathetic UI was not a term until about three seconds ago, as far as I know. I'm sure there's a real term, but what I mean is a UI that thinks about what are the needs of my users, what kind of situations are they gonna be in when they're using our software and then how do we anticipate those needs and give them what they need in the way that they need it. On time, depends on your organization and on your users and their needs, but if you're writing tax software, really try not to be a year late. Performance, we always think of performance as a computer science thing and for the life of me, I can't figure out why. Part of it is because yes, so much of computer science curricula is about performance, but it doesn't matter for some reason of technical accuracy or anything. It matters because users can't wait forever for your app to work. It's just to meet a user need and when you do performance optimization, you have to actually focus on meeting that user need and what are the things that they actually need me to optimize. So that's pretty good in the red area and we're just gonna add a couple more things for technical products. Documentation is the face of your product to your users. If they see a distinction between your documentation and what your software actually does, they don't think that your documentation is wrong. They think your software is broken. Something to think about. Writing client code may or may not be relevant in terms of what you're doing, but sometimes if you write a client library that will help your clients use the code that you're creating, the technical product that you're creating, that will actually give more value to them than just kind of staying on your own and making a more robust product, but they have to figure out how to integrate it. All right, so that's the whole picture in my mind and there's more practices that I care about, but we only have limited time. But this is my brain right here on a slide. There's more to my brain than that, but part of my brain. But ultimately in the question of is it quality software? I can't tell you. You have to decide. So I'm gonna leave you with this. A blank slate. I put it, or I'm about to put it on my site. I tried to deploy before and it didn't appear so I'm gonna try again right after. But bring this back to your teams. Think about these issues. Think about the practices that you do and that you care about as individuals and as teams. And whether there's areas that are missing that are a little patchy in terms of your software quality. All right, so we're gonna wrap up. Couple of parting thoughts. Number one is different projects require different balances of factors. And actually Chembeck has this three X framework you've been talking about recently, which points out that even within one project it'll change over time which of these things matter. Number two, I don't think it's bad to focus on good code first in terms of career development. Why? This is more straightforward. Business understanding takes a really long time to develop. It's really important but it takes a long time. Good code, you can get really, really much better at good code in a scale of months, maybe a small number of years. And once that happens, by the way, it becomes more automatic. Like you'll find yourself less able to write bad code if that's the way that I can put it. Business understanding, you can't automate. It's something that you have to constantly refresh because there are constantly new business realities. So the implication is start off really focused on good code and then move more into business understanding in terms of your focus as you move on. So your career trajectory might look like this. The middle line's sloping down. You start out focusing a lot on good code but then it goes down. Business understanding is kind of coming in in its place. Those lines might cross. Those lines might cross really far if you're going into management or project, a product management or stuff like that. They might say far apart if you're an architect but those lines should change over time. That's okay, that's expected, that's a good thing. The main thing is the line on top is how much value are you creating? So what can I do to build business understanding? It's basically a matter of learning. It's learning about your users, your industry, the organization of your organization looking to solve dysfunctions within your organization, ideas of business, ideas of organizations and processes. So there's all that learning but you also have to become better at empathy skills. And that's my last point is that empathy is gonna become ever more important. What can you do to build empathy skills? Number one is read, learn, find out about new ideas. Next slide, we'll talk about that but the other part is practice. Meaning cultivating curiosity about others. Especially if they're different from you which is really hard. But you have to listen to them. You have to understand their needs and their feelings and see the humanity ultimately in everyone. That will make you a better person and it'll also make you a much more effective developer and person in your business. So I started a club, or I'm starting a club that's launching officially at the end of RailsConf. We're gonna be reading books on empathy. In the software context, in a general context and thinking about how they apply in our professional lives. You can check out the site, devempathybook.club if you're interested. I'd really like there to be more discussion about these things in our community. So check it out. But the bottom line is make your software valuable, high quality, creating value for users and make yourself valuable. I wanna thank a few people. I'm not gonna name them, they're on the slide. But what I've said today is not my ideas per se. They're just my analysis and integration of ideas that I've learned from and through these people. I especially wanna call out Gene Westbrook who was my mentor for my first year at Vitals and he's in the room today. So thank you for being there for me. And the last thing I'm gonna say is I spent a lot of time on airplanes to get here. 18 hours in the air, three flights. So I'm a little like, I have the airline thing still like haunting my dreams. So I'm just gonna say I know you have a lot of options as to where you can spend your time at RailsConf. Thank you very much for spending it here.


Maen nhw ydw i nhw'n rhoi gydag i gyrfaith iawn o dwi'r gweith sydd o'r Cymru a Gŵrgol Gwmwylon Nhigien Yn 2024, ryddyn ni'n iad o ddefnyddio'r gyrfaith iawn i gwnlu gyrfaith iawn. Fe yw yma ar weithiau gweld o'r documenta'r Cymru yn gwybodol yn dodiodd y drosafosibol Cymru a Llyfrgell Gwrsfer. The purpose of the code is to set minimum standards for funeral director businesses in their care of the deceased and related procedures and behaviours. The Delegated Powers and Law Reform Committee considered this document at its meeting on 9 January 2024 and made no recommendations in relation to this document. We will have an evidence session with the Minister for Public Health and Women's Health and supporting officials on this document. Felly, oeddwn i'n gweithio'r ddysgu, rydyn ni'n teimlo i'r ddweud o'r ddweud o'r ddweud. Felly, rydyn ni'n gweithio'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud. Elizabeth Sadler, directoraidd ffasilol o ddweud o ddweud o'r ddweud o'r ddweud o'r ddweud. Joanne Tintall, pwyllfaen, Alexandra Wright, Beryl a'r team yng Nghymru, 50 i ysgol ff gammaenidr o'r Gwrthg Choose yng nghyrweddau, a pob baitio'r gwahanol felly Lатyn. Mae bob ein cynyddon i ddefnydd sy'n colladau i'r Gynnir yn gyfrydau am eich dyfodolillau awog ddweud iawn. Mae hwn cyhoedd понolifeinr, phy infringon a'r hanfer iechyd ac rydyn ni'n bydd ar doutefol ymarfer. Mae hwn ni'n gatheringu certh场 o'i rhoi ddwang 전fainll classmates 잔 â'r hops. I watering figures of over £4,000 for a funeral, which is, and each funeral company can actually set their own fees, so it will hopefully agree £4,500 is a lot of money, but also what's known as paupers funerals, so paupers funerals is something that could be regulated, and the costs do vary and can vary for each area, and I've got some figures that they can vary from over £1,000 to a figure in Edinburgh was £683. My data isn't recent. The data that I've managed to find was in 2015. There were 549 paupers funerals in Scotland costing the public purse half a million pounds, so my question, Minister, is that something that can be looked at? If it can't be incorporated into this, can it be looked at by you moving forward? I took part in a discussion and a number of debates about poverty and death, so it's something that is very much on my radar. I was very pleased to hear at the discussion that I was at the support that celebrants will provide people that may not be able to afford funerals. That's not specifically with regard to this piece of code, but yes, it is something that I am absolutely aware of when we look at regulation and also licensing and things like that. It's also important to point out that the Competition and Market Authority did a piece of work in 2021. As a result of that, funeral directors are now required to have online or available when they are talking to bereaved families the costs of how much a funeral will cost. They are also required to provide any information if costs have changed. It's also important to note that the Scottish Government has got a range of actions to support people in fuel poverty, although that doesn't specifically sit within my remit. I'm happy to write to you to give you that additional information. It's something that I am aware of, yes. Thank you, convener. I thank the minister for her answers there. I've had no indication that any other member wishes to ask questions, so we'll move to agenda item 2, which is the formal debate on the document on which we've just taken evidence. Minister, can I ask you to speak to and move motion S6M-1105? Can I check, convener? Do you want me to read my statement in there or just simply want me to move the motion? As we're moving to the debate on the motion, then to read your statement and to move the motion, please. Thank you for confirming that. I'm delighted to join you today to consider the draft Funeral Director Code of Practice, a significant milestone in the regulation of the funeral sector in Scotland. The draft code has been developed under the Burial Incremation Scotland Act 2016, which provides a modern, comprehensive legislative framework for burial information in Scotland. The death of a loved one will be, for many of us, one of the most difficult experiences we will face. The bereavement impacts on each of us in many ways. Funerals can fulfil a vital role in the grieving process, providing an opportunity to commemorate and celebrate life, but also to acknowledge the reality of loss. Funerals are organised at a time of extreme emotional vulnerability. If things go wrong with the arrangements, there can be lasting impacts. Funeral directors are entrusted to guide individuals and families through this challenging time. They directly prepare the deceased for viewing, burial or cremation, a trusted role with profound significance across cultures and faith systems. It is crucial, therefore, that when a person dies, funeral directors can be relied upon to deliver a highly compassionate, conscientious and professional service, which must maintain the dignity of the deceased and be respectful and sensitive to the bereaved. The draft code introduces minimum standards of care for the deceased and aims to establish and promote a common understanding of good practice. It will also be key to underpinning the statutory inspection of funeral directors in Scotland. It aims to safeguard against malpractice and help to promote continual improvement in the sector, contributing to greater public trust and confidence in the services that funeral directors provide. Specifically, the draft code covers engagement to the funeral director and transfer of the deceased, care of the deceased and the premises used by the funeral director, planning the funeral service according to the wishes of the deceased and the bereaved, delivery of the funeral, dealing with complaints, business continuity and management risk. The draft code has been developed in close collaboration with the funeral industry and other key stakeholders, drawing on their experience and expertise to ensure the intended outcomes of the code are proportionate, pragmatic and justified. The code has been available in draft form on the Scottish Government's website since 2019 and has been extensively consulted upon. In addition to a full public consultation, focused engagement sessions took place with small independent and rural funeral directors. Respondents were generally supportive of the draft code and its intentions. The feedback that we have gathered has been instrumental in refining the draft code. Scotland's two main funeral trade associations are clear in their support of it, which underscores the collaborative spirit and shared commitment to our common goals. Research has shown that the vast majority of people incorrectly assume that minimum standards exist and that funeral directors are already subject to regulation. Worldwide, countries such as Canada, Australia, France, Spain and many states in the USA, funeral directors are regulated and many require both a personal and business licence to operate. In the UK, some headway is being made in the consumer protection space by the competition and markets authority and the regulation of funeral prepayment plans by the financial conduct authority. However, standards lag behind in relation to care of the deceased, which occurs in private areas of funeral director businesses. Whilst many funeral director businesses are already operating to a high standard, some departure from good practice has been identified. The provisions of the 2016 act were largely based on the recommendations made by the Infant Cremation Commission, chaired by Lord Bonomy. That was convened in response to historical poor practice at a number of crematoriums across Scotland, details of which emerged in 2012. In addition, the national cremation investigation by Dame Elish Angioloni in 2016 found that overall regulation of the funeral profession required improvement. Her final report recommended that the Scottish Government should exercise its powers under the 2016 act to licence funeral directors and establish a statutory regime of regulation and inspection. More recently, an assessment of the industry has been strengthened by voluntary inspections undertaken by inspectors of burial, cremation and funeral directors and their investigations of complaints. The current lack of statutory regulation within the funeral sector poses a high level of risk. A minority of professionals can pose a threat due to poor practice, ill health or deliberate malevolence. I believe that the implementation of a code is a vital step to safeguard the dignity and safety of the deceased. In turn, the code should go a long way to instill greater confidence in the funeral sector for the public and bereaved families. The draft code is the first significant step in the implementation of statutory regulation of funeral directors in Scotland. The CMA has recommended that England, Wales and Northern Ireland establish this type of statutory oversight in their own funeral sector. I am proud that Scotland is leading the way on that in the UK. The draft funeral director code of practice seeks to establish a baseline set of professional standards and quality assurance for funeral directors in Scotland. It is not intended to be a burden on businesses. The Scottish Government believes that the standard set-out in the draft code not only protect the deceased and bring confidence to the public and the bereaved but will also benefit the funeral profession contributing to the overall reputation of the industry and acknowledging the unique and challenging role that funeral directors play. I hope that committee members agree that the draft code brings about positive changes to an important industry. With Parliament's support, I look forward to introducing the draft code in its final form to the industry. If approved by Parliament, funeral directors will be given a 12-month grace period to become fully compliant with the code's standards before the code would be formally issued by the Scottish Government and would come into force. I therefore move the motion and propose that the committee recommend that the draft of the funeral director code of practice be approved. I look forward to answering any further questions the committee may have. Do you wish to sum up any member wishes to make a further contribution? I'm content. I think that my opening statement covered what this code is intended to do. I'd like to thank the committee for your consideration. The question is that motion S6M-11905 be agreed to. Are we all agreed? Thank you, the committee is agreed. That concludes consideration of the document. Our meeting next week will be held fully and private to continue consideration of a draft stage 1 report on the National Care Service Scotland Bill. At our meeting on 6 February, we will be taking evidence from stakeholders as part of our post-legislative scrutiny of the Alcohol Minimum Pricing Scotland Act 2012. That concludes the public part of our meeting today.


Stand and sing of Zambia Nice to meet you Nice to meet you too Sorry to disturb you Is it a national anthem? Yes it is South Africa National Anthem, yes? South Africa? No You don't want to look at me, you close your eyes all the time I'm not really comfortable talking to you right now Oh wow, just wow Anyway I heard you singing the beautiful national anthem I'm not from South Africa But I thought you were singing the South Africa National Anthem No it's actually Zambia National Anthem Zambia National Anthem? So do you know that Zambia and South Africa have the same tune as the National Anthem? Are you for real? Come on, even Tanzania has the same national anthem That's news I think I need to sing for you Do you know the South Africa National Anthem? No You are just trying to make me laugh No, that's the South Africa National Anthem God bless Africa Oh I see And then in Tanzania they also have Mungu Ibariki Africa Wow that's lovely So that's the Swahili part But you don't know that both three countries All the three countries have the same national anthem I have no idea The lyrics are different but the same tune Even Zimbabwe Their former national anthem Was exactly the same thing Don't tell me No, even Namibia has the same national anthem Until they go independent Can we just sit down And let me lecture you a bit Because I need to go revisit my history books And tell you the exact same thing Thank you Okay I hope you have your history right I'm going to ask you so many questions You know what? I'm not a history teacher But I'm going to try my best To educate you And so many people out there Keep the ball rolling First question Is that even a question? Africa We are just the same people We are just differentiated by colonialism So The song Was composed by a South African It was actually a Christian hymn In the year 1897 Really? Do you know the name of the guy who composed the song? No His name is Inok Sontonga What a beautiful name And this song became a pan liberation song For African countries Five African countries Wow Five? But what made you think they didn't copy each other? I feel like they don't copy each other Because that's the song that brings unity Among African So Tanzania adopted that song Zambia adopted that song Zimbabwe adopted that song Namibia adopted that song But the song actually became famous in the year 1924 Okay I think I heard the Zimbabwe national anthem But it doesn't sound like ours What do you have to say about that? Don't be confused It's just a new national anthem that they have Which they changed the old one In the year 1994 But when Zimbabwe gained its independence The national anthem that they were using Has the same tune as what In Kosikelele Africa But they changed the language Into Zimbabwe language So it has the same meaning Like God bless Africa But I don't speak Shauna So if you speak Shauna, you can go and check The year 1980, what was the Zimbabwe national anthem Go find out So out of the five countries you say How many countries are still using The same tune as ours? It's just three Zambia your country Tanzania and then South Africa Wow Zambia, Tanzania, South Africa So Namibia was using exactly the same tune The same lyrics of the South African national anthem Until they gained their independence in the year 1990 So March 1990 There was a contest in Namibia To what There was a new national anthem One person from the country I don't remember the name but he won And his tune Became the official national Anthem for the country Namibia So you see, Africa They are just the same people So if you don't know that your national anthem Is the same as South Africa Tanzania My sister, you got a lot to do Thank you so much for enlightening me I enjoyed it I think I need to Educate my fellow youths in Zambia About it because I doubt if they know All about that So I'll definitely You're making me feel like a historian It's just that I got to know this Traveling within Africa So when I came to Zambia it was the first time I got to know that Zambia national anthem Actually have the same tune as South Africa And what, Tanzania I also don't know, I keep on Learning anywhere I go to But hey, you know what I would love to sing the South African national anthem I'd love to sing I'm looking forward to that Can we sing it right now Of course we can Do you know how to sing that one I can try Okay, one, two, three Ready? Okay, here we go


This paper presents a novel approach to developing a decision-making guide for families and healthcare professionals who are faced with difficult decisions regarding eating and drinking for patients with severe dementia. Through a systematic review, interviews with family carers, healthcare professionals, and patients with mild dementia, as well as co-design workshops, a decision-making guide was created which provides a framework for making informed decisions based on patients' values and preferences. This guide has been successfully implemented in English hospitals and is currently being evaluated for its real-world impact. This article was authored by Kandiyan Antipong, Andrea Brun, and Walford, and others.


So we're here with Sinoware, and who are you? Yeah, I'm the CEO of Sinoware. And here you have POS solution, right? Yes, we have a POS solution based on Android system. OK, here you see that all the system is Android-based. You see? It's Android-based. So here what we show here is the cloud-based POS solutions. Why we use the Android as the POS? Because with the cloud computing coming to the market, so traditional, when we use the Windows inter-solutions, it's too heavy, maybe. So right now, based on the cloud, we just needed some sync line. Sync line means we can use the smartphone and tablets as the POS system. So here what we show here is the cloud-based POS solutions. We have this traditional station also based on the Android. OK, with dual screen, dual touch. OK, they have a different touch. Right now, we are using this station as the server. So that means in case of the internet is down, the system can still work with this machine. OK, so right now, we have different devices connected to this station. Through this station, we connect to the cloud. For example, this is what we call an email. We put on a custom table. So people can order the food. OK, for example, we can order different kind of food, food, custom can order. Right? And this is waterproof? Yeah, this is the industry standard. We call it IP54. It's the water and the dust proof. OK, so you see that right now, we say this table is 0.05, table 5. So when we order the food here, so all this information will transfer to all the cashier, all the station, all the tablet. Even for example, we use this smartphone as the order terminal. You can use a QR code on here to use this if you want. Yeah, we can use that. We can use the QR code I will show you later. So for example, here we have the table 5 as well. So we have a new order. For example, we order some food here. So then when we update here, you see the price is 12, 7, 8. Here is change. Let's see here, we have the table here. So you see the price here. OK, this terminal also have the same thing. And here, it goes through the card. Yeah, it goes through the card. Then you can check all the status. For example, we see that table 5, you check the order here. You see that. OK, if in case somebody change added some dish here, for example, we change here when we update it. So you will see all the machines get changed. You see that this one get changed. And also you will see the readout here. You can have a noise, a sound go off. Yeah, for example, somebody, I want all the tell me, for example, we have other sounds called notification solutions. Notification, yeah, that's the exact number. Maybe the waiter can also have a phone in the pocket. So we can order, they call it middle water. OK, so customer can order any services they call. OK, please wait. Nice, nice. So let's go away. Yeah, OK, here I would like to highlight one station here. You see our device, you can hold. Take it and put it to the customer. What is this payment? OK, this is a payment. OK, let me show you how we do the payment. Do you have contactless also? OK, yeah. So that's the exact number. We can do that for them payment. OK, so you can have a... Is that a real credit card? Yeah, it's a real credit card. You see that there's... Oh, don't show the number. Yeah. You see that all the information is showed here, right? It's not done everything. Yeah, and also for them, we can have a... You can do the, for example, the magnetica as well. Yeah. You see the magnetica as well. And finally, I would like to show is... We can NFC as well. NFC, yeah. You put it under. Yeah, under. OK, you see the NFC walk as well. And past that, we have 2D-bowl cooking. So which can support Google Pay, Samsung Pay, even Alipay, Vechar Pay. OK, so all is integrated together. It's one devices, OK? When you put it on the docking station, if I see what I... There are all the interface here. Oh, there's a lot of stuff going on here. Yeah, you can have this, that, casual control, USB, and the IC232. The same design is here. So, you see, we can have a different order here. Show the price there. Yeah, we can add different things at a different price change. And if you turn it on, you will see. You can have it when you ask. Wow. Cool. And the connect here with... Yeah. When you put it on, then it's connected. Then you have an interface here. So you already sell millions of devices, what? Yeah, we have a very good sales in Japan, both in Japan and in Korea. Japan, they are very advanced with this kind of thing. Yeah, it's a very tough one, but we already have very high-quality devices. Should the big companies in Japan and Korea, right now, we are getting into... What about India? Not yet, OK. They're welcome to contact, right? Yes, definitely. America, US? Definitely, yeah. Already have big sales there? No, we have a study to sell in the US and the Europe as well. Because this is potentially big, right? Yeah, I think this is a good opportunity. You see, like I mentioned, this is a new POS working with the cloud. That's our solution. What's the CPU, is it secret? Yeah, no, CPU, we are still using the so-called vertical CPU based on free-scale IMAX 6. Yeah, it can be the industrial grade or the... Long-term support. Long-term support. The lifespan can be more than five years. Do you want to do IMAX 7? Yeah, this is the project we are developing now, OK. All right, and you do all the cloud-based solutions. So you have... Where's your engineer? Where's your company? Yeah, our company's headquarter is located in Nanjin. OK, we are more than 50 engineers working on this project. You see, based on these solutions, we also have digital signage for the Malkai media, for the media advertisement. And we also have a video camera, not only for the audit, the monitoring, and also for the data mining, because we don't know, we can know how many people already visited this restaurant and what's the age and male, you know, female, et cetera. So we also have the other support, like a kitchen monitor, kitchen printing, printer as well. Waiter app, it goes to the application on the phone. Yeah. It's just a phone. Just a normal phone. No need a special... No, no, no. But you also make a portable device to do the payment, Yeah, we also can do the support. But now, using a phone, you can easily do the support, just like Apple Pay, Samsung Pay, Ali Pay, et cetera. So... Nice, easy to support. Easy to support. And what's the price for all this product? OK, we have actually the price. What we do is, we want to produce the high quality, very decent price, OK. So like, for example, this set of the device is between, it really depends on your configuration, between 300 to 500 USD. So not too expensive. Not so, yes. Cheaper than the iPhone. Definitely, yeah. Much cheaper, OK. Cheaper than the iPhone. Yeah. If I follow, I will not make more business. Yeah, this is different. Maybe you will make a million dollars more. Yeah, yeah, this is a good idea.  So you can check everything online. I want here to be a security camera integration and also case recognition. If you want, every time you come back, the restaurant know you there. They know what you like. They already send you what you want. Yeah, that's a good point. We call it IoT, the Internet of Things, right? So you see the video already integrated in our system. They can identify, OK, to see who is coming again. So then we can know. Maybe the voice in the restaurant can say, welcome back, Jack. Why not? If they want, if the user is coming many times, you can say, I want this. And he gets special discount. Definitely. That's a really good point. So that's why we try to integrate so-called next generation internet, like IoT, Internet of Things, Mobile Internet, Cloud computing, and data mining. So that's all we call in the next generation BOS system. Every store, every restaurant need to buy this now. Yeah, definitely. Please contact us. But who's the leader in the world for this business? OK. Some companies very big? No, that's not true. OK, because right now, traditional one can begin to transfer to the next generation. So everybody sit at the same level. OK. Everybody at the same level. Everybody is trying new technology. But nobody is a leader. Big one, yeah. Nobody is very, very big, yeah? No, not yet. OK, so what we know is right now, in the US, there are a lot of venture capital trying to invest money. Square. Yeah. No, square is right now, it's not the same. There is some other very famous startup company. You know, in Silicon Valley, in Boston, et cetera. Right now. You don't have this kind of device, square? Not yet, not yet. So maybe you can work with them? Why not, right? We really wanted to work with all the software company. PayPal. Yeah. Work with PayPal. PayPal, et cetera, yeah. Cool, OK, I don't want to get too many secrets. Yeah, OK, thank you so much. It's so happy to introduce our other clients, introduce Sanwell. Cool.