Episode 130

Linda Westfall: How to Design Quality Software

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
Speaker:

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.

About the Podcast

Show artwork for The Business Samurai
The Business Samurai
Skills and Stories to be a Well-Rounded Leader in Business

About your host

Profile picture for John Barker

John Barker

20+ years of technology, cybersecurity, and project management experience. Improving business operations to create a culture of better cybersecurity and technology practices. John is the Founder of Barker Management Consulting and the creator of the Business Samurai Program.

MBA, PMP, CISSP