Bill Curtis with Consortium for Information and Software Quality

SUMMARY KEYWORDS

software, weaknesses, omg, iso, standard, put, industrial, fix, measure, security, bad, technical debt, cost, problems, bill, work, curtis, company, digits, iso standard

00:03

Welcome to the Industrial Talk Podcast with Scott MacKenzie. Scott is a passionate industry professional dedicated to transferring cutting edge industry focused innovations and trends while highlighting the men and women who keep the world moving. So put on your hard hat, grab your work boots, and let's go.

00:21

All right, thank you once again for joining Industrial Talk. We are broadcasting on site right now OMG, the q1 meeting here in Reston, Virginia. And you're listening to Industrial Talk, the number one industrial related podcast in the universe that celebrates industry professionals all around the world. You are bold, you are brave, you dare greatly you innovate. You solve problems. I say it all the time. That's why we celebrate you on this particular podcast because you are the hero in this particular story. All right. He's been in the hot seat before, he doesn't disappoint. Bill Curtis is in the hot seat. This time. We're gonna be talking about ISO 5055. I hope I got that. Right. You got it? Right. Check it out. All right, let's get cracking with the conversation. You having a good meeting? I see. It's not a conference. It's a meeting. It's

01:12

a meeting. Yeah, because we're getting some standards through that are pretty critical. Like for software bill of materials, best bombs, bombs, bombs. Yeah. And then in response to the President's initiative on cybersecurity. And this was a big piece of it to get past bombs used by anybody to submit software to the federal government. So we know what's in it.

01:36

Before we get into that, because I have so many questions. Take us through who you are all sort of establish. Alright,

01:44

well, I'm Dr. Bill Curtis, probably best known for leading the effort to build the capability maturity model at the SEI back in the early 90s. Which means in the Agile community, many consider me the great Satan. But, but it actually made a great difference. And they're actually suffering from some of the problems we tried to solve, which is people throwing require additional requirements. And once you've got your plan in place, and you're throwing everything out of kilter, it happens all the time, it happens all the time to this day, it happened, it's a major reason for poor quality software, because you got running too fast, you didn't have time to, to fix things, you got tons of technical debt, you know, you're gonna have to fix someday. It's just it's a mess. And agile had a way to stop that, which is the use of the frozen stories for this sprint until the gaff or marketing or the business comes down and throws more requirements in and says no, no, you got to do it, we have to have it for competitive reasons, and blah, blah, blah, I'll go straight to the CEO, the old chain. And so it really puts the onus on executive management to protection to say no, these guys have a frozen set. And you can put that in the next one if they don't have policies for both protection and for removing technical debt later is never going to happen. Did you say technical debt technical debt? Yeah. So one of the my, the thing I do right now is I've been in the software industry since the late 70s. And one of the the efforts right now is the Consortium for information and software quality, which builds standards for measuring software. And we also sponsor reports and we sponsor a report called the cost of poor quality software, which is redone every two years to look at what's the latest data felony herb crasner goes through about 130 different sources of cost data, which is cost for outages cost for what it you know, maintenance costs, migration costs, and modernization costs and all kinds of things that that you have to pay for because the quote, quality software's bad and it's terrifying what numbers he comes up with, based on these public sources. And you know, it's like one and a half trillion dollars this last time. Oh, my God, that's a chunk, huge chunk of the national national. What am I looking for the product productivity? It's just it's it's a hell of a, you know, the national product and actual product. Yeah. And it's, yeah, it is. But it's a drag on productivity. And it's sitting out there. We're in the era of nine digit defects. And by nine digits, I don't mean bits and bytes, I mean, dollars and euros. Right, so you're looking at some of these things like if an airline has their their reservation system go down so people can't get their tickets to get on airplanes and they can't fly the airplanes you know, they're looking at they're looking at nine digits if they have to go two days. You can look at what's happened to some of these airlines experience look at what happened to them because the cost would wouldn't directly an experience it was in all the credit card problems they created when all that stuff Got stolen. And now they're gonna get sued by the credit card companies for the expenses. And then repairing all that and putting everybody on on, you know, free watch for all the problems they could have. The one of the worst was night trading, which is a high speed on on, you know, high speed trading company on the stock market. And they had an update that accidentally activated some dead code because they had a lot of dead code they hadn't removed and it made $440 million of bad trades in 30 minutes. They were bankrupt. Right. So you, you look at something royal, RBS and England had a bad update and the kid when he tried to back it out and ended up screwing up all the data, all the customer files, and you know, Brits 22 million Brits couldn't get to their their bank accounts for like three weeks couldn't pay mortgages. Yeah, it was just it, they estimated the initial estimate was 175 million pounds. Figure that out. And dollar eight was probably worse. So you're looking at some of these outages. Now some of these online problems costing in the nine digits, and we probably have a few that may be in the 10 digits. You know, the the one that broke into all the networking systems. And that one was that when they can't do it, they're not not sure that government will ever get all that stuff out

06:25

a couple of great points. I like that technical debt. I like the term that cost of poor quality software. Yeah. Because I don't think that we really truly understand that I think people understand the pain. They know it, they know that it's it's clunky or cumbersome or don't do this because when I did it one time it did. They know that it exists out there.

06:47

But to be able to quantify it, well in herds, huge herb crasner, when he built that report, goes out and looks at all these public sources. He's not sitting here, just guessing. Now, some of those public sources are probably estimates, but they're probably reasonably based. He looks at so many of them, he gets a good sort of broad picture of what's happening. He kind of triangulates down on costs in different areas like outages, excessive maintenance, and technical debt and things of that, that nature, security breaches. And they pulled it all together. And when he puts that data together, it's staggering. What he comes up with.

07:23

All right, now I want to curl up in a ball. Yeah, well, I, I don't know where to start, you know, you always want to say, well, what's the solution? We

07:34

take your money out and put it onto your mattress?

07:38

Talk to us a little bit about ISO.

07:39

Yeah, so 55. The issue in most of these cases was a serious problem in the software, some some weakness, some glitch, that allowed a bad thing to happen, whether it was a crash, or a security breach, or serious degradation in performance or whatever, or just makes maintenance, a nightmare. So we got 75 experts together in the US and Europe and India, and really went through all this and said, What are the worst, most serious weaknesses, you know, you have to get out of the system. If it's something you can leave in there for years, that's fine, we don't care about it. We care about stuff, you know, is going to cause a problem if it gets activated, and you need to get it out now. Because it's a problem in either reliability, security, performance efficiency, or maintainability. We we actually had executive meetings in Washington, DC and Frankfurt. And in Bangalore, we brought executives in from from Europe, from India, from North America, and said, What are the quality issues you're most concerned with? And those were the four that came out in every meeting, the top four that they wanted to dress reliability, security, performance efficiency? And maintainability maintainability? Yeah. So we, we went and started identifying the weaknesses that caused the most serious problems in those four areas and put them together into measure. So the measures are simply counts of the number that are in your system, the number of those weaknesses. And then you can, you can normalize it by dividing by your favorite size measure, you know, where there's lines of code or function points or cosmic points or whatever. And come up with a normalization, or you know, any other way that you can, you can find out but that way, you can start comparing across systems to see where your worst problems are. So those became OMG standard. We put them through the OMG process, they were formally defined in terms of OMGs metamodels. And then we initially it was only for business software. And then there was clear demand for let's expand that to embedded software because that's critical and avionics and medical devices and whatever And so we we expanded it to things that you would find in embedded problems and put all that together and there was a request, let's put all those weakness all those four measures into one standard. So we did. And OMG has a prawn has a quick way to get standards to ISO called a publicly available standard process, which means Oh, it is Oh, poor me ISO trust, that OMGs process is rigorous enough that they can trust the standard. And so if it's publicly available standard through OMG, we can submit it, if they approve it, then it becomes an ISO standard. And so we submitted this one that has the four measures in it, and it became the formal title is ISO slash IEC 5055 colon 2021. Good for them. Yeah. So but we just called ISO five of five. And until it became a stencil companies are starting to use it to say, Okay, what do we want to hold our people, third party vendors, our suppliers accountable for in terms of the software they deliver to us, because you're fed up with getting software that has problems that breaks that have security holes, and what have you. And so this is a way you can say, Look, this is going to be part of our acceptance test. And here's some, you know, you can set whatever thresholds you want, you're not going to get zero. But because the cost is just exorbitant, but you can set thresholds say, Look, you can't hit you have to have at least you know, be below this density of weaknesses per 1000 lines of code, or something of that nature. Or per 100 function points or whatever. And are, you can say, here are certain weaknesses you may not have in the software, you can have SQL injections in the software, and other kinds of things that you know if a hacker finds it they're in. And so you can set both thresholds and thou shalt nots and and use that as acceptance criteria in your contracts with suppliers of software, the software you're going to use, or check open source, because what a lot of applications 70 presented since open source, and you want to make sure that what you're bringing in is not going to put you at risk. So this at least list things you ought to look for, you can look for more than we list if it's if it you think it's serious for your kind of application, or your kind of embedded system. But here's the starting point. We know these, and there's general agreement, these are things you shouldn't have in software.

12:35

So I have an existing, I have an existing application of software. And I know there's some questions here and there. Can I take this standard and then be able to do something that is sort of more, I hate to use, I'll use it brownfield as opposed to Yeah, yeah, the Greenfield type of absolute, you know, just, it makes sense. In the beginning, you want to be able to nail it down, right, you're getting but but there's so many existing systems out there

13:05

well, and and that's where serious static analysis technology comes in. And you want it to be able to deal with the system level, not just the code level, but the system level. So because a lot of the about a third of these weaknesses involve system level interactions between components. Now people that skip skip layers, with called make that just makes maintainability a nightmare. Or they skip around the authentication routines, which is a massive security breach. So there's all kinds of things that really do affect. So you want system level, and there's a couple of the sponsors of CES cast and Coverity both have serious technologies for doing that I worked for CAS so I know our, our technology and where we are, have spent a lot of time being able to identify and detect a lot of these, in fact, moat the majority of these weaknesses, Coverity has been going after the same sort of thing. So you've got technologies like that, they can go and do the static analysis, identify what the weaknesses are, and then you have to prioritize because you can't fix everything. So that becomes an executive decision or management decision. You know, what are we going to prioritize as security, the most important thing is you how important is maintainability for this component or for this system, and then make those priorities and then, you know, protect time that your developers need to fix it. Because if you don't protect the time, it's never going to get fixed because a business is going to be constantly running down the halls exactly what the next you know, you got to do this now. And and the software degrades and degrades and degrades to where it's a nightmare to fix anything. So if you don't fix the software, it becomes a serious limitation on organizational agility.

14:51

You mentioned that company so that company is able to provide the solution or service to be able to analyze Your, your software, you have to say, Okay, we've done this. Yeah, we've looked at it. These are the the the areas of challenges, then it's up to the client to say, that's number one. That's number two. But there is there an interaction between you and the client saying, we recommend this being number one, just because it's a security. Well,

15:23

a lot of companies work with third parties. outsourcers security companies, whatever, and they provide the service, you know, we provide the technology can also provide the service. But we work with partners who are service related, and that's their business. So they can work with the company to identify the weaknesses they want to fix, and then help them get them fixed. So it's, you know, there's all all kinds of approaches they can take.

15:57

Now, this is a, this has already been published, it's out there. Yeah, it's free, free days

16:02

free. Here's the warning. That if you go, if you go to the website, guys a website, and if you list it'll take you the website, and you can buy it for a bunch of Swiss francs. But at the bottom of the page, there's a link, you can click that takes you to the free when the publicly available standard. So you know, go for the free, when could I go to OMG, you can go into OMG. And it's on the OMG website is automated source code quality measures, ASC QM is the is the catchphrase. And you can get it free from OMG. I think we have it on the Cisco website as well. Well, it would make sense yeah, yeah.

16:46

What What fascinates me a little bit about this is going to be the responsibility now of OMG. Team OMG. To make, keep this ISO standard up and changing and, and and then resubmitting an update. And that's that's

17:03

exactly responsibility. And in fact, the publicly available standard process with high is always one where they rely on whoever submitted the standard to keep it current, keep it updated ever so often. And we are in the process now of updating it, we've expanded to have the weaknesses, to some issues that people were very concerned about, we took the security standard, we upgraded it to data protection, because your other weaknesses we wanted to bring in. So we do have a data protection standard. So if you're looking at GDPR, or the PCI, or the California, you know, there's all kinds of standard Regulations now. And another one, we took the performance, the performance efficiency measure and the reliability measure, and pulled out some weaknesses and upgraded that for resource sustainability. Because in Europe, they're working on regulations. Now for sustainability, we'll probably see the same in the US at some point. And so you've got sustainability issues that are how the how effective the software is in limiting its user resources. In addition, if it crashes, if there's a liability problem, you've got all this energy to reboot everything, which is an excessive use of energy, so So those are two and we're now adding those in is annexes into ISO 5055. So that that's in process, it's not out there yet, we're going through the process and making a submission. So we'll see, as we come up with these additional measures on top of the ones we have, we'll submit them as annexes to 5055. I like

18:45

I like free. I like free to I like free. Know how to people get a hold of you, Curtis

18:51

at ACM dot orgy.

18:55

Do you do anything on LinkedIn?

18:57

Currently, well, my profiles on LinkedIn various. So do that, too. I don't do a lot of posting. The other thing we're doing, by the way, is because this is an issue for developers. code quality isn't the issue for developers as well as quality assurance. We're building a certification exam, test your knowledge of the weaknesses in ISO 5055 to make sure you know how to avoid them, how to identify them, how to remediate them, how to fix them. And so that's, that's a year at least a year away. So I see. But it'll be a certification through OMG.

19:33

Yeah, see, as long as there's a process to keep things current and exactly the date and, and I can trust. Yeah, trust what's going on there. And it's not static. It's more dynamic because the world is dynamic. Exactly. So I do like it. Thank you very much. My

19:46

pleasure. being here. Thank you so much.

19:49

All right. Let's just we're gonna have all the contact information for Bill out on an Industrial Talk. So make sure you connect with this gent because you will not be disappointed. He knows more than you. Just FYI. All right, we're gonna be wrapping it up on the other side. Stay tuned, we will be right back.

20:04

You're listening to the Industrial Talk Podcast Network

20:15

Bill Curtis is his name. I'm telling you right now, if there's somebody that you need, this is your call to action. If there's somebody that you need to reach out to, here's this sage, this incredible professional, who definitely understands what's going on out there in the market. A must connect, make that happen all out on Industrial Talk, as it is always out there. ISO 5055 and we're talking about software quality standards. And yes, you need that to the event was OMG Q1, Reston, Virginia. Anyway, here it is. Reach out to bill that your call to action. Industrial Talk is here for you. I say it all the time. You have a podcast, you need greater attention, put it out on Industrial Talk. It's just it's about getting that information out there so people can learn and be successful industrial information. People will be brave dare greatly hang out with Bill change the world. We're going to have another great conversation shortly. So stay tuned.