Rockin' The Code World with dotNetDave ft. Woody Zuill- Show 2

Thank you

Hey, welcome everybody to the second Rockin' the Cold World with Donette Dave

I'm David McCarter. I'm glad you're back. And we have a really awesome show lined up for today

And we have awesome shows lined up for the rest of this month and into November

So I hope you come back every Saturday. and if you're not here live, then please catch it recorded

But if you watch live, you'll win more prizes. So we'll talk about that in a second

So I'm really happy that my second guest for my show is Woody Zul

a friend of mine for a long time. He lives in the same area that I do

and I actually haven't seen or talked to him in a while. So I'm really excited about talking to him and catching up with all that he's doing

and all he's doing with Agile and coaching and things like that

So let's get started. Can you put up my slide deck? David, you forgot to share your screen

I didn't share it. Oh, I have to share my screen. It lost my screen

Yes. Okay, there you go. Perfect, David. Yep. Working out the kinks

All right, so show number two, October 3rd. If I can get PowerPoint to work

There we go. So those of you who maybe don't know me by now

I'm a Microsoft MVP and C Sharp Corner MVP, award-winning developer architect

all that kind of stuff. There's my email address. Please, please, please email me

with your questions and comments. There's my Twitter handle. Please follow me at Twitter, not Facebook

I don't really use Facebook anymore. And there's my LinkedIn handle. So that's all about me

That's enough. All right. So welcome to the second show. Like I said, I'm really glad you're here

I've been really, really excited about doing this show and bringing this show to all of

you worldwide since this idea was presented to me. So I'm really happy

I think about it all week. And like I said last week, you know, this show is for you

It's not for me. I do enough. I'm just doing this for you guys to help you not only in your coding, but also in your career, too

So this is for you. This is your show. So but I can only make it your show if you let me know what you want to see or hear or do or anything like that

So please reach out and email me. There are no stupid questions at all

I will read every single comment and incorporate them into the show if I think it'll work out good for everybody

As you know, if you're watching live, it's every Saturday at 10 a.m. Pacific Time

That's where I live. And this is what I'm going to do in most of the shows

We're going to interview a top expert in this industry. We'll do some tech news

Maybe I'm not doing that today Just because I've been behind On looking that stuff up

And also I have this dog fooding Segment that I did last week

That I really like the dog fooding segments But I don't have that this week

Either because I've been Flooded with other stuff to do But we'll do something a little bit different today

That will be easier than recording My Amazon Fire TV So and more to come

And again, this is your show. So let me know what you want me to do and I'll do it

So to entice you guys to not only watch the show, but watch the show live, every show I'm going to be giving away these sets of gifts

They will change maybe on every show. So one of the big things we're going to give away is a $50 Amazon gift card to anybody in the world

I save that to the end. So you watch. The first thing we'll give away is a C Sharp Corner swag bag full of T-shirts, backpack and whatever else they have at the C Sharp Corner offices

And then I'll also give away, unfortunately, to U.S. residents only a Donna Dave swag pack and which will include lapel pins, stickers and all kinds of things

I have piled up here because I couldn't travel this year. So I think you'll like it

And I'll fill in at least one of my custom Donna Dave guitar picks

So and at the end, everybody will win a free copy of CodeRush from DevExpress

CodeRush is the only refactoring tool I've ever used. I swear by it

And if you watch through the end, you'll be able to get your copy of it, too, for free

So how do you win? Well, pay attention and have fast fingers. All these giveaways today have a question behind it

So listen. Google fast if you don't know the answer and put it into chat

And Simon will pick the answer. I mean, pick the winner and we'll announce the winner live on the show

So before we get into the first gift, the last show of this month is actually on Halloween

and you know Halloween at least in America is where everybody gets dressed up and goes trick-or-treating

and and adults have Halloween parties and all that kind of stuff so I kind of wanted to make

my show on Halloween fun and so I will promise you I will wear full-blown kiss-like makeup

if you come up with the design for my face on the left hand side there so on the right hand side is

one of my very first favorite groups when I was a teenager, Kiss. I've been to many of their shows

I used to dress up like Kiss during Halloween. I think the last character I dressed up as was

Paul Stanley right here. But I've tweeted this image. And if you go get that image

I want you to design kiss-like makeup, but in a geek kind of theme, right

So maybe like an evil zero and one, or I don't know, you guys come up with it

So if you're creative out there and you want to win a C-sharp corner gift bag shipped anywhere in the world

please draw my makeup and retweet it with those things They my handle and also rock and code world and the winner will get that prize pack So I hope you do that and if you if I don get any entries I not dressing up So it all on you guys

So Here's the first giveaway and this is the C-sharp corner gift swag bag including a backpack

so I'm gonna only leave the question up for a little bit and

and whoever gets the answer first will be picked by Simon, and he'll flash the winner up on the screen

So ready? Here we go. The C Sharp Corner website started in what year

I'm trying to do the game show song. Okay? So that's the first question for the C Sharp Corner GIFs

What year did the C Sharp Corner website start? Okay. So instead of dogfooding this week, because I was super busy with doing other things like work and taking care of health related things, I decided instead of doing dogfooding to just show one of my Twitter polls

If you follow me at Twitter, I'm always doing Twitter polls because mainly just to kind of fish for ideas on what you guys are interested in for maybe an article for C Sharp Corner or something like that

And but anyway, I did this poll back in March, I think probably towards the end of March

and it was about remote working. And because I love remote working

and I've been doing it full time for about eight years now

And so I did a poll and just what do developers think about remote working

And since we're all forced to remote work right now, I kind of would see what everybody thinks

