Episode 130
How to Design Quality Software w/ Linda Westfall
Linda Westfall is the President of The Westfall Team and one of their lead consultants and trainers. Her specialties include Software Quality Engineering, Metrics, Project & Risk Management, Requirements Engineering & Management, Peer Reviews, Testing, and Process Definition & Improvement.
Prior to starting her own business, Linda was the Senior Manager of Quality Metrics and Analysis at DSC Communications. Linda has more than forty years of experience in real-time software engineering, quality, project and risk management, agile, and metrics. She has worked as a Software Engineer, Systems Analyst, Software Process Engineer, and Manager of Production Software.
Linda and her husband Rob also have an active fireworks hobby.
https://www.linkedin.com/in/linda-westfall-668191/
https://www.softwareexcellenceacademy.com/
https://asq.org/quality-press/display-item?item=H1516
Mentioned in this episode:
LammarMarie.com Buy 1 Get 1 50% Off
This episode of the business samurai podcast is brought to you by Lammar Marie popcorn. You can get now one bag and get a second bag for half off with the code Barker at checkout. So if you like your snacks, a little sweet, a little salty, a little mixture of both. Go check out lammarmarie.com and all of the flavors that they have for your next snacking sensation. That is lammarmarie.com with code Barker at checkout for buy one, get one half off.
Transcript
Welcome to the business samurai podcast.
Speaker:I'm your host, John Barker, excited to have a guest today in a subset of a
Speaker:field that I know almost nothing about.
Speaker:From a software perspective, I have Linda Westfall.
Speaker:She is the president of the Westfall team and one of their
Speaker:lead consultants and trainers.
Speaker:Her specialties include software quality engineering metrics, project and risk
Speaker:management requirements, engineering and management peer reviews, testing,
Speaker:process, definition, and improvement prior to starting her own business.
Speaker:Linda was the senior manager of quality metrics and analysis
Speaker:at D S C communications.
Speaker:Linda has more than 40 years of experience in real-time software engine.
Speaker:Quality project and risk management, agile and metrics.
Speaker:She has worked as a software engineer systems, analyst,
Speaker:software process engineer, and manage your production software.
Speaker:Lyndon, her husband, Rob also have an active fireworks hobby, which I
Speaker:definitely have a question or two about that toward the end of this Linda really
Speaker:appreciate you taking the time and reaching out to me and let's have some
Speaker:discussion on quality software management.
Speaker:Thank you, John, for letting me join your podcast.
Speaker:Absolutely.
Speaker:Prior to us, we, you were starting to dive into the background about
Speaker:the, the the scope of ASQ and quality within software engineering.
Speaker:And it's a smaller scope and not familiar with, because my experience
Speaker:with something like lean six Sigma, when you talk about manufacturing and
Speaker:you got standard deviations, somebody has got this pin here and only so
Speaker:many of these can fail before they get to look at the process or redefined.
Speaker:Can I get into you I guess your background with this from a software
Speaker:perspective, because that is be honest with you after 20 some years of it
Speaker:experience relatively new to me.
Speaker:One of the things that is a big difference between software quality
Speaker:and manufacturing quality is we don't focus on replication by the time you
Speaker:get it, it's already been designed.
Speaker:Those designs have been vetted as it were validated verified, and
Speaker:you just replicate the process.
Speaker:So you're building that pin a million times and you can look statistically at
Speaker:how many failures you have, how many pins are warped or don't have a cap or whatever
Speaker:out of millions in software, you really don't have a major issue of replication.
Speaker:Now it is important in that, I can make a million copies of the CD.
Speaker:To send to somebody and, yes, there's a potential of failure and yes,
Speaker:you need to sample once in a while.
Speaker:But the primary focus of software quality is the design and development side.
Speaker:So how does it, is this something that comes from, large very large programs,
Speaker:or is this something, if somebody comes to you and they say, Linda, I
Speaker:got this idea for this really cool app.
Speaker:And I want to build, because we're in a software as a service environment,
Speaker:everything is a subscription that we have to deal with nowadays.
Speaker:Where do you start engaging with somebody that is it something
Speaker:that's been out in the market space?
Speaker:A Microsoft has got millions and millions of users, or is this
Speaker:something that starts from infancy?
Speaker:And the answer is yes.
Speaker:Okay.
Speaker:Really honest with you.
Speaker:Any software that you were building has the opportunity
Speaker:to have defects in it when you.
Speaker:You write the code incorrectly.
Speaker:It all starts with getting the right requirements for the product,
Speaker:from your customers and knowing what the customer's needs are.
Speaker:And then building a software product that actually meets those needs.
Speaker:As I said, our main focus is on the research and development.
Speaker:If we're going to use the software again, we just replicated.
Speaker:It's not, we call it reuse.
Speaker:So we do something like, oh, here's a driver for running a printer.
Speaker:We just use that same driver over and over again.
Speaker:And multiple different pieces of software that brings quality with it because
Speaker:over time the defects are shaken out.
Speaker:And, the main issue, like I said, is when you build it, you make a mistake.
Speaker:That mistake turns into a defect in the code.
Speaker:And if you encounter that defect during operation of that,
Speaker:Then something bad happens.
Speaker:A failure happens.
Speaker:The wrong screen comes up.
Speaker:The wrong button is indicated.
Speaker:You push a button, that's supposed to select one thing and it
Speaker:accidentally brings up a different screen all the way to the point
Speaker:that software can kill people.
Speaker:And it has.
Speaker:So how do you go about identifying I going w what is the workflow process
Speaker:look like on your end to try to either prevent, the bugs from emerging and
Speaker:before it gets released and then post release, what's your workflow?
Speaker:What's your process look like?
Speaker:When I talk about the different areas of software quality, I talk in my
Speaker:book, I've actually written the book on the certified software quality
Speaker:engineer, which helps people get ready for the exam from ASQ to become a
Speaker:certified software quality engineer.
Speaker:I actually chaired the effort for six years of my life to make that happen.
Speaker:And we built a body of knowledge around.
Speaker:So I like to think of it as six major areas.
Speaker:First of all, there's the software quality management, which is all
Speaker:about setting your policies, defining your standard operating procedures,
Speaker:also called processes, your work instructions at the organizational level.
Speaker:And then you mentioned you were project manager.
Speaker:You take all of that, which is what usually works best in your organization
Speaker:and tailor it down to the project.
Speaker:For example, you'll have a standard process for conducting peer reviews,
Speaker:but your project plan says on this date, we're conducting this peer review of this
Speaker:type and these people are going to do it.
Speaker:So you have your planning documents on how you're going to implement
Speaker:the quality management system as part of your project plans.
Speaker:That's all, but the management of quality, the planning, the establishing
Speaker:of the policies and procedures.
Speaker:Then you have the, what I like to call software quality engineering, which is
Speaker:defining those processes in detail, the associated work instructions, creating
Speaker:your templates, your training, making sure that people know what to do and
Speaker:how to do it when to do it and who to do it with and all that kind of thing.
Speaker:You've heard about designing for manufacturability.
Speaker:This is what's happening to goods.
Speaker:Good processes create good products.
Speaker:Correct.
Speaker:So the quality engineering is all about defining those and then
Speaker:continuously improving those.
Speaker:That's the engineer, software engineering part, the software quality assurance is
Speaker:all about making sure you're following your processes and products and processes
Speaker:and work instructions and policies, and that they're working for you.
Speaker:And this is typically your software audits, your software.
Speaker:Where people are making sure that the pro that the processes are
Speaker:being followed, looking for areas of continuous improvement, reporting
Speaker:both of those back to management.
Speaker:Can I interject there real quick?
Speaker:Are you talking when you're talking about audits and reviews, if you were using
Speaker:an agile process where you're releasing new code every couple of weeks and like
Speaker:in a two week sprint cycle, is this somebody sitting there signing off and
Speaker:going, yes, this button does what this button is supposed to do this interface.
Speaker:That's not there.
Speaker:Okay.
Speaker:Audits and reviews of just the procedures.
Speaker:Again, the process as well as the product, both.
Speaker:Okay.
Speaker:But the product from a standpoint of, does it meet its workmanship standards, for
Speaker:example, does the code follow the coding standard and the naming conventions?
Speaker:Does the ha is there an appropriate header with all the
Speaker:information, that kind of thing.
Speaker:What you're talking about is the VNV activities, which are making
Speaker:sure which are very product focused.
Speaker:Okay.
Speaker:The assessment can be product or process or even quality system told you this
Speaker:was an area I wasn't familiar with.
Speaker:The VMB is verification, making sure the product matches its
Speaker:requirements as specified.
Speaker:Okay.
Speaker:So through peer reviews, through testing, through static analysis
Speaker:and other techniques, we look at the software focused in, on the product,
Speaker:making sure it does, like I said, if it says this button should do this,
Speaker:we in testing, push that button and make sure it does that's verification.
Speaker:Does it meet its requirements?
Speaker:Validation is, does it meet its intended use?
Speaker:And this is going back to things like user acceptance testing or looking
Speaker:at, are the requirements even.
Speaker:Are you building the right product versus did you build the
Speaker:right product, the product right according to its specifications.
Speaker:So verification is you built it right according to the spec, you
Speaker:followed the requirements and build them all in versus validation.
Speaker:Is that spec appropriate and good to meet the user's needs?
Speaker:And does it actually do what the users need it to do?
Speaker:You've probably gotten software that where somebody misinterpreted
Speaker:the requirement or misinterpreted what you asked for, and it doesn't
Speaker:do what you expected it to do with.
Speaker:That's has happened probably on a time or two in my past, particularly
Speaker:with a lot of custom programs that I have been involved with the government
Speaker:before was like, oh, that's not exactly what we talked about when they
Speaker:went through that user story period.
Speaker:And somebody didn't write something down the right way, or I said it
Speaker:wrong, or somebody on the team said two different interpretations.
Speaker:Can you talk?
Speaker:I have a whole list of words that say, don't put these
Speaker:words in your requirements.
Speaker:I guess speaking of that, when you're going back to defining the requirements,
Speaker:what is the best way to approach getting those requirements to find so they can
Speaker:actually be built out the way they need to be talking about the words they like
Speaker:your do not use words, but what's the best way to approach that with new?
Speaker:The best way is to communicate and talk to your actual users.
Speaker:The first thing you have to do is identify who all your stakeholders
Speaker:even are, because if you miss a stakeholder, you miss all the requirements
Speaker:associated with the stakeholder.
Speaker:I can tell you a story about that.
Speaker:From early in my career, I was doing energy management and
Speaker:building automation software, and.
Speaker:Our customers was a big energy park and they wanted a billing system added
Speaker:on to their energy management system.
Speaker:So that cause they got one electric bill for the whole park and they
Speaker:needed to slice and dice it and send energy bills to various customers
Speaker:based on certain parameters.
Speaker:And I talked to my customers and I did all the good practice in the industry
Speaker:and built this system and installed it.
Speaker:It was a Minneapolis, Minnesota in January.
Speaker:So we installed in about a half an hour.
Speaker:Everything's good, but I'm there for the weekend anyway.
Speaker:So I offered to enter the database because I knew the guy was a one finger typist
Speaker:and it was going to take him forever.
Speaker:And so he dictated and I typed and we did everything was working beautifully
Speaker:till we hit the American red cross.
Speaker:Now what's special about the American red cross and a billing.
Speaker:All of their donations, their sales tax exempt debt is correct.
Speaker:Yep.
Speaker:And most, yeah, never even thought.
Speaker:And of course he says, where's the field to make them sales tax exempt.
Speaker:And I said, you never told me that was a requirement.
Speaker:Duh, it was always a requirement, just because he didn't state it, it wasn't
Speaker:built into the, it's like the analogy I used is somebody sold you a car
Speaker:that had every requirement you asked for, but it didn't have a steering
Speaker:wheel because you didn't ask for that.
Speaker:Might it's not a car.
Speaker:If it doesn't have a steering wheel, it's not a billing system.
Speaker:If you can't make your customer stay at your sales tax,
Speaker:exempt customers, sales tax.
Speaker:And that's something I've seen.
Speaker:I've seen that over the years where you either get particularly with I'll
Speaker:call them decision-making stakeholders.
Speaker:They either don't want to take into a, we don't need to talk to them or
Speaker:they have no clue what's going on, but because they hold the purse string, they
Speaker:want to, just dictate all the stuff.
Speaker:And it's Hey man you're not the one using this day in and day out.
Speaker:Here's where we're talking to the end user experience.
Speaker:We're talking to the people that are going to have to use this day in and day out.
Speaker:How do you approach those situations to make sure you get
Speaker:it crafted the way it needs to be?
Speaker:I actually, like I said, first of all, you've got to identify, brainstorm,
Speaker:bring those key decision makers together and have them say who's impacted by the
Speaker:system who does this system influence, who might need to have, because the
Speaker:charity is not a direct user, right?
Speaker:They're an indirect user.
Speaker:Yep.
Speaker:They're going to get the bill.
Speaker:So who, you ask questions like who all is getting the outputs that are, if
Speaker:I talk, if I'm building a pant, the gas pump system, I gotta think about
Speaker:the state weights and majors lady.
Speaker:I got to think about the accountant.
Speaker:Who's going to get the reports and do the sales tax.
Speaker:Who are the other stakeholders, besides just the customers and users.
Speaker:And even the developers are stakeholders because, requirements
Speaker:about reuse and portability and those maintainability are all part of the
Speaker:requirements of a software system.
Speaker:So first you gotta identify all your cus its stakeholders.
Speaker:And then I say, okay, here's your choices.
Speaker:You gotta include them, but you're going to go interview them.
Speaker:You're going to bring them together into a group, a focus group, or a facilitated
Speaker:requirements workshop, or what.
Speaker:Those are the people you're going to talk to.
Speaker:Then there is the like to includes if I have time and there's
Speaker:never enough time, but sometimes you can get to some of those.
Speaker:If not, you've got to figure out how to do, take your Mustang includes
Speaker:and find out the information about the light to includes and those that
Speaker:you can, you're just going to ignore.
Speaker:For example, if you do a pay at the gas pump system, you have the vendors
Speaker:that are trying to sell you Slurpee syrup and candy bars are going to
Speaker:impact be impacted because if the people aren't coming into the store,
Speaker:they're not buying those things, so what are we going to do about them?
Speaker:I'm not going to go talk to the Slurpee salesman to gather software
Speaker:requirements, but I can talk to the manager or the owner about what do you
Speaker:want to do in the, about the potential of, no, you may have a requirement that
Speaker:the back of the receipt has coupons.
Speaker:Or you may have a requirement for advertising out at the pump.
Speaker:They're doing that now and it drives everybody crazy, but it may bring some
Speaker:percentage of people in, especially if it's a sale or something like that.
Speaker:So you got to think about all those different stakeholders, then
Speaker:you elicit all that information and there's going to be gaps.
Speaker:There's going to be conflicts.
Speaker:So you analyze those and start fitting them together into a
Speaker:complete system, identify your gaps, go back and talk to more people.
Speaker:So it's an iterative process as you're doing that, you're specifying
Speaker:and writing all this down.
Speaker:Now, if you're an Angelist, it's being written down as stories,
Speaker:if you're more traditional, maybe you're using use cases or whatever.
Speaker:And then the requirements analyst has to interpret all that information
Speaker:down into technical requirements, because the user's going to say,
Speaker:I want it to be user-friendly.
Speaker:Okay.
Speaker:How do you program that?
Speaker:So the job of the business analyst isn't to interpret that and say for
Speaker:this customer through conversations with them, that means there's
Speaker:a help file, a help function.
Speaker:Or it may mean that somebody with 2040 vision or better from three
Speaker:feet away can read the screen on the pump in bright sunshine.
Speaker:You ever seen the ones where people are having to do this, just to do
Speaker:that the other day, as a matter of fact, again, what's user-friendly
Speaker:to that user, what am I asking them?
Speaker:What they don't like about the system questions like that?
Speaker:One of my pet peeves with the pay at the gas pump system is they
Speaker:all ask you a series of questions, including, do you want a receipt?
Speaker:But they don't all ask them at the same time.
Speaker:So they ask you all the questions you pump your gas.
Speaker:And as you're trying to get your gas cap back on and everything finished up, then
Speaker:they ask you if you want a receipt and it times out before you notice, come on,
Speaker:the software can remember for the five minutes while you're pumping gas, whether
Speaker:you want it to receipt or not, it's not user-friendly to break those questions up.
Speaker:And I've had it asked me at the beginning as well.
Speaker:Now I won't say that.
Speaker:I'm not saying that, but talking about different user specs of whoever
Speaker:required, ask that it was like, all the questions were upfront.
Speaker:You knew what you were doing that was infrequent versus the end.
Speaker:No, I know exactly what you thought.
Speaker:Have you noticed that some of the more modern gas stations now have
Speaker:pictures of what you're supposed to do instead of just the words I've
Speaker:not seen, I've not seen those here.
Speaker:What's the stakeholder that's there addressing non-English speaking.
Speaker:Here in Texas, that's a big issue or people that are
Speaker:illiterate, they might get.
Speaker:So rather than having words scroll across the screen, there's pictures
Speaker:of what you should be doing next.
Speaker:And the, and you just taking about illiterate.
Speaker:I don't even know if I know somebody personally is that, but you've hit
Speaker:upon a thing out there that I've seen in the news going, there's actually
Speaker:a high percentage of people that are illiterate still in the United States
Speaker:to go that they're a stakeholder of a public facing payment system.
Speaker:That's yeah.
Speaker:Handicapped, handicapped.
Speaker:Yup.
Speaker:Now I'm hoping that nobody's driving a car that has to have braille
Speaker:autonomous is coming.
Speaker:Yeah.
Speaker:But there are issues, maybe it's the passenger that's pumping
Speaker:gas and needs braille or what?
Speaker:There's all kinds of subsets of customers.
Speaker:And then there's your quote, unquote unfriendly.
Speaker:You stay clean.
Speaker:People you want your system to be unfriendly to.
Speaker:And this is where you get your security requirements and things like that.
Speaker:You want to, you don't want people with expired credit cards using your system.
Speaker:You don't want people with stolen credit cards using your system, et
Speaker:cetera, et cetera, you don't want counterfeiters using your system.
Speaker:If it accepts cash out at the pump, there are systems like that now that
Speaker:are starting to accept cash, et cetera.
Speaker:Yeah, go ahead.
Speaker:No, I was gonna, I was gonna, now that you got the requirements, I
Speaker:was to jump forward a little bit.
Speaker:You've gotten your requirements.
Speaker:It's now time to, for the tech team to put hands on keyboard and start
Speaker:actually building the systems out.
Speaker:This is something because there's a step in between.
Speaker:Okay.
Speaker:What step in McQueen.
Speaker:Go ahead, please.
Speaker:First of all, from a quality perspective, you go validate those requirements.
Speaker:You get the right people together in the room and validate them, but the
Speaker:next step is then to design your system.
Speaker:What are the various components in your system, which requirements are
Speaker:going to get allocated to each of those pieces of software within your system?
Speaker:What's the interfaces between the components of your system.
Speaker:You can't skip design.
Speaker:It's a very important step because otherwise, modulator doesn't know
Speaker:how to integrate or talk to module B.
Speaker:That kind of thing you want to decouple it, this, the Zionist also where you
Speaker:get into actually designing insecurity, designing in safety, designing in
Speaker:usability, which was going to be, yeah.
Speaker:And then it's like your hands on the keyboard and start writing code.
Speaker:This is one of my, again, a pet peeve of mine is you go to college
Speaker:and they teach you data structures and algorithms and coding languages.
Speaker:And the kids, even today, they're doing better, but not great.
Speaker:They may have one class in how to do testing.
Speaker:Okay.
Speaker:Or one and nothing in requirements and design.
Speaker:If you're lucky, heaven forbid, configuration management or auditing or.
Speaker:Unless you're going after a management degree, even project management.
Speaker:One of the things that, talking about that it's, it always seems to be in a
Speaker:full project scope that the planning phase and the QA phases, if someone is
Speaker:going to cut some places down, you've got enough, you need to get going and there's
Speaker:okay, you've got enough going here.
Speaker:You've tested enough.
Speaker:We need to get this out to the end users.
Speaker:Now, even if it's not properly tested and stuff like that or not.
Speaker:So I see.
Speaker:Yeah.
Speaker:And who whose schedule always gets cut is the VNV people because they
Speaker:are at the end of the life cycle.
Speaker:So as things run shorter, their schedule gets more and more compressed.
Speaker:The problem with that is the exponential defect cost curve.
Speaker:If you find a requirements defect during the requirements activities, and
Speaker:it costs you one unit that might be.
Speaker:Two hours of effort.
Speaker:It might be three weeks of effort, but whatever that unit is, if you don't
Speaker:find it to design, you can basically double that it'll cost you twice as
Speaker:much, because now you've got to redo the code, the requirements and the design.
Speaker:If you don't find it until coding typically five to 10 times as much, if
Speaker:you don't find it until the field, the average in the industry, as something
Speaker:over a hundred times more expensive.
Speaker:So it's paying me a dollar now or pay me a hundred dollars later and
Speaker:we can point to classic defects.
Speaker:The Mars Lander that boat burned up in the atmosphere.
Speaker:That was a software defect.
Speaker:No, I did not.
Speaker:One module was passing a number to another module.
Speaker:The first module was measuring.
Speaker:Let me see if I got it right.
Speaker:The number of meters away from the planet past it to the other module.
Speaker:No, I'm sorry.
Speaker:It was the opposite number of feet away from the planet past the number
Speaker:to the other module that interpreted it as the number of meters away fall
Speaker:planet decided they weren't close enough and moved in past the atmosphere,
Speaker:burned up the ma what did it cost?
Speaker:And it wasn't even a multi-million dollar project that failed, but NASA
Speaker:lost reputation and had problem getting funding from Congress for future projects.
Speaker:But the costs of quality.
Speaker:And you're probably familiar if you're familiar with quality issues
Speaker:at all, is there's prevention costs.
Speaker:There are assessment costs, which is all your V and V activities and
Speaker:other activities of getting it right.
Speaker:The prevention costs are the costs of training people and putting the systems
Speaker:in place and all that kind of thing.
Speaker:Then you've got your internal failure costs, the cost of fixing
Speaker:things that you find internal to your company before you ship it.
Speaker:And then the external costs and the external ones, the ones that'll blow
Speaker:you out of the water on your project.
Speaker:The industry that I was thinking about as you were describing that I don't know if
Speaker:your familiarity with what's going on, but it, no kidding is the video game industry.
Speaker:The video game industry and the triple a gaming space has been hit hard over
Speaker:the past, at least three, if not four years, with these games that come
Speaker:out, they're almost non-functional, but they've spent who knows how many
Speaker:5,000 million dollars team seven, 800 person teams that have been.
Speaker:Monkeyed with, by management and the publishers and all this kind of stuff.
Speaker:And then just cost out on to, Hey, spend 60 or $70 on my game that doesn't work.
Speaker:And it just blows my mind every time I see this.
Speaker:Cause that's probably I tracked a little bit of that news.
Speaker:I still play it.
Speaker:Now let's take that same attitude of management and move it into
Speaker:a biomed product that is doing like the DaVinci machine.
Speaker:That's doing surgery on my husband's heart, true story to repair a valve.
Speaker:True story.
Speaker:True story.
Speaker:Back in 2011, I'm sitting there praying to the software gods
Speaker:says somebody's weakness, right?
Speaker:That they didn't do that.
Speaker:Unfortunately, yes.
Speaker:There's all kinds of industry standards.
Speaker:The FDA does all kinds of, did you do it right the first
Speaker:time before they let you even.
Speaker:The biomedical device and product, they just have come out with their
Speaker:second version of the guidance documents for doing software security,
Speaker:et cetera, et cetera, et cetera.
Speaker:The issue here is good risk management because the lower, the
Speaker:risk of the product, but then those gaming companies, they're one in.
Speaker:There's too much competition there.
Speaker:If they put out a horrible product, they'll never sell another one or they
Speaker:just change the name of their company and put it out under another name.
Speaker:Yeah.
Speaker:W oh yeah.
Speaker:No, that, and that.
Speaker:I just tagging on that one for a minute.
Speaker:It's been one of those things that each iteration that they try to do.
Speaker:Cause some of them there's been mass consolidation in that market space
Speaker:that they can, they've got some that are the money makers and others are
Speaker:lost leaders just for different genres.
Speaker:But going back to talking about the biomed and stuff like that, or are there specific
Speaker:industries, come from cybersecurity perspective, there's certain industries
Speaker:that you've got your compliance standards.
Speaker:There need to be.
Speaker:It is like the, talking about FDA.
Speaker:Are there other industries that are absolutely regulated
Speaker:by that need to be a software?
Speaker:Okay.
Speaker:Do you know that the stamp, the average car right now has two?
Speaker:Let's put this.
Speaker:Over 2 million lines of code in it.
Speaker:I believe that I've heard it may 10 X over the next couple of years.
Speaker:Yes.
Speaker:And that's doubled from last year.
Speaker:The literally doubled from last year, but over a hundred microprocessor chips.
Speaker:I laugh.
Speaker:Everybody talks about artificial intelligence.
Speaker:My first comment on that is my truck.
Speaker:My car tried to kill me literally.
Speaker:And this is a true story too.
Speaker:I'm driving down the highway.
Speaker:I had never been in a car that had all the sensors in it before.
Speaker:And because I rent cars, travel for the living, right?
Speaker:So I'm in this car, I'm passing, there's a semi, I am coming up and passing the semi.
Speaker:I got too close to the rear end of the SIM.
Speaker:Now I'm three fourths of the way over into my lane or more.
Speaker:And I've got plenty of room to get past the semi and get into
Speaker:the other lane to pass him.
Speaker:There's a person coming up on my rear.
Speaker:What's going 70 miles an hour down the highway, the trucks doing maybe 55.
Speaker:Okay.
Speaker:I get apparently within the range where they're not happy,
Speaker:how close I am to that truck.
Speaker:Now I'm still 10, 20 feet away from the truck, but it's going 55.
Speaker:I'm going 70.
Speaker:The car decides I'm getting too close, too fast and slams on my brakes.
Speaker:First of all, unexpected to me.
Speaker:So I am literally lose, almost lose control of the car because I'm not
Speaker:expecting it to slam on my brakes, the car behind me, which was, 10 car
Speaker:lengths away is now a half a car going.
Speaker:Yeah, it's getting ready to be in my trunk and I'm having to make a split decision.
Speaker:Do I slam on the brakes even more and try and pull over behind the truck?
Speaker:Do I go off in the ditch?
Speaker:So the lady doesn't rear end me or do I let her rear it?
Speaker:I'm having to make a split decision.
Speaker:My car tried to kill me because it made a wrong decision.
Speaker:And that's why I'm sure there were parameters that, yes, I was close, but I
Speaker:was close and passing and I was personally not advised of what the standard was.
Speaker:So I had no warning that it was saying, too close or Hey it, 30 feet.
Speaker:It could have said, you're getting too close.
Speaker:Do you want to hit the brake?
Speaker:But no, instead it just slams on the brake on me.
Speaker:It's health and safety you're out there folks.
Speaker:Oh, absolutely.
Speaker:And that goes back to, so my wife's vehicles a couple of years old now,
Speaker:but it was the first one that had all that safety feature on there.
Speaker:And it had a bug, nothing that got obviously to that extreme that you did.
Speaker:It's got the, it's got the side mirrors that if somebody is in your
Speaker:blind spot, the light lights up, it will that feature by the way.
Speaker:Yeah.
Speaker:That's actually what kinda messed up.
Speaker:It was all, it was always on, it was being triggered by nothing like
Speaker:driving down a road with trees.
Speaker:It's always on.
Speaker:And I'm like, there's nothing there or, that type of thing, but it makes you
Speaker:because it was our first vehicle that had all of that stuff on there because
Speaker:it will, instead of just slamming on the brakes, don't get me wrong.
Speaker:It will, if you, if something, if somebody just jerks to a stop in front of.
Speaker:It will start gradually.
Speaker:She'll slowing down.
Speaker:If somebody is slowing down in front of you, if you're getting too close to them.
Speaker:And I just, there are those times where it's fighting for control
Speaker:because it wants to be in lane assist.
Speaker:He wants to keep you in the lanes and you can feel the steering wheel or it's
Speaker:and in my head, I'm going, you're turning to alert to earlier turning too late.
Speaker:And you're trying to help me with this.
Speaker:That makes me not fully comfortable with it yet.
Speaker:Self-driving cars.
Speaker:Yeah.
Speaker:With some of that stuff.
Speaker:Cause it will yell at you, but it does make you wonder, when you start talking
Speaker:about, is this card, the anonymize.
Speaker:Yes.
Speaker:The human mind can take so many conditions into consideration
Speaker:and the software just can't.
Speaker:The only thing it's got is the distance between you and the truck
Speaker:and the speeds that it can monitor.
Speaker:Yeah.
Speaker:It didn't it.
Speaker:It's not paying any attention to the lady behind me, how much it's not paying any
Speaker:attention to the fact that I'm changing lanes and I'm almost all the way over.
Speaker:It just sees the distances to short.
Speaker:It was something like that.
Speaker:So in, in our case, because, and I think this is actually a good way to figure
Speaker:out how you detect, do remediation after the fact something, something
Speaker:gets in the marketplace, you get the bugs, all software has, all software
Speaker:has some various bugs because you can only test two or three class software.
Speaker:According to capers, Jones still has two to 5% of its bugs
Speaker:with something like the car.
Speaker:There was a a firmware upgrade that fixed that they knew that
Speaker:was a, it was a problem when we took it back to the dealership.
Speaker:Cause it happened within a week to 10 days of us taking possession of the vehicle.
Speaker:One who tracks that stuff to know it's if I hadn't re you know, it's just X amount
Speaker:of people have to report this back to the manufacturer going, Hey, this light's
Speaker:always on for somebody to go back to.
Speaker:In our case, it was a Hyundai to go back and say, Hey, can
Speaker:you guys go check this out?
Speaker:We need a patch for this because we've had 2% of the people that have bought this.
Speaker:How were those things track?
Speaker:I don't know what the regulated industry is for automotive,
Speaker:in, in biomed, it's the FDA.
Speaker:And when incidents like this happens, they have to be not only fixed internally
Speaker:and dealt with internally, but they have to be reported to the FDA.
Speaker:The federal aviation administration for airplanes that the FCC
Speaker:for telecom issues, telecom.
Speaker:Software security and safety related because of the nine 11, et cetera.
Speaker:So you're talking about the FAA.
Speaker:If you saw the Boeing max documentary that was on Netflix, where they
Speaker:kinda changed the system, but didn't want to go through some of the
Speaker:process, what looked to be hiding.
Speaker:What was, should have been a very simple thing.
Speaker:It looked like in the, at the end of the process for the that's where your
Speaker:BNV comes in, how much re retesting and regression testing can you afford?
Speaker:Cause it's a balancing act.
Speaker:That's another problem with software, with hardware.
Speaker:There it is.
Speaker:There's the defect.
Speaker:You can see it.
Speaker:There's a solder splash.
Speaker:There's a bent wire.
Speaker:There's a, some of it still gets through, but with software it's first
Speaker:of all, millions of lines of code.
Speaker:Second of all, where's the defect.
Speaker:It's one of those you can't prove the negative.
Speaker:All you can do is prove there are software defects because you found them.
Speaker:But there's nothing that proves that the software is perfect.
Speaker:How about, so how much it's all going to be?
Speaker:Risk-based how much testing do you do versus because the problem, you have to
Speaker:look at the probability, there's a, yet undiscovered defect in your software
Speaker:and the impact, if that defect gets in the field, because it could be a
Speaker:misspelled word on the screen, big deal who cares a misspelled variable name in
Speaker:the code could cause the car to crash.
Speaker:So even the same defect in the wrong place could be a major catastrophe.
Speaker:So there's the risk.
Speaker:Again, the risk side, the probability there's you got undiscovered defects
Speaker:cause you, it could be perfect.
Speaker:You can't prove it's not.
Speaker:Versus the cost of doing more testing and the probability you find the
Speaker:defect, even if you do more testing, you can test for another three
Speaker:weeks and not find that defect.
Speaker:So it's always a risk-based balancing act with software.
Speaker:I've always said, particularly with some of the the projects that I have been on.
Speaker:You've got a, most likely limited QA base to sit there and, help
Speaker:with this or whatever software tools you've got in there.
Speaker:But once it gets out into the public spirit, you never know what
Speaker:combination of junk you end user is going to do to trigger something
Speaker:odd that nobody in bazillion years would have actually thought about.
Speaker:That's been my, this is why a lot of companies do beta testing of their
Speaker:software, where they put it out in the live field and let the real
Speaker:users play with it for awhile before they propagate it out to everybody.
Speaker:So another one of the VNV techniques is.
Speaker:What are called alpha testing and beta testing, alpha testing is letting the
Speaker:users use it and play with it in the lab in a test bed versus beta testing
Speaker:is a limited number of live sites.
Speaker:So at least you're minimizing the damage if it does occur.
Speaker:Yeah.
Speaker:But again, I'm going to go back to more familiar with that on
Speaker:the video game market space.
Speaker:Don't ask me why I know all the video game news.
Speaker:Oh, Microsoft does extensive beta testing of their products.
Speaker:Yes.
Speaker:Adobe does as well.
Speaker:I've come to find out the telecommunications company I work
Speaker:for did extensive beta testing.
Speaker:Hey, we called it first office verification, but we put it out
Speaker:in one office and make sure it worked well because you can't have
Speaker:the telecon system going down.
Speaker:I feel like we're finally also getting into an environment where
Speaker:cybersecurity is getting this.
Speaker:Obviously the spotlight shown on it with industrial control systems, you've
Speaker:got your water plants and electricity, gas pipe, internet of things.
Speaker:How do you, how are you, how would you rate with all your experience on the
Speaker:quality side of getting the security pieces baked in from implementation versus
Speaker:bolted on after the fact, whether it's identity, access management controls, or
Speaker:just there's ways too much software that we used to see that wouldn't even encrypt
Speaker:the data within their own databases.
Speaker:For instance, are people putting a lot more of that I didn't have to, and they
Speaker:didn't need to because the internet was, they, their system wasn't hooked
Speaker:to anything nobody could get in because they had complete access control.
Speaker:Their system was a standalone system.
Speaker:The invention of the internet has changed the game completely.
Speaker:As far as cybersecurity is.
Speaker:Now the problem is, and to answer your question, I see most new systems
Speaker:being built with cyber security requirements, hopefully, and good design.
Speaker:And there's lots of good practice out there.
Speaker:There's penetration testing and vulnerability testing.
Speaker:What we call white hat hacking, where you get people trained to hack into
Speaker:your system and test it that way.
Speaker:The problem is software doesn't wear out.
Speaker:So back in the eighties and even the seventies and sixties, a lot of the
Speaker:software systems we use today were built back then when there was no
Speaker:internet and security, wasn't an issue.
Speaker:The air traffic control system in the United States is an classic example.
Speaker:The air traffic control system was built back in the seventies,
Speaker:sixties, seventies, 80.
Speaker:They've tried.
Speaker:It's so complex.
Speaker:It's so much spaghetti code.
Speaker:It's so long.
Speaker:They, my understanding an article I read back when they've tried three times
Speaker:to trash that system and completely rebuild it from scratch and all
Speaker:three times it has failed next gen.
Speaker:So this is where you start bolting things on.
Speaker:Yeah.
Speaker:Next gen for FAA has been in, talked about for let me see.
Speaker:I did actually did my master's on next gen with that.
Speaker:And it's just, it can't get what it needs to get off the ground
Speaker:these legacy systems out there.
Speaker:So with any of the work that you do you go back and do you get.
Speaker:Talked about to go back to legacy systems and go, Hey, we need to bring
Speaker:this up to a quality standard for not only functionality security take and
Speaker:take a re-look at these older systems because they can't do rip and replace.
Speaker:And the problem is, do you even have the source code?
Speaker:Did they do good configuration management back then, which is another one of the
Speaker:quality topics that I didn't get to, which is quality control, where you're doing
Speaker:config, controlling your software, doing your configuration management, doing your
Speaker:metrics, all of those kinds of things.
Speaker:But yeah, it's, it is an issue because, what's the risk of doing it.
Speaker:What's the risk of not doing it because if I go touch that stuff
Speaker:many of those older systems are I E they were written in spaghetti code.
Speaker:Nobody alive even, or non retired, even knows how, it's like 20 Y2K.
Speaker:You might have friends that wrote COBOL code that made a fortune in
Speaker:Y2K and folks, some of those systems are still out there that were written
Speaker:in code, but who's training anybody on writing COBOL code anymore.
Speaker:You're making me think of that movies face Cowboys from like 2000
Speaker:with Clint Eastwood, they had to go bring all the old astronauts out.
Speaker:Cause they were the only ones that understood the system
Speaker:that had to be repaired.
Speaker:No, I started out on Unisys mainframe.
Speaker:There was people not that I actually, the dumb terminal and stuff like that.
Speaker:And that's what everybody, nobody can do that stuff anymore.
Speaker:And it's probably still there.
Speaker:I have a client.
Speaker:Who is currently running an accounting system that was
Speaker:built in the sixties in cobalt.
Speaker:They are on the ambulation of the emulation of the
Speaker:original operating system.
Speaker:This is like taking Mario brothers and making it run on a current
Speaker:PC with the current database, current operating system.
Speaker:You've got three wrap arounds between the original code and the
Speaker:operating system just to make it work.
Speaker:Yeah, retrofitting is an ongoing issue.
Speaker:And again, we got to go back to risk because is it riskier to have the
Speaker:potential security holes or is it riskier to touch the software to try and patch
Speaker:the potential security holes, which has.
Speaker:And I would I would throw in a third one, there is it riskier with a system
Speaker:that is that data to not convert to something else short of it being so
Speaker:niche, whatever it is that they do, that you can't migrate to a new system.
Speaker:What's the cost of the new system versus trying to maintain something
Speaker:through all of that craziness in mind, the issue is unlike hardware
Speaker:wears out and we throw it away.
Speaker:We go buy a new one.
Speaker:I've got cell phones in a drawer someplace that, don't even work on modern anyway.
Speaker:But yeah, software does not wear out.
Speaker:There's not the back end to the bath Cub curve, once it's good.
Speaker:It's going to run forever unless you touch it.
Speaker:You got to pull the apple, what apple does with their phones, that they stopped
Speaker:supporting their stuff after about seven or eight, seven or eight years
Speaker:when they keep coming out with one.
Speaker:I tell you a story about that too.
Speaker:I worked for a telecom company that right when mob bell started getting
Speaker:broken up, the very first competitor was MCI and the only people building
Speaker:soft telecommunications equipment was one of the branches of mall bell.
Speaker:So little startups like DSC communications that I worked for years went in the
Speaker:business of building telecom equipment for companies like MCI and other upstarts.
Speaker:We're trying to break into a new model.
Speaker:We promised we'd support the software for the life of the product in the field.
Speaker:Now this was not a problem for MCI because they always wanted the latest
Speaker:and greatest stuff and they were building new hardware and we're building
Speaker:new software to fit on that hardware.
Speaker:Now, fast forward 20 years when I'm working for the company.
Speaker:And again, we're on version 30, something of this code, but there are
Speaker:some ma it's, little Midwest towns where they're the only town for 50 miles.
Speaker:And there's all of 20 people in the town.
Speaker:And somebody is the telecom company.
Speaker:I E they have a switch in their garage, running the telecommuting
Speaker:indications for those 20.
Speaker:Guess what version they're still on?
Speaker:We're on version 36.
Speaker:You remember the old eight inch floppy disks.
Speaker:The software is running on eight inch floppy hats.
Speaker:You can't even get the discs anymore.
Speaker:So we're having to hand patch everything.
Speaker:Cause we can't give them new software because the only way they can read it as
Speaker:off of eight inch floppy disc, we had to pay them money to allow us to come in,
Speaker:take out their system, replace it with a brand new modern system, retrain all
Speaker:their, retrain their other two people for free on how to use the new system.
Speaker:And they still weren't happy.
Speaker:And the reason they weren't happy is because now you've got to dial a seven
Speaker:digit phone number instead of only having to dial the last four digits
Speaker:to talk to somebody else in town.
Speaker:Geez.
Speaker:Yeah.
Speaker:Yeah.
Speaker:Versioning is that's, yes.
Speaker:After a while we said we only support the last three versions, back in the day
Speaker:we signed contracts like back when I, so I did a lot more network engineering.
Speaker:That was how, I guess I got started on, the help desk computers.
Speaker:Like I said, I started out on a Unisys mainframe and then all this kind of stuff,
Speaker:but I was supporting an air conditioning refrigeration company years ago.
Speaker:And they were running some, some funky off the walls software that was on oh shoot.
Speaker:I can't remember some sun.
Speaker:It was sorta Unix-based command line system that was, had to be emulated
Speaker:through a terminal service screen.
Speaker:And I just remember going, Hey, the box is old.
Speaker:This thing is going, the box itself was going to die and they were tied
Speaker:in to one support company made up of three people somewhere in Florida.
Speaker:And this is I'm in Virginia and.
Speaker:I kept telling them.
Speaker:I said, if this goes down, your business is down your dispatch for your Texas
Speaker:down, you can't bill, you can't receive money and you just, you can't function.
Speaker:If the software goes down, if the box itself dies.
Speaker:Cause this was, I would say pre this is pre cloud stuff anyway, but not
Speaker:that would have run into the cloud.
Speaker:And I remember always having to talk to those guys in Florida who are not the one
Speaker:in particular was not a very nice person.
Speaker:So none of us, it was like, I always usually made, cause I was the consultant.
Speaker:I would make one of them call because I didn't want, and they didn't
Speaker:want to deal with them either.
Speaker:So we went through this whole process of trying to go switch out the software
Speaker:to something that was more updated.
Speaker:Something that if somebody got hit by a bus that somebody else could
Speaker:figure out how to use it, you're not tied into this one supporting
Speaker:company and sure enough, the box.
Speaker:They didn't switch when we had, when we try to, because one person,
Speaker:the company didn't want to learn a new piece of software because
Speaker:she had been there for 20 years.
Speaker:They got tied into this company.
Speaker:They're probably still using it for all I know.
Speaker:And to a vendor, they did not like for hardware that I could have gotten
Speaker:for 20% of the price that they have to buy it from these other guys.
Speaker:And then they were down for 10 days and couldn't do any work
Speaker:because they had to ship the stuff to Florida for the transfer.
Speaker:And it was just crazy how some of these places get stuck
Speaker:into these legacy devices.
Speaker:When they, when you're looking at the, obviously that's a small operation
Speaker:versus a big gigantic multinational corporation or a town or municipality,
Speaker:they may be locked into something, but how, software doesn't, like I said, it
Speaker:doesn't die, but it should at times.
Speaker:Yeah, definitely.
Speaker:At some point you have to draw the line and say, bite the bullet and.
Speaker:My husband did that with one of the jobs he was working on, simply because
Speaker:the chip, it was all firmware and the chip manufacturer went out of business
Speaker:and they couldn't get the chips.
Speaker:They went on the eBay market and bought every ship they could find from anybody.
Speaker:And that gave them two years to convert the software to a new chip set because
Speaker:the assembler language was unique to the chip set and the chip set was antiquated.
Speaker:And, sometimes the hardware gives up on you and you have
Speaker:to move forward and migrate.
Speaker:So yeah, legacy code is a major quality issue in and of itself.
Speaker:What, with what the current environment we're in, I'm seeing a lot of stuff
Speaker:where people are doing these drag and drop coding things for the no-code
Speaker:experience with somebody starting out.
Speaker:Do you have any thoughts on those?
Speaker:Because some of it seems very generic.
Speaker:It's Hey, I can go.
Speaker:You create your own app, use our platform, it's drag and drop.
Speaker:I versus, somebody going out there and doing a customized solution for you
Speaker:from scratch or something like that.
Speaker:I don't think it's great.
Speaker:I don't have any experience with them other than I see more of it popping up.
Speaker:It's the one, is it the fourth or fifth generation languages now are all
Speaker:these this piece of software does this piece of software does that this P and
Speaker:then you can build a series of those.
Speaker:It's basically getting you into let's design a good system, and
Speaker:then we can just plug and play all these reuse software pieces.
Speaker:The big advantage from a quality perspective is those components have
Speaker:been previously built in other systems.
Speaker:They have been they've stood the test of time, whatever GFX we're
Speaker:in them have been out of them.
Speaker:No, I have been taken care of.
Speaker:So you get that quality.
Speaker:The problem is, does it do what you really want it to do?
Speaker:Or do you have to start building some kind of weird wrap around so that
Speaker:this piece of this component talks to that component or talks to this piece?
Speaker:Does you know?
Speaker:Yeah, I think they're great.
Speaker:They reuse code gives you a big boost in security, but it
Speaker:doesn't come without a cost.
Speaker:And that's what I was curious about.
Speaker:Not just having seen that kind of start popping up in the market
Speaker:space that, does it really get you what you're truly looking for
Speaker:or is it, is it a 70% solution?
Speaker:I don't even know what all the functionality is within there, but
Speaker:for anybody who's starting out.
Speaker:Cause I know you've got, you've got your software excellence academy.
Speaker:What would you say I'm actually going to go talk to a group of
Speaker:fourth and fifth graders next week at the time that we're recording
Speaker:this and who have an interest in it.
Speaker:And I'm going to be talking about to a degree software development of, I wish
Speaker:I had gotten into coding years ago.
Speaker:I don't know how to code because that's, that seems to be the future.
Speaker:There's going to be a lot more.
Speaker:Yeah.
Speaker:I like coding.
Speaker:It is 10 to 20% of the job of building software.
Speaker:What would you, how would you start somebody out that approaches you and
Speaker:says, Hey, I'm looking at, we're seeing a lot of people doing career transitions.
Speaker:Now I know people reach out to me for career transitions or that person that's,
Speaker:they're maybe getting ready to graduate high school or something along that line.
Speaker:They say, I want to be in tech.
Speaker:I would like to be a software engineer.
Speaker:What path would you set them on?
Speaker:Again, go look for a college that is T teaching more than coding languages now.
Speaker:Let's go look for a CA if you're going into college, look for somebody that
Speaker:has a software engineering program.
Speaker:And by that, they're teaching testing, they're teaching requirements
Speaker:engineering, they're teaching design.
Speaker:I know, for example, the university of Texas in Dallas
Speaker:has hired some of the best gurus.
Speaker:I know.
Speaker:I know that for example, mark is there and he's just teaching classes on
Speaker:architecture and he's teaching classes on.
Speaker:So look for a university.
Speaker:Don't just look, they have a good baseball program in Texas.
Speaker:The university of Texas at Dallas does not have a good football team.
Speaker:I don't even think they have a football team, a good football team,
Speaker:but look at the program and look.
Speaker:Do you ha do you even see the words, software quality, or configuration
Speaker:management or requirements engineering, or even testing in their curriculum?
Speaker:Don't just look for got a computer science degree and here's 10 different classes
Speaker:you can take on Python and C and whatever the list of current languages there are.
Speaker:Because like I said, the actual coding is 10 to 20% of the job.
Speaker:And if you want a career path rather than a job, now, there
Speaker:are people who love coding.
Speaker:They want to code for the rest of their life.
Speaker:They want to sit in the corner by themselves with a computer.
Speaker:Okay, fine.
Speaker:And if that's your jam, all the power to yet, but if you want a
Speaker:career path, you're going to need to know more than just how to do.
Speaker:Because a cause there is the design and the requirements and all and now,
Speaker:especially with the agile lists, being the, that's more and more of that.
Speaker:And there's a reason there's more and more of that.
Speaker:I was going to ask you your thoughts on natural.
Speaker:I just, I helped write a paper or a little bit on agile versus
Speaker:waterfall a month or two ago.
Speaker:Agile is great in the right circumstances.
Speaker:Waterfall is great in the right circumstances.
Speaker:Pick the process that matches the way you need to be doing business.
Speaker:If you, I have seen agile scale, but it's still not primetime enough
Speaker:to be building massive systems with millions of lines of code in it.
Speaker:Agile is great.
Speaker:You mentioned the small to medium size.
Speaker:Yup.
Speaker:Or if you're doing something that.
Speaker:Even in a big system, very isolated.
Speaker:For example, I'm building a banking system.
Speaker:Agile is great because I can just have teams working on this little piece over
Speaker:there, which doesn't really impact all these other pieces, could, they can write
Speaker:just the night and day teller stuff.
Speaker:They can write just the financial web page.
Speaker:This one web page and somebody else is doing this other web page
Speaker:and never the Twain shall meet.
Speaker:And that's fine.
Speaker:But if you have a system that is needs to be tuned, but it's large, it's great for
Speaker:doing automobiles because the automobile, even though it's got 2000 lines of code
Speaker:in it, the fuel injection code does not talk to the antilock brake code.
Speaker:So you have all these little teams, each doing their own little piece.
Speaker:Agile is great, but if you've got a system where everything has to work
Speaker:together, everything has to talk together.
Speaker:Everything has to be to.
Speaker:Has it worse so that it all works to performance together, like a rocket
Speaker:ship or an air plane navigation system, or a then you have to have
Speaker:the rigor of the bigger teams.
Speaker:And I don't think that not yet, it may get there, but not yet does for
Speaker:safety, critical security, critical LAR reliability, critical large systems.
Speaker:I agree, because one of the things that we would see, particularly
Speaker:with agile, when you're talking about trying to maintain scope.
Speaker:Because I felt like in the government, they were using the terms wrong with some
Speaker:of the stuff that I had been involved in.
Speaker:And you would sit there and go hold on a second.
Speaker:I understand you want to show performance as you're going along and not sit there
Speaker:and say, you're not going to see anything for 18 months because it's a big system.
Speaker:It's a big built.
Speaker:But you're, but at the same time, you've given that power all
Speaker:into that verification approval.
Speaker:Oh, by the way, we've got a whole new backlog of new user
Speaker:stories that are coming in here, taking away from the overall.
Speaker:That's just what I saw.
Speaker:Yeah.
Speaker:Continuous replenish.
Speaker:And the biggest concern I have with agile is they've all, but, and I'm
Speaker:seeing it come back, but the original Agile's jumped straight from requirements
Speaker:to code and missing that design piece, I believe is a critical yes.
Speaker:That you're basically building technical debt into your system,
Speaker:using agile, even though they talk about eliminating technical debt.
Speaker:Yes.
Speaker:You're eliminating technical debt at the requirements level and the coding
Speaker:level, but you're building, again, security is added to the system.
Speaker:During design safety is added to the system.
Speaker:Usability is added to the system during design.
Speaker:If you skip that stage, I've got a lot of concern.
Speaker:No, I've always said the more that planning design you can do upfront
Speaker:again, coming from I'll call it from the network engineering side.
Speaker:When you get to brass tacks implementation and flipping it live, man, your life's
Speaker:going to go a whole lot smoother and you're not sitting there with your fingers
Speaker:crossed going, is this going to work the way we thought it was going to work
Speaker:versus pushing it down, build a dog house.
Speaker:Can I go say, I need a doghouse.
Speaker:I needed to have a roof.
Speaker:I needed to have a door.
Speaker:I needed to be this big because my dog is this big.
Speaker:And I go get a bunch of boards and build a dog house.
Speaker:Yeah.
Speaker:Do you want to build a house without blueprints?
Speaker:Definitely not.
Speaker:Even though I think the house before this one, that's exactly what
Speaker:happened, but that's a different story.
Speaker:That's a way different story.
Speaker:If they want to reach out or check out any of your courses, what's the
Speaker:best way for them to contact you?
Speaker:L westfall@westfallteam.com.
Speaker:You can email me or they can sign on to my website at software
Speaker:excellence academy, no spaces.
Speaker:So just software excellence academy, all one word.com.
Speaker:And I'll make sure that I do weekly webinars.
Speaker:If you go slash webinars, it'll, the next three coming up are up there record.
Speaker:I always keep recordings of the previous eight webinars there for people to watch.
Speaker:If you go to slash classes, you can see what live classes are coming up.
Speaker:What online classes.
Speaker:I do virtual on demand or live classes periodically.
Speaker:No, that's awesome.
Speaker:And I'm going to make sure to put all the links in the show notes and all of that.
Speaker:So that's all out there and got, we just did that one yesterday
Speaker:that I need to take that one off, but we do a theme of the month.