So at least that March 27th, when this poll ended, 51% say they're more productive

of remote working. 41% say less, and unfortunately, 8% were laid off. So I hope the more productive

percent changes, maybe I'll do one towards the end of the year, now that everybody's been working

remote for so long. But me personally, I get so much more work done at home. And because I don't

have so many distractions. You know, I, you know, my work environment is so much more comfortable

because my kitchen is right there. The beach is about a kilometer away. You know, I have nice

lighting in here. I just feel so much better working at home. And I get more work done

you know, back when I started this. I guess back when I started working remote in the early 2000s

I figured I got as much work done remote in two days than I did five days in the office

And that's a little bit changed now, but I still get more work done working remote

And I know everybody's different. I know everybody has different needs and requirements

And some people don't like being at home. Some people like being home like me

But, you know, the only thing I think I hope that good comes from this horrible pandemic we're all dealing with right now is that it's going to teach companies, not only software companies, but other companies that, you know, remote working works

And I've already written a couple articles about that on C Sharp Corner

I hope you'll check it out and where I explain this in much more detail

But, you know, you know, I'm more healthier being working remote. You know, I have less expenses

You know, I impact the environment less. You know, to me, there's just so many positive things with remote working that it just I really like it

Now, there's some negative things, you know, I wouldn't call them negatives

but maybe challenges, you know, managing people remotely is different than managing people in an

office. You just can't corral them and talk to them. And, you know, I have to set up a meeting

on teams or something like that. So management is a challenge with remote work, but at least with

all the tools we have available to us, you know, in 2020, you know, what we do can be easily tracked

and then looked by the company. I mean, where I currently contract, I have to fill out three

different time cards every week because of it. So, which is kind of a pain, but anyway, so let me know

what you think about remote working. I don't see any comments, but I really love to hear your

comments if you're liking remote working or not, and how's it doing with you guys during this

pandemic. So I'm not even sure. I don't think where I work currently, they even announced when

we're going to go back in the office. I haven't been back in the office since the middle of March

And yeah, I'm okay with that. I do miss my team members. I do. That's for sure. But

I like being at home. Okay. So second giveaway for today, this will be the Dada Dave gift pack

unfortunately only US residents because it just costs two freaking months to ship anything outside of the country

and it might take months to get there with our postal system but anyway

so answer this question and you'll get a .NET Dave gift pack

including a .NET Dave custom guitar pick what year did I start as a Microsoft MVP

I say this all the time you can Google it it's not that hard to find out

And if no one gets it live, then if you're watching the recording, tweet your answer to RockinColdWorld at RealDawnItDave

And whoever tweets first, I'll give them the prize pack after the show if it's not picked up during the show

So there you go. In what year did I start as a Microsoft MVP

Not C-sharp corner MVP, Microsoft MVP. Okay? All right. Wait, we're giving away the gift card now

Huh? Oh, wait, I have to put in the answer to Simon

All right. So I thought I was doing this at the end

I guess I messed up my slide decks. Okay. So anyway, so here's the giveaway for the $50 Amazon gift card

And, of course, this will be shipped anywhere in the world. Oh, C-sharp corner people cannot participate in this

All right. What does the acronym SMTP stand for

First one, comments, gets 50 bucks. I need 50 bucks from Amazon

Okay, so what does SMTP stand for? The full name okay And whoever puts that in the chat first wins all right so i think it guest time

where is okay hold on something's wrong with my slide deck oh i hid what he slide that's the problem

them. Sorry about that, everybody. Technical difficulties. So today, I'm really happy to have

my very good friend, Woody Zool, come on the show. I've known Woody before I say his bio

I've known Woody for a long time. We met a long time ago. He helped me with my user group

for part of the 20 years of his existence. He was nice enough to come

not only come to my retirement party from the user group, but he also spoke at the retirement

party. So I'm very appreciative of that. And because we are good friends, Woody's even

babysat me in the hospital. So I won't go into that story, but he's helped me in the hospital

too when I really, really needed it and was scared out of my mind. So before Woody starts talking

Woody, I will always be internally grateful for you and the other guys doing that for me when I

needed it. So with that said, Woody Zool is an agile and learned software development guy and

has been programming computers for almost 40 years. He's an originator and pioneer of the

mob programming approach to teamwork and software development and provides workshops, training on team software development. He's also the founder of the No Estimates Discussion

which I hope to talk to him about later in the show, and frequent speaker at conferences

user groups, and all that kind of good stuff. So welcome, Woody

Hey there. Thank you, Dave. Hey, there you go. How's it going, man? All right. Doing great, and I really appreciate you as well. Last night, I went into my

my emails to see if I could find my first involvement in the old VB users group

But it only went back to 2002. And I know I'm certain it goes back to 1996 or seven

And I know I gave my first talk at a user group there in 1999

So this was, I got to make this really clear. You are kind of like a vortex

You draw people in and I can draft behind you. I learned a lot from you

But at the same time, I got a lot of experiences like the encouragement to speak

And now that's pretty much what I'm doing for a living. Back in those days, I couldn't hardly even talk in front of a group of 10 people

And now I've been to so many conferences and it's not still completely comfortable

But that's where I started. So thank you. Well, I think instead of a vortex, maybe I'm a black hole

I just suck everything. No, go ahead. No, I was just going to say, you know, it's like, you know

when I was in high school running track, you kind of learned to get behind someone else when you're going against the

headwind or whatever, so that you're drafting behind them, so to speak. Oh, that's me

And so you're kind of the person who was out in front and made it easy for guys like me to get involved and, you know, get drawn into the user group, get drawn into the management of the user group and, you know, encouraging us to speak and come up with topics

You know, that was powerful stuff for my career. Yeah. So do you remember how you found the user group originally

I was trying to think about that, and I couldn't remember that far back

So first of all, when I first started learning to program in 82 or so, I got my hands on a computer that had a built in basic

You know, they all came with basic in those days. So I started learning to program just in basic

And about 93, my little brother, who's also a programmer, I was visiting one day and he had a shrink wrap visual basic

It must have been visual basic three. And he said, you ought to try this and see what you think of it

So I got my hands on that. I was trying to program Windows using C++. That was a monster difficult thing to do back in those days. That was not Visual C, of course, or anything like that. And so, you know, there I was with VB3. And I was really in the midst of a learning phase, because I was thinking of changing my career from what I had been doing with a little shop, graphics and signage and so on

and move into programming for a living. And the VB3 was a really quick avenue into becoming productive

And somewhere around there, I know I started – it was probably – what was that magazine

Computer Edge. Computer Edge. Back in those days, I must have seen a listing in there

Yeah. That's where I found it. That's where I found Richard is through Computer Edge. Yeah

So you folks were meeting down in about 20 miles from where I live

Yeah. Easy to get down there, direct shot from the freeway. And even the very first meeting, I learned so much stuff

I would tell everybody two things to help move your career along

Get involved in a user group. Go to the user groups and try to get involved in as a volunteer and helping out

It's a great way to make connections, learn things and boost your forward motion in your career

Yeah, it definitely is. And I don't know how many millions of times I've probably said that in front of people, you know, but, you know, the people that are struggling to learn or want to learn more, the first thing out of my mouth is a user group

Or in C Sharp Corner, they have chapters in India, you know, same thing

C Sharp Corner chapters are like user groups, you know. And, you know, quite frankly, running that user group for 20 years is the reason I know a lot of what I know

You know, because I went to almost every single meeting, you know, and, you know, when you sit there and listen, it kind of seeps into, you know, after a while, right

Well, there's an interesting part of my career. My first contract, when I started working for other people, my first contract, I got differently

But after that, for about two or three years, all of the work that I did originated somehow in the user group

people like Woody Pughett who knew everybody in town. You know, all you had to do is ask him, you know, Hey

you know of anything coming up and in the group meetings, they would always have people come up and announce, you know

jobs that were available. So this was a powerful thing. And really I would say for, for three or four years

all the contracts that I got. And then when I started working permanent full time, a lot of the references I would get came from those experiences

all directed back to the user group. It's a powerful way to build a network quickly

if your career is just getting started out or if you been in it for years Yeah Yeah I I uh uh yeah you totally right Uh and you know the one thing I want to say before I forgot is I believe that our user group

had the best logo of any user group in the world because of your wife did it

Yeah. She's a great artist. I love that. Iconic, uh, kind of computer nerd with a propeller hat

Yeah. And it was kind of cute, but very simple. Yeah. Reproduced nicely on any printed material or on the website

Thank you. I'll tell her that. Yeah. I've said that many times, but, you know, it's ��

I look at user group's logos now and I go, blah, no good, no good, no good

So anyway, let's – Yeah, let's go ahead. Let's go ahead. So I don't know why my OneNote's not working correctly

Oh, there we go. So I've asked you when we first got together. So since I've known you for a long time and since I've known your progress in this world since, you know, for over 20 years, I guess now

So you're the creator of Mob Programming. And so first, you know, kind of quickly explain what Mob Programming is to everybody who doesn't know what it is

And then how did you how what led you to come up with Mob Programming

So, first of all, I think it was a team effort. So what is mob programming? I put it in this one sentence. It's all the brilliant minds working together on the same thing at the same time in the same space and at the same computer

So when we originated this idea, we didn't set out to do that. I had already been pair programming for over 20 years, and I knew the advantages of working with someone else closely

There was actually a little period of time we both worked at a place together where we got to kind of collaborate on things

But I really was experimenting with pair programming at that time and learned the real value of it

And it was much bigger than just, you know, that it helps you do better work

It has all these advantages to it. It's a highly amplified learning environment

You're sharing the ideas from two different people. So you're integrating your ideas in real time, so to speak

and so on. When I had the chance to work with more than two people at a single computer

I would take that, and it happened a few times. In 2005 or 2006, we would do a daily lunch and learn, so to speak

where I'd talk my boss into providing lunches for the team, and we would just get together in a room and look at some problem of code

that was hard to work on, and we would refactor it together. And we were all learning together as a group with one person at the computer, but everybody else interjecting ideas to try

Well, that wasn't mob programming, but it was on the path to it. In 2011, I was working in a company where we were focusing on learning to collaborate well

We were focusing on building our skills. We were focusing on learning to identify what bad code looked like so that we could change it and learning what to change it to

So in doing that, we had set aside three hours a week, three to four hours a week to sit together as a team on the company time and practice and study ways to improve our coding

During that time, we were actually learning how to communicate with each other

whereas before you know i've been programming almost 15 years before probably 15 years before

i even heard about pair programming it didn't really exist back in those days i was a solo

programmer yeah so this is sort of the thing we were learning to interact with each other because

we normally don't get any practice at it as developers we're working alone all the time

there's no one to talk to except ourselves and you know we can still argue with ourselves that

happens sometimes, but, you know, it's really more about let's learn how to communicate. And

there's three things that we were learning. One was we're learning to go ahead and try someone

else's idea and not argue back why we think our idea is better. The next one was we were learning

how to explain ourselves better and use the whiteboard to make that communication. And the

last one was learning to just be quiet. Let's just not say anything unless it's meaningful to say it

Because I've noticed with teams, especially when they first start out, everybody wants to share every idea they have

There's no big value in that. It's like it's just noise in the system

Yeah. If a good idea comes forward, all the ideas can stop for a moment while we try that idea

So anyways, we were attempting to study together and to learn how to interact well

And then one day somebody came to me. I was the manager of this group, but I was also working as a programmer full time with them

One of the team members came to me and said, they've got this project that we need to restart

We had, it was already a year late when I got there. I kind of put it on the back burner

They were getting anxious about working on it again because our time frame was shrinking

And so I said, well, what do you want to do? She said, well, I'm going to go look at it with another programmer and then we'll let you know what we think

Well, she came back and in about an hour, she said, boy, this code is terrible

And the way she said it was, there's a lot of badness lurking underneath the surface

From the surface, it looked like it worked. You could turn it on. You could click on things and so on

But it wasn't working very well. And I said, what do you want to do about that

And she said, let's get everybody together into a meeting where we can decide who should look at the code, talk about the problems, and we'll decide who should be working on this

And we'll put a little team together to work on it. But instead of doing that, when we got together in this meeting, we almost instantly started working on it together using this concept that's now called read by refactoring

With read by refactoring, instead of trying to read and understand difficult to understand code, you just start refactoring it

And pretty soon you have this clear understanding of what's going on. And the code is much better

And you never need to read it in the future to try and understand it

You can just see the names of the code is good. The functions are all small

Everything makes it easier to read. So anyways, we started doing that in this meeting

And it changed from being a meeting into being a working session. And within about an hour and a half or so, we were making good progress

Someone came into the room. and they said, hey, we've got this room scheduled for a meeting

You have to leave. And somebody on the team said, let's find another room right away

And so we just moved. I found one in our schedule over at the place I was at

We had about 40 meeting rooms. We could find one, and we found one and got to it

And before the end of that second session, somebody said, let's just book rooms for the rest of the day so when lunch is over

we just know where to go. That was, that's how, so we didn't invent anything

We just noticed something good happening and we didn't let it stop

And to really to put the cap on it at the end of that day, I asked them, well, what do you want to do about this

We were doing a daily retrospective at the end of each day. We'd ask ourselves what went good and how did we get more of that tomorrow

And everybody said, just, just go book some rooms for tomorrow and we'll work again this way tomorrow

I looked this all up. up just a week ago. I had taken screenshots of my Outlook calendar and I could see that we started

on a Thursday. By the Friday, we decided we're going to do this a lot more. So I booked rooms

for the whole next week and we didn't stop. Since then, we've been working that way. Now

I left the company in 2015. We started this in 2011, but I was getting so many requests to go

speak at conferences. I've now been essentially to every continent except Antarctica, which I'd

I'd love to go there sometime, but I don't think they do conferences there. And I've shared this all over the place

That pressure from the industry to know more about it was a challenge to me

I thought I need to learn how to explain this and share it with people. And it's been a wonderful thing just to have that feeling that maybe I'm helping some other people

I hope I didn't answer too much there, but that's the whole story. No, no, no. That's great

I was just thinking while you were talking and about, you know, I think you're a lot like me where, you know, I do things to help other people, you know, and you've been lucky enough that or you've been smart enough or blessed enough, however you want to look at it, that this is what you do full time now is just helping people

Right. Yeah. I would love to do that. So here's the thing for me is that the first invitation I got to speak at an international conference outside of the U.S. was going to be the first time I was going to leave North America

I'd been to Canada. I'd been to Mexico, but I'd never been off this continent

But at that point in my career, whenever I wanted to speak at a conference, I would usually submit a request, you know, like a proposal, and then maybe it would get accepted

maybe it wouldn't this they called me and they said hey we'd like you to come speak at our

conference on both mob programming and no estimates this was in 2013 and there was a lot of twitter

action about both those topics and i kind of told him i can't afford to do this it's uh you know i

can't take the time off pay to fly me there put me up in a hotel said no no no no we'll pay to fly

you here. We'll give you a place to stay and so on. And so that opened up my mind, really. It's like

oh, I never thought that could be a career for me. That seemed like that was for the really smart

people that were doing really amazing things. And hey, I've really, but it gave me an opportunity

to share some ideas that were working for us. And now I've seen them working all over the world

I don't think we invented this as much as we stumbled upon a part of human nature

And that is people do want to communicate and collaborate with others

It's just so dang difficult all the time. We've got to make it easy for that to happen

And I hope I've had some influence on the industry. You know, that little bit of time we worked together a few years back

I guess we've worked together a couple of times. But boy, it was so hard to get anything done

It was so difficult to be effective in our work. At the end of the day, you felt frustrated and tired and worn out

And my wife used to tell me after we started my program, she noticed this one day

She said it used to be you'd come home and you're all grumpy and mad at stuff

When you come home now, you're happy. You know, you're enjoying your life

And I thought, boy, I wish everybody could have that. Yeah, yeah

And that's always a hard thing to find, at least in your career and everything

But getting back to MobPro, so who came up with the name MobProgramming

Is that you? Well, kind of, not really. I'd read a paper from the Extreme Programming Conference from 2002 or so, and it had the word MobProgramming in the title of it

So I read that article long before we ever did this MobProgramming

and I adopted that phrase when I would go to user groups and do a coding dojo

So there's many ways to do coding dojos, but the basic idea of a coding dojo is it's going to be a social activity

with whatever number of people you've got there. But when you have a user group, let's just say with 20 people

it can be really chaotic. So I would make this little joke. I would say, well, we're going to do this thing where everybody's going to program

And we're all going to work on the same thing with just this one screen we're projecting up

It's going to be it's not like a pair. It's more like a mob. Right. And then I would say, but we don't want to be chaotic

We don't want to be an unruly mob. We want to be a ruly mob, you know

And so that name kind of that was meant to be a joke

And then once we start working this way, the team at our original place, the team kind of took that name

And just like anywhere you go, you'll see these scrum teams and stuff, and they give themselves names

And they wanted that name. I was calling it a whole team approach or whole team programming because I want to have all the skills and knowledge to do this work sitting together

Not just the front end people or the back end people, but add into this mix a database expert, a tester, a product owner

All the knowledge is sitting there with the team so we can work directly from start to finish on anything we're going to do without having to go off the team

Wouldn't that be nice? Well, it's how we are when we're writing some code for ourself

If we're writing code for ourself, we don't have to go ask somebody else anything. We just have it all there

We might need to look stuff up in a search engine. but the basic concept is this is about working with the knowledge that's about the product we're

writing right here yeah and so anyways um that's so that's where the word originally came from the

team kind of accepted it i found my slides from my very first talk in 2012 less than a year after

we started working this way people started hearing about it purely through word of mouth and uh in my

first talk, I titled it whole team programming. And by the end of that first talk, because there

was a slide showing the mob programming team, the people that were actually on our team

they called themselves mob programming. They said, you know, people were calling it mob

programming. If the team had been called, you know, the Hello Kitty team, you know

Hello Kitty programming. It was just by chance. I'm not very good at inventing names

but once one sticks yeah keep it keep it but i do encourage people if if mob programming is it

just doesn't make sense for you uh the the name use whatever name you want some people are calling

it ensemble programming others call it team programming i like whatever works for you

that's what you should do don't stick with what i called it or what we called it uh you know use

whatever works. Yeah, that's, you know, I've never used my programming. I've seen you explain it a

bunch of times and that I've not been on a, you know, team that used it. So unfortunately, I don't

have any like, you know, firsthand knowledge on it. But, you know, I was thinking, you know, the

last couple of days about this, this interview, and I was thinking about like, back to my beginner

days where, you know, when I started learning programming, you know, back in the early 90s

And up until you know into the 2000s you know the main you know the main methodology for doing software engineering was waterfall right And then even when I was working up the street here I started to learn and then teach at other companies the Microsoft software development lifecycle right

Which is better than Waterfall, but closely resembled it, right? And then all these other techniques came out

like Agile and all these, and now Mild Programming. So there's lots of different styles these days

you know, some better than others. And some people still use, you know, I forgot what the

guy at Microsoft told me once they used to like a combination of agile and waterfall. I forgot what

he termed it, but so they kind of do both, you know, at least back then when I talked to this

guy who used to run the visual studio team. And so there's all kinds of different methods, you know

unfortunately the method I see in most of the teams that I work in now, because I just do

consulting now. So I don't work full time, you know, for a long period of time at any company

now. So I'm always going to different teams and different projects. And, and, and I came up with

a name for that, what I'm seeing, at least on these, on these teams. And I, I termed it yesterday

pants on fire methodology, right? So you've heard it here first, pants on fire programming. That's

my term. But it seems to be that too many teams, that's the way they work, right? Either they are

just in crisis mode all the time. And there's lots of reasons for that, which is mostly

horrible architecture of the system, right? Or no architecture of the system, right? And

now they get themselves into a mess where that's all that happens. Whoever's screaming the loudest

that's what that's what gets worked on and it's that's not from to me that's not the right way to

approach it and just because uh somebody's screaming doesn't mean you throw out you know

the fda you know for example and and not not test anything right and so that's the way that kind of

seems to me it's like no architecture no documentation no thought process just do it

kind of thing, right? Yeah. So there are many good ways to approach designing and accomplishing

this work that we need to do. But what I noticed over the years is that once you start writing code

you're going to learn the reality. Until that starts, you know, all bets are off. So usually

we try to figure everything out in an old-fashioned waterfall approach, which I don't know if

anybody's really fully doing that anymore. You try to figure out everything so you understand

what you're up against, what it will take, who you're going to have to hire, and then you run

off to do the work, and then you start realizing we were wrong. So we made a lot of important

decisions before we had enough information to make those decisions. I used to joke about

software architects that if you're going to call yourself a software architect

I would first want you to design a complex system, create it, and maintain it for five years personally

At the end of that five years, if you're still sane, you probably have what it takes to be an architect

But it's going to drive you crazy because usually the architect's there at first, but then they sort of disappear

By the time the maintenance comes around, they're not around anymore in the waterfall

And so here's a bunch of developers mostly spending their day hacking around an architecture that really wasn't sufficient

Right. If we can refactor that architecture and move it to something better over time, fantastic

We're usually not allowed to do that. Matter of fact, at most organizations, whoever wrote the original code to implement the original design, they've retired or moved on

They're long gone. And so everybody there is scared to death to touch that original code

I worked at one place for about six or seven years where there was one chunk of code that was written before anybody that was still there showed up

And every time someone had to work on it, you know, the rest of us would commiserate with them and wish them the best of luck and hope they come back alive, you know

And we used to joke about we tie a rope around their waist and let them down into the code

And if any time they didn't signal back to us that they were still alive and breathing, we'd pull them out and resuscitate them

You know, so it's like a ridiculous situation, but that's what we often have happen

So, yeah, I really, I don't think the waterfall, of course, was the solution, but it was a way a lot of people worked

The original documents on the idea and where a lot of people turned back to, they were really suggesting a little bit, at least a little bit more of an iterative process

Eventually, they came up with this thing they call IID, which was an iterative incremental development

and we would see the spiral model and these other things, which tried to be somewhat

But when Agile came along, I really recognized this. And this really ties into mob programming closely

I think they recognized that if we can't work on the same thing

we can't collaborate if we're broken into different phases. If the people designing the application are not there

when the people are writing the application, they can never really communicate or collaborate. So they realized we've got to work on this at the same time

but we're also going to work on it in the same space that makes it easy for us to communicate

Well, nowadays we're doing it remotely, which turns out to be pretty much just as easy

But in those days, you know, if you need to communicate with someone who wasn't, you know, in your room or on your floor

you had to make a meeting or you needed to, you know, you'd communicate through emails, which are terrible for communicating this stuff

You spend hours trying to explain yourself. I really believe what we, you know, the advantage to Agile and now the advantage to mob programming is we get this extremely rapid feedback loop

So the people are going to ask us that we would ask questions of, they're going to be sitting there with us

If you and I were working on a job together and I had to, we were working on two, we were working separately on this code that we're trying to deliver this week

And I came over to you to ask you a question. That means I have to interrupt you

take you out of the context of what you're thinking about, which isn't good for a developer usually

And then try to get you into my context, which I'm never going to explain things really well

In your brain, you're going, okay, I think I know what the problem is. But you think you know what the problem is because I'm not explaining it

You give me your idea and I go, oh, yeah, that's going to work. I get back to my desk and start doing it and go, oh

I forgot to mention this other thing. So I have to go interrupt you again. So all of this is waste

These interruptions are waste. And then eventually, Dave, I'm pretty sure you would say, look, I got to get my work done today

Can we talk about this in the morning? Right. Now I'm in a queue

Then you're stuck. I'm stuck. But at least you're not getting interrupted

So somebody's productive. We get rid of these things when we're mob programming or at least when we're sitting in the same room and can easily turn to each other, hopefully without the distractions

But those distractions are costly. when you get in the flow you don want to be dragged out of the flow yeah that I think you know there two points I I want to make from what you just said And one is I think the average context switch you were talking about is 20 minutes

So every time you interrupt a developer, it takes them 20 minutes to get back to where they were, right

So just think if they were interrupted just five times a day, right

That's a lot of waste of time, right? Yeah. And so there's two. The other side of that is if I have to interrupt someone five times a day. So it's like this. The getting interrupted is bad. The having to interrupt somebody else makes you feel bad. Mob programming seems like this can't possibly work. Like we're going to sit there and we'll never get into the flow

But you're all in the same space, though, right? Exactly. So we're still in that personal flow, but we're also now getting this thing that's called team flow. With team flow, we have this, basically, we're all working on the same thing. So we are all focused in the same direction, but we're bringing our skills from all these different areas. So the ideas pop up faster

As a matter of fact, if the front end person is going, so we need to change these to red when this happens and green when that happens

And the database person says, well, where are you going to store this information about these rules

So we've gotten to that point a lot sooner than we would normally get to it

So we're getting – so I like to think of it this way. Somebody shared this idea with me

We're not trying to move faster from here to here. we're trying to compress the trip

We're now taking a much shorter trip to get from here to here

We're eliminating a lot of things that don't bring value. Have you ever noticed you're asked to do something

you sit down and do it, and the whole time you're going, this ain't going to work. Waste of time

That's right. When you bring back to the team, when the team is doing it together

somebody's going to point it out, going, I don't think this is going to work. Now we're going to have that real conversation

much sooner. And this is a big part of teamwork. But I think you have mob programmed

but in a very different domain. When you're playing with a band

a band is very much like mob programming. You get the team flow

You hear somebody over here do a riff, and then you go, oh, I like that

and you're going to play off that riff. Now there's that famous jazz musician, forgive me for not remembering his name

When he heard someone do a mistake, he'd riff off their mistake

Right. And so like this is a very creative process, innovative process

And you get that with a band. You get that with a lot of other human endeavors

And programming is just one of them where we get the people together and they get good at working as a collaborative effort as a team

We're going to see some great things happen. Yeah. And, you know, the other thing you mentioned a little bit ago was, you know, when you were talking about Waterfall and you were also talking about documentation

And, you know, one of the things I still I struggle with more and more as we go down the agile world, at least, is trying to get people to do documentation is like pulling teeth, you know

And and when I ask them for documentation of what the feature they're asking for, they don't want to do it

They said, here's a sentence, sit down and start coding. I'm going, no, wait a minute

You know, and so that's one thing I really was. And I know documentation is part of Agile, but at least where I've seen it implemented, I don't see that happening. Right. I get I still get one sentence requirements. Right

And the one thing I do miss about Waterfall is that upfront thinking documentation part

And they reminded me of a study that this guy did, which I'm going to actually be talking about in a couple of user group meetings this month when I do my defensive programming talk

And in that talk, I talk about the cost. One of the first things I talk about is the cost of fixing bugs

Right. And in the chart I show, you know, by the time you fix a bug while you're coding, that's 10 times the cost

Right. If you didn't figure it out when you were thinking about it or documenting it or something like that

So by the time you sit down and code, you've already 10 times the cost to fix something you didn't think about before

Right. And then if it gets to the user, that's like 150 times the cost

It's an astronomic cost that goes in if a user reports something

That's why I am kind of a pain in the butt about architecture and software quality and stuff like that to make that better

That kind of leads me into my next question because so far we haven't gotten any questions, so I'm going to keep asking them

That leads me on my next question. And so now that you've come up with mob programming and you've done it for real, you know, at a company, a couple of companies I know here in San Diego, and now you travel the world teaching it

Right. Overall, do you think that this is a two part question

The first part is for a business owner. So do you think that you can actually get features done faster or bugs fixed faster or whatever

And second is, do you end up with better quality software that can be modified easier in the future

I know that's two big, long questions. So if we're getting the second, then we probably were getting the first as well

But let's start with that. So from a business point of view, I often hear it this way. How can you possibly be productive with five people at one computer

Right. And so what we often think is that if we know what we need to get done, and then we can get, if we got five or six people, then we can get five or six things being worked on at the same moment

And therefore, that clearly needs to be, that's an advantage. But we are introducing a situation where all those interruptions, where all that context switching and so on has to happen

So we start introducing meetings. and a lot of the documentation, and I agree, it's good to document it

but it's good to document it just sufficiently, just enough documentation. What's our big idea

And hopefully that big idea isn't going to force us to write something

that's unchangeable later. So what's the big idea and what can we do first to kind of start proving

that this is going to work for us? So if we start there, then we can. So can this be productive? What I think we discovered almost immediately working this way. The end of that first day, we were doing these end of the day retrospectives and I'd ask the team what went well today. And I was working with them. So I kind of had an idea too. And they all said, boy, working together was great. Well, what was great about it? Well, we were doing a lot of knowledge sharing

Well, that means tomorrow is going to be better because we're learning more

We were getting a lot done. It was of higher quality and it was less stressful

Yeah. Now, at first, for us, it was less stressful, but I've noticed with a lot of other teams, it's more stressful at first

But we've been practicing the skills of collaborating for almost six months before we started doing this

so we had a little bit of an accelerated from starting it to making it effective This is the thing We were getting more done So any manager who wants to ask me that question how can you be productive with five people at one computer

I used to answer, I don't know, but we are. So, you know, so but then I spent a lot of time researching this

And, you know, the band is a good example. There's an example of a team

you're going to get a lot better results out of a band when you've got the band together

So if you're going to play a gig, let's say it's a wedding, and you're going to play dance music for that wedding

they're not going to come to you and say, look, we can't afford to have you all working on the same thing at the same time

I want to do five different songs. Then everybody can dance to the thing they want to

With only one instrument. Yeah. So what if we're going to bring in

Yeah, that's a good point. All we have is bass players. Right. Right. So but what if what? Well, I can't afford to pay you all for this whole thing

So I want the bass player for the first hour. The drummer comes in for this

We'll be there for the second hour. The lead singer for the third hour and the lead guitar player for the fourth hour

You know, the experience isn't what we're after. So there's lots of reasons to investigate as to how can this be more effective than separating people

People will ask me this. Where's the research that shows working as a team is better than working separate? And I say, I don't really know. There are people doing that research. But why did you decide that separating people is better than a team? Where's the research that told you that separating people is better than having them work as a team? It just seems like it should be

Right. But I don't think it really is. I think that because of the high costs of collaboration, the high costs of the communications and the very faulty communication, we wrote something down, we hand it to someone else

Are they going to understand it? They have to be really good at understanding or we have to be really good at writing to make that a complete thing

diagrams and so on. I've seen architectural diagrams that were too complex for anyone to

understand. And it didn't grow out of the actual needs. It grew out of what we thought were going

to be the actual needs. So I think for a manager, understanding that enhancing the ability to

collaborate, making it easy for people to interact with each other can have big advantages

Now, the second part of the question, this was basically about... about code quality and maintenance and for the future, you know, building a good architecture

with good code quality that could be easily changed in the future. Yeah. So the first thing

I would argue that if your architecture itself can't be easily changed, it's mostly probably

because you didn't decouple things well in the first place. So just by learning how to decouple

things, you could conceptually change the architecture later. But what we found was

And this is amazing for us to see. In the three and a half years I still worked at that original place

in 2011 to 2015. But the three and a half years after we started mob programming

we only received three bug reports into our bug tracking system on something like 40 projects that we had worked on in that time

The work that was done prior to this was getting bug reports still all the time

So what happened here was by having the testers and the product owners really being first class members of the team, they could have their input at the time we really needed it to make sure we were writing the right thing

Now, bugs can be thought of as we're introducing some work we're going to need to do later that we shouldn't have introduced in the first place

And they call this failure demand in certain businesses. Failure demand is the work we need to do now because we didn't do it well before

But we often don't really know how to do it well before. Yeah, sometimes you don't know

Yeah. But this is what we found. That was the numbers we had. There was, since then, a movement come along that's called Zero Bugs or Bug Zero

I'm not sure what they call it, Zero Bugs. It's like I will often ask a team, what's the appropriate number of bugs to have in your code

Zero. Zero. So whatever we can do, and part of it is by having all the brains on the thing at the same time, we alleviate a lot of the problems that happen when we work as individuals

When you're working as an individual, let's say you're the database expert, you're really more concerned about the database need than you are about the need of the application and how it will affect the other people that are working on it

When we work as a team, we start realizing whatever I demand is going to affect someone else here

So I have to be more empathetic about that. How can I make it where it's easy for them to do their job

How do they make it easy for me to do my job? And if we get good at that, we're just going to get fewer bugs because of that more full communication right at the beginning and as we do the work

But because we're doing things in small bits, we are delivering those frequently, like several times a day

We're going to have to have automated tests in place. Oh, yeah. And this really forces the point of having the automated tests

And if they're not very good, we can see that right away

So all of the things that lead to higher quality code when you're working as a team, we found were easy to accomplish

Matter of fact, the team keeps you honest. When you're working alone, the pressure's on you

I've got to get this done. You're focused on getting it done. When a tester's sitting next to you, they're looking at it from a tester's point of view

and a tester's point of view is that's going to introduce some other problems

in these other areas. We better investigate that before we push this code to production

They'll also say things like, there's some edge cases here you're not considering

When I'm focused on writing the code, I'm focused on this current issue

but those edge cases might be slipping past me. It's like just doubling my brain

It's doubling my brain to have a whole other point of view sitting with me. And if we have all these different people

from the team with those different points of view, we're getting a very full picture of what we're trying to do

Now, I think I've over answered that question. No, it's good. But this is just a bargain

Yeah, it's, but, you know, that's, you know, one thing that, you know, I'll follow up on

and then we got to go. We're almost out of time. But, you know, the one thing that, you know

I've tried painstakingly do for 20 years now is even in the beginning

when we're coming up with the, even the feature requirements or maybe even the design requirements phase

maybe having everybody in the room, you know, QA database, you know, the stakeholders

I have never been able to get that done. You know, I cannot get people to do it

And I think, and because we are out of time, I think part of the problem

that we have as developers trying to, you know, even if we come up

with a good methodology, like yours, right? If you can't get management to buy in

it's not going to happen, right? That's right. And in most cases, management is the problem

because either they don't understand it or they don't really want to do it

And, but to me, the biggest thing, and this has happened that most companies

that you know I've worked out in San Diego, is what we call butts in seats, right

Managers think that if there's more butts in seats typing away at a keyboard

that means they're going to do more better code. And it's completely opposite

That's right. So they're paying attention to efficiency and productivity. And what we really want to be looking at

is effectiveness and enhancing the flow of the work. So effectiveness really means

we're working on the right things, efficiency productivity efficiency is just like it's it's everybody's hard at work they're coding

away productivity just means we're getting stuff done but it doesn't mean we're getting anything

done reasonably well or that people want to use or whatever i'm after effectiveness i want to see us

of working effectively my dad used to say i'd rather work quickly excuse me i'd rather work

slowly on the right thing than quickly on the wrong thing and i i kind of like that saying it

It might be doesn't go for everything, but, you know, in woodworking and electrical work and so on, boy, it pays

You pay attention to the right things. You're going to you're not going to have to revisit to fix problems that never should have happened

Yeah. So this is great stuff. Thank you so much. I'm so sorry we have to end

But, you know, before we end, I want to make sure I ask you the question I'm going to ask all my guests

And I asked Scott Hunter this last week and he gave an awesome awesome answer But I wanted to know I it I mean because this is a personal question So besides traveling around the world and teaching geeks how to do software processes better

what do you do for fun? That's not geek related, not software related

So previously in my earlier years, it would have certainly been playing music. I love to play music

I don't do much of that anymore I don't have the time to keep my chops up

as they say but what I'd like to do now is get out into the wild

and take hikes and climb mountains whenever I get a chance I love to get out into nature

so those are the areas that have continuously been with me in some way through my life

and we live in an awesomely beautiful area of the country too so hiking is awesome around here

Right. And every day the weather is good enough to go outside

Pretty much every day. Yep. When we get the worst weather we get, it's it's like an average day at many other places

Right. Right. I was before the meeting started, I was telling Simon what the temperature is here

And he just started laughing at me because he's in Delhi, you know

So, yes, I go, I know, I know. But 90 degrees, you know, 90 degrees Fahrenheit

for a kilometer from the ocean is hot for us. It not usually this hot by the ocean Like I told him I tell everybody this is the first time I worn a shirt in four days So well thank you very much

Thank you. Thank you so much, Woody, for agreeing to be on the show and coming on the show

And we didn't really get any questions, but I hope we do get some after this

And if you guys want to see Woody back on with questions, because I didn't even get to the no estimates part

So I'd love to have you back on, you know, next year sometime when you have some free time

Excellent. Thank you so much. Thanks a lot, Woody. And take care and let's stay in touch more than we're doing

All right. So that was Woody. Woody's an awesome guy. Awesome, nice guy and very, very knowledgeable and just an all around great guy

So we're almost done with the meeting. I mean, with the session

I'm sorry I've gone over a bit. We've already done that, so I'm going to..

We've already done that because I screwed up the slide deck. And I forgot if we did that before

but everybody who's watching gets a free copy of CodeRush from DevExpress

I've known the people at DevExpress for a long time, but I've known CodeBrush even longer

because it's the only code refactoring tool I've ever used in Visual Studio

because I like it the best. And so everybody who watches the show go to that link You can download your free copy And I appreciate it And we actually going to have one of the guys who started DevExpress on at the beginning of next month

So stay tuned for that. With that, thanks for watching. Next week, I'm so excited

I'm going to have my good friend Mads Torgerson on. He's the principal program manager at Microsoft

That's what he says. He's really the new architect of C Sharp. So please, please watch next week

It's going to be an awesome show, not only talking about what's coming out in C Sharp

but also just catching up with Mads. Please, please be safe and listen to your medical professionals about the COVID-19 pandemic

Unfortunately, I'm seeing India is right behind us now in cases. So please stay safe

I want to see you back here next week and see you back at C Sharp Corner Conference

So please listen to medical professionals. I'm actually working on a new song

I laid down a demo of that today that the other guys in the band are going to be working on

I have four other musicians for this song. It's going to be the intro song for this show

So stay tuned for that. We're working on it probably in a couple of weeks, hopefully

And with that, email your suggestions to me, please, please, please at .netdave at live.com

And thank you very much. and I'll see you next Saturday