Coding Blocks - Project Management Anti-patterns

Episode Date: September 5, 2017

It's time for another episode as Joe wants to choke a developer, Michael scraps his new social networking platform, and Allen finally learns of dad jokes while we continuing the anti-patterns conversation.

You're listening to Coding Blocks, episode 66. Subscribe to us and leave us a review on iTunes to learn more using your favorite podcast app. Check us out at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net, follow us on Twitter at CodingBlocks, or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach.

And I'm Michael Outlaw. This episode is sponsored by Linode. You can have your server up and running in seconds. They have SSD storage with a 40 gigabit network empowered by Intel Xeon E5 processors. They have data centers in Asia Pacific, North America, and Europe. Mess up your network settings? You can still get into your instance with the Lish Virtual Console. Linode has a robust set of developer APIs to control your instances programmatically.

They even have custom stack scripts with some Q&As and custom built instances to meet your needs. Get started with Linode today and get $20 off using the code CODINGBLOCKS17 by heading to www.codingblocks.net slash Linode. That's L-I-N-O-D-E. And as always, we like to get started with the reviews that people have left us. We were almost going to postpone this episode because we didn't have enough. We're going to set it back a couple more weeks.

No, totally kidding. I guess I'm taking the iTunes reviews today because we don't have anybody's names by it. We've got Lazarus, Really Old Coder, and The Jungin. All fantastic names. I'm calling dibs on Stitcher just because I wanted

to say Frostblooded, Jehuzalah, and Andre Mesito. Very nice. We apologize for butchering everyone's names but we thank you very much for leaving them as always we read each one of them probably two or three times you know as we do you know i'm talking about reviews we got quite a bit of feedback on a certain word we used last episode. So what we're curious about is how do you actually pronounce the word kludge?

Is it kludge or is it kludge? It can't be kludge. That just sounds wrong. I've never heard that. It's a kludge. So overwhelmingly, the feedback we got was that it's pronounced kludge.

No, they're wrong. They got it wrong. You know what? So speaking of that, also on the last episode, we occasionally do the GIF versus the wrong way to say it. And Ambix left us a message on episode 65, and he's like, yeah, so people who say it like GIF are terrible people. Apparently I'm a terrible person. I can never say GIF. That just is wrong. Well, Paul Spoon over the Slack channel, he mentioned the idea of making the word kludge as difficult to say as

possible. So kludge sounds almost too smooth. So maybe like a kludge. A kludge. A kludge. A kludge is almost too smooth. So maybe like a kludge. A kludge. A kludge. A kludge is pretty good, yeah. Oh, that just, like, I think my ears are bleeding. That's the point. It's all wrong. It's kludge.

It's not even a debate. I don't even care if Merriam-Webster's has it differently. They can't be wrong or right. Yeah. They can't be wrong or right. They can't be wrong. Alright. By the way, for these show notes, these beautiful

full length detailed show notes, you can get those at codingblocks.net slash episode 66. I think you meant to say these are pixel perfect show notes. Of course they are. They would be no other way um also a i do want to point out so ambix said that funny thing about the gifs versus gifs um he also pointed out

uh my tip i think on maybe episode 64 was about table value or yeah table value parameters yeah and udts and sql server and he said that you have to be careful because at least in SQL Server 2012, it would confuse the query optimizer sometimes and it would just take forever. And I do want to point out, he said the way to fix it is the first line of your stored proc is select everything from that TVP into a temp table, right? I will say it's not unique to just this. I've definitely seen situations where the query optimizer just goes haywire. Right. And you have to do stupid things like your input parameters, set them to local variables or, you know, random things. So now was I, did I misread that though? Because it kind of sounded like what he was describing, though, was if you had thousands of rows in the UDT that you were passing in, right?

Yeah. But the example that you were describing, were you talking about passing in thousands of rows, or were you just talking about like general use configuration kind of thing not both i mean whatever like i wasn't putting any limits on it you know i mean joe you've had the inverse experience right where people would pass things in as common limited lists or whatever and you turn it into terrible yeah and then you turn it into a table value parameter and all of a sudden it screams right so? So, and thousands of records, right?

Yeah, you know. Oh yeah, yeah, absolutely. Yeah, and I mean, so the TVP, UDT, whatever, is pretty awful, but so is lists, and so is, I mean, just really doing a lot of stuff. Like if you're working with thousands of records, like many, many thousands, hundreds of thousands, millions of records, you're going to have a lot of problems and you're going to be doing some ugly, ugly stuff

to get around it. Yeah. Well, I raised this because the way, if I recall, the way you introduced this tip was you were talking about like common to limited lists and like if you did use this stuff or something like that to create the list and then you were like trying to parse it out, right?

And I was thinking in my head that you wouldn't be doing this string parsing on like thousands of entries that you were only going to be doing it like you're doing it as a shortcut for like configuration kind of options that you want to pass in or maybe there's a better way to say that but some like you know limit yeah like a, a dozen kind of things. And so that's why I was curious if, you know, when you were originally describing it, if that's, you know, which direction we were going. I actually had two different directions. And so one was bigger, bigger things. So, you know, instead of passing a common delimited list of a thousand entries, do it in the table value parameter way. But more importantly, I think the more useful use case other than just

sheer size of data is keeping related things together, right? Because I've seen things where people would pass in three lists and they were all coordinated, right? Like item one had to match up, item two had to match up. And that's a horrible way of doing it, right? Because now you're relying on delimiters to make sure that that data is parsed out properly. Whereas if you do the table value parameter approach, you think about it like a table, right? Everything's going to be on row one. Everything's going to be on row two.

They're all going to be in their proper columns. So that's how I was thinking about it. You know what, though? It's a common misconception, but I'm pretty sure underneath the hood, SQL Server is actually telling, it keeps things stored in the same ways. It basically uses a comma, then a pipe, and then an equal sign, and then a semicolon. It's got this whole hierarchy of deliveries that it uses

to keep track of stuff. I think you're making this up. I'm pretty sure. No, I'm pretty sure you're making this up. I mean, that's how i would do it if i were on the single server team so he's got a smile on his face right now so kind of can't trust anything he's saying right you guys ever have you ever been in like a mixed crowd of people whatever you're hanging out somewhere and you're you know maybe you're in line in the movies or something you hear someone in the line say something like yo listen i'm a programmer and i can vouch for this thing and they say something that's just awful and terrible or just really dumb and you just like want to go they'll be like hey i'm a programmer

too i'm gonna choke you now you have anger anger issues i thought it was going to be moral i thought he was going more along the lines of like hey i'm a programmer i know things oh yeah well then why is the internet down yeah that'd be like no listen i'm a programmer i've been doing it for like one year and i could i could tell you right now that i could write facebook in a weekend yeah totally you kind of you kind of um i don't know that we ever talked about this but you you mentioned something kind of glossed over it and i And I think there's actually a name for it too, where you mentioned saving a copy of the arguments passed in to a local variable.

And I think it's called like input shadowing or what is it? Parameter shadowing. Parameter sniffing. Parameter sniffing. Because SQL Server tries to parameter sniff and sometimes it screws up, which is really weird. And it causes hours of frustration.

Wait a minute, though, because for those that don't know parameter sniffing, and I might be pointing at myself, could we go into more detail about parameter sniffing for a moment? Well, it doesn't make a whole lot of sense, but basically the deal is the optimizer doesn't do a great job. And I think it has to do with when the data structures underneath are where the statistics change a lot. So if you have a table that changes a lot, like, you know, has a lot of new records added daily or something. But it just doesn't do a very good job of knowing when to kind of recompile and run the query differently. And so one trick to kind of get

around that is to always set your set local variables that just copy the arguments that you pass in and it kind of forces the optimizer to kind of redo the work i guess it's bizarre yeah just because we're talking about an historic procedure in a store product yeah and the other thing too that can confuse it a lot of times is we've talked about this with static analysis on on regular programming but when you have a bunch of if else loops right like your complexity gets high once the complexity gets so high in a stored proc you start seeing these same type problems so if you have a bunch of if else if else if else things on there the query optimizer is basically like i can't i can't do

this properly it's really bizarre and you would think that you'd just be able to do like you can set with recompile to make the store procedure recompile every time but for some reason parameter sniffing i don't know why but it just doesn't seem to uh to to hit it all the time and so you're going to know there's going to come a day if you're working with sql server and a lot of data you're going to hit this one day and you're going to be pulling your hair out and you're not going to say and like you're going to stumble upon this weird person in stack overflow that says oh man just set a local variable you're going to be at the end of your rope and you're going to try it and it's going to work and then you're going to be mad you're gonna be mad yeah it's bizarre and we've gone off on a tangent here but i think it is important

though that the table value parameter thing like anything anything with SQL Server, there can be weird things happen depending on the size of data and the type of variables being used and all that. So it's a legitimate thing that he pointed out. And the way that he got around it is sort of like this parameter sniffing thing. He just took everything from that and turned it into a temp table immediately before he started doing anything else. And that sort of forced SQL Server to reset how it thought about that proc, which is crazy. Absolutely crazy talk, but sometimes that works. So, um, yeah. Hey, thanks for that. Thanks for writing that in. And also, man, Joe recurs and Joe, he, he, he writes us several times on various different episodes. And we talked about the magic push button in the last episode about how there's these random things, man, we're going to have a link to episode 65 in here in the show notes. You must click it and go

look at this page because it's a perfect example of just beyond dozens of fields. And I'm sure that nothing validates. You're going to click about 30 things on that page and hit save. And it's going to be like, no, this, this doesn't match this. You're going to go really like, really? So that was, that was beautiful. Oh, and so here was the thing that's, it's not new news, but it's been going around and man, I don't remember what episode it was that we talked about open source licensing and all that kind of stuff, but it's a big deal. Like we we the three of us know it's a big deal for the various different places we've worked at. So there's a thing coming around now that just cranked back up recently. It's on Hacker News. It's it's all over the place with Facebook patent licensing. So Apache Software Foundation basically just proclaimed

that you can't use any of the Facebook licensed BSD projects in their projects. So basically, if you have an old project that was using some of the Facebook technologies, it's fine to continue using it. But anything that wasn't using it or hadn't been released, it is banned. You cannot do it. And I don't know the exact specifics on it, but it was basically something along the lines of, in this one article, they spelled it out pretty well. I thought it was something along the lines of, if you sue us, you lose the right to use our software. If you sue Facebook, you lose the right to use Facebook's software. That, you also cannot write anything that competes with them. So if you write anything, that was the other part of it that I thought was interesting.

So if you decided to write your own little social networking type thing and you utilized any of their tools, you're going to have to scrap it. So it's kind of interesting, right? Like you can't go after them legally for any reason, which I mean, you could argue that, Hey, yeah, that's not really fair, right? You're using their tools. You shouldn't really be going after them for that. But on the flip side, you can't use it to write whatever you want, because who knows what they come back and say, Oh no, that competes with one of our image things, or that competes with one of our social networking things or that, you know, like they've got a ton of technologies

now that they use. So who knows what you would be stepping on? That's a real shame because based off of the coding box community, I was deep into, uh, my development of my new social platform using react and graph QL that I was, uh, you you know i was going to call face blocks but i guess now thanks alan that's fine you just gotta switch it over to a really or something so that goes back to you mentioned uh when we last talked about open source licensing that takes us all the way back to episode five wow we still don't understand open source licensing. And that was four years ago. And yeah, that title is still true today. Man, that's amazing. Episode five. And honestly, a lot hasn't changed since then, right? Like there's still so much gray area. And

that's basically why these things still come up. I mean, it's a shame, but it is. That's just what it is. All right. So the next thing, I'm only going to touch on it briefly. I don't know how deep I want to go into this because technically it's against the terms of service and all that kind of stuff when you do this. But I built a Hackintosh. And, man, I got to say, I love it. Oh, you're breaking the law. No, we're done. Right?

It's over. Time out. All right. It's time to kill this podcast. So, no, I created one. I'm dual booting. I have Windows and Mac OS running. It's a fairly ridiculous machine, but I got to say, like, I am really happy with it.

You're hooked? I am hooked. Like, I'm pretty excited. And I'll tell you, the one thing that I – things have gotten ridiculous in my life. Like, I really enjoy silence like one of my favorite parts of this machine other than the graphics card is the cpu fan i bought for this it's a noctua i think it's a ds15s or d15s or something dude this thing is ridiculous it's it's like twice the size of any normal cpu cooler it is silent silent we're looking at this one yeah dude and

it cools better than the d15s you said d15s it has 12 heat pipes on it 12 man like and and it's again silent just dead silent and it cools better than most water cooling solutions out there. Now it's not as pretty as water coolers by any means, but it's awesome. So anyways, that's, I will say I did follow some guides out there. Uh, you know, I stuck with most of the hardware and overall I really love it. I haven't had any issues. I've edited some videos, edited some audio all as well. Yeah. I remember reading some reviews about that one because that one was a pretty well received. It's got perfect reviews on Amazon.

There's not very many products you ever see that have perfect reviews on Amazon. They're all five stars. Like there might be one four star in there. Yeah, it's amazing, man. Yeah, and it's got like this really cool kind of vintage look about it with the color of the fan it's almost like um it it looks like a scene out of star wars yeah it's weird the the two tone two shades of tan that they chose for it you know what i'm gonna do i'm gonna take a shot of the inside of of my setup and and i'll put the image on this

particular uh show notes page it's really pretty like i'm so you you're saying then you didn't bling it out with uh like leds and no it's the the motherboard's got leds all over it my power supply has leds my graphics card has leds it's it's all lit up it's amazing but not like a lighting kit or anything like that no but it has a header for hooking up additional LEDs. Right. And I'm starting to feel like a little kid. Like I'm going to put some neons on my car now. Right.

That's what I feel like. That's what you do. That's what you do. Yeah. After the subwoofer is there. You got to have the subs in there. And the rims. Yes.

It has some rims. Oh, you can even make the LEDs inside the case play with music. So if you're playing music, it'll actually pulse to the beats. And I'm like, I feel like a little kid again. Yeah. Yeah. All right.

Exciting times. Yes. I know this news is already getting long, but I had to sneak one more in here. I started kind of thinking about SQL server and some of the weird behavior and some of the things I was griped about, like not being able to dynamically order by variables or whatever. And I started thinking,

you know what, what a SQL server is built on alien technology? I read that as Alan technology. It's built on Alan technology. It scales to everyone. We've got the pyramids. We're not real clear on how that happened. Who shot JFK?

We still don't know. Long Island Medium. I mean, maybe this is up there. Maybe that's why we still are dealing with this like 1980s syntax we don't have the sugar we've got these weird things that like no one really understands like i'm pretty sure no one in the world really understands why prime rest of it happens and maybe it's you know not of this earth i'm just saying it's possible this is very good and so anyway i started googling great mysteries of the earth to see if it was listed anywhere it's not but there's a lot of freaky stuff out there on the internet if you look for like the world's greatest mysteries i'm pretty spooked right now

i like how joe sounds kind of shocked that there's a lot of freaky stuff out there on the internet oh that's amazing but hey you want to know what's really sort of ironic about this you said is it alien you know what microsoft's new um cloud database is called right cosmos cosmo db coincidence i think not there's something to it all right all right uh getting back to planet earth, I did ask people in a recent contest via the mailing list what their preferred title was. And we got some really great responses. And I shut the tab,

but I'm opening it right now. I do know that developer won with 51% of the vote. And engineer was a close second with 31%. And what I thought was really interesting is a lot of the people who responded and did say developer would say, and even the people who chose engineer, they all kind of had a little story about it. It was like, well, I work at an engineering firm and the mechanical guys give me the stink eye, so I say developer.

Or I really think engineer, but kind of, you know, it's either a protected term in the country where I live or some other reason why they ended up choosing developer. So it does seem to me that even though developer won by a healthy margin, it literally had the majority. It did feel to me like engineer was still the preferred term. You know what's funny about that? There was one comment I read when you posted this up on Reddit that I thought was probably the most true of anything anybody said was, I put whatever will get me the next job the best.

Yeah. I mean, honestly. Yeah, we'll put the link to the Reddit in there because we did get, I think it was like 170, really good comments. Like, I mean, 130 of those were probably like mean jokes, but like the 40 or so were really good ones. I'm kidding.

They were all really good. We're all really good. And it was just kind of interesting to hear people talk about the reasons behind it. So what was your choice what was yours uh whatever will get me the next job oh that was your comment no uh i don't really have a preferred term about you guys alan uh i think maybe from my Amazon days, I prefer engineer. And I treat it like an engineering type thing. I literally treat it like a problem. It's not just hack away type stuff. So I think that's what I internalize more. I agree. I like engineer better too, because it feels like it's more, you're taking a bigger picture,

you know, into the, into the equation. Like you're, you're looking at something more holistically. Yeah. I'm not a task doer. Like you don't just give me a task. I'm going to do a task. I want to think about how it integrates and how it works with everything. Yeah. So that's, I, that's why I feel like that. I do understand though, that in certain places of the world, engineer is a protected term. It means that you have certain types of education. That's the guy that's in charge of the train. There you go. There you go.

Bringing it back around. All right. Awesome. Yeah, and a lot of people did say with like the terms like programmer and coder to like, they felt that was only a very small portion of the job. It's like calling like calling yourself a typist, right? It's a only a very small thing. So they didn't really like that term. Um, I guess if they were to be more accurate than instead of programmer or coder,

it should just be like a code reader. Oh man. That's 90% of your job, right? That's right. That's a very good point. Well, you know, kind of on that note, the next story I want to mention is especially for people who are listening to this podcast right now, there's an article that came out recently from a blind programmer who kind of talks about the way that he works and deals with kind of listening to code

audially and kind of working and dealing with that. And they actually played a couple snippets of how what he hears at the speed that he listens to in this blog post. And man, I know a lot of listeners will listen that like, you know, one and a half to two and a half, maybe speeds. This listening to these audio blips at 450 words per minute it sounds like a modem like i just can't imagine parsing stuff you know but i do think about you know i could kind of scroll through a file pretty quickly and you know get a feel for what's going on without necessarily seeing every word so i don't know if that's what's going on here but i was pretty impressed here in the audio that's awesome man that's crazy to think about. 450 words a minute.

I'm just trying to think how you would even... You're scrolling through a file to get somewhere into the middle of it to figure something out, right? Via audio. Only by listening to the code being read to you at 450 words per minute. Just shows you how impressive the human mind really is right i mean it adapts it's pretty that's incredible stuff yeah yeah and when you're like

if he like visualizes that in his head at all but then i guess why would you yeah because if you're blind why would you visualize anything, maybe? I don't know. I don't know how it works. Crazy thought, I guess. It's cool stuff. That was a great article. We'll have a link in the show notes, and you can read about it. Yep. Yeah, if only there was a link. We'll have it. And also, we didn't mention earlier,

but we are on new microphones tonight, so let us know what you think of the sound. Yeah, if it's bad, don't't tell us we don't want to know we would uh yeah after the money spent we might cry if you couldn't hear us yeah but no seriously we'd love to hear what you think i mean we're always trying to go for the best audio give you guys the best listening experience so yeah totally it's supposed to be great for voices and kick drums so and we have both yeah so with that let's head into the main topic of tonight's episode project management anti-patterns last time we talked about software design anti-patterns which were kind of arranged by

article we found on wikipedia and so tonight we're just taking a slightly different stab look at the things from the project management point of view which is a point of view that i like to beat up on a lot yeah they beat up on me yeah i think i think uh we'll all have some opinions on these so the first one is the cart before the horse. And this is, I mean, this was about as short and sweet as it could possibly be. It was focusing too many resources on a stage of a project at the wrong time out of sequence. So if you haven't heard the cart before the horse before that literally just means the horse is usually pulling the cart. So putting the cart before the horse doesn't make any sense, right? So that's all this is. I'm sure we've all seen this happen, right? Like people will,

will maybe start putting too much resources into planning something when, when the piece that they're getting ready to integrate with isn't even built yet, you know, things like that. Like there's so many different ways that this can happen. And, and it really stinks when it does too, because a lot of times this is wasted effort. Yeah. One example, I think it was like, you go off to start, like say you're going to create the next big multiplayer video game and you spend the first three months working really hard on like encrypting your database or, you know, getting OAuth just perfect. And in the meantime, you don't actually have game. You don't know what you're doing. Like all these things are, are bypassing you because you're focusing way too much energy on something that

is just not important. It's not in the right priority order. You know, I'm glad you said that because I was having a hard time trying to think about this, because as I was, as you guys were talking about this, I was thinking of it like, well, this seems very contradictory to the MVP, right? Because, you know, you're, as Alan was speaking, I was like, well, it almost kind of sounds like we're saying that you should have like, you know, hard set lockdown requirements before you start coding. But if we're going down the MVP pattern, we want to just start writing. We want to start coding as soon as possible. We want to start getting stuff out there, get user feedback sooner rather than later. You know, that kind of mentality.

So, you know, it's OK to fail, but fail quickly, fail soon and, you know, let it be in like smaller doses. Right. But then as you said that, then I'm like, oh, well, here's an example that Alan could totally relate to because this would be focusing on scaling your application to a babillion concurrent users before you finish writing the app. Right. But that's important. I mean, it is. I'm not going to take that away from you, but I mean, it of cars it's been a joke it's been an ongoing joke though you know for a while so like i was like oh yeah okay there you go there you go you focus on

on the scalability of your application before you even finished the application or even started yeah yeah so how do you know if you're starting to do this? Man, that's, that's a harder question to answer, right? Like, I think that, I think that if you are, if you've got a bunch of people sitting around all pontificating on what's getting ready to happen and there's zero traction on any front and these, these continue, right? Like I'm not talking about on day one, right? But if you're two weeks into it and there's still no traction on anything, then you can kind of look at it and say, wait a second, why are we wasting our time on this right now?

Apparently we're not ready to get rolling on this. So maybe we should focus on the other things that need to be done first so that we can come back to this, right? Like I think it's a thing that has to be gauged that we can come back to this right like i i think it's a thing that has to be gauged after a certain amount of time has been spent and you see that there is no traction all right what if i were to phrase it like this you're you focus your concern or your worry on something that isn't even yet a problem that's possible yeah that's yeah that's definitely a way to see that well i could definitely drift there especially if i'm just kind of coding on a side project and i'll start

like refactoring refactoring refactoring for all these things i'm i'm not going to need i'm yagning right like how do i prevent that from happening one way i was kind of thinking is like if i have a set milestone like say in two weeks i want to be here or if i can schedule like periodic demos, then those will be ways of kind of preventing this. And if I'm scared to do either of those things, if I'm scared to write down what I think is most important, or I'm scared to schedule a demo, then maybe I'm already putting the cart before the horse and thinking about things backwards. Possibly. Yeah, this one's tough, because it's so unique to every situation, right? Like

if you're talking about what ifs, that might even be something, right? Like why are you what ifing something right now when we have no idea what the outcome is going to be? A good example is the whole thing or the notion of you've got an e-commerce site and somebody wants to put, I can't think of what they're called right now, but like runners down the side, right? Well, what if this happens? What do you mean? What if this happens? How are you going to know, right? The thing that you do is you put it up there and try it. A, B test or something, right? Like don't waste too much time on what if-ing things, just make them happen, right? Because the cart before the horse is,

well, if this happens, we're gonna have to do this. Well, you don't know what's gonna happen yet. Don't waste your time guessing, get some real statistics and metrics and then move from there. So it sounds like the solution then would be rather simple. Once you recognize that you have put the cart before the horse, just walk away from whatever it is, whatever that conversation is, you don't need to be having it to

just walk away from it. Yep. Start iterating towards what you can do immediately. Pretty much. Although I've seen it bite things like the other way, like, uh, the problem in reverse, where like, say you're on an e-commerce site and you start okay i want to add a new feature i want to show some new data so let me first start by going to the page adding that new data i'm just going to grab it out of the database and now it's time to start talking about rolling it out and you're like oh wait a second this is a huge e-commerce site i can't be querying the database every page load what i need to do is go and like plumb this through some sort of like you know search engine and I need to get this hooked up to the cache. And it's like, wait, so all that work I did in order to kind of prototype this or, you know, in order to get my results quickly is all completely throw away to

how it really needs to be done for production. But that's, you had to learn. Yeah. You had to learn. That's not putting the cart before the horse. You had an actionable thing at that point, right? That was literally just a learning experience saying, oh, we did this, that, you know, we have more traffic than what we thought. It's a bigger load on the database than what we anticipated, whatever, you know, that's, that's real world type stuff. But I don't think that's, that's not necessarily sitting around talking about something that wasn't ever going to get done, you know? Yeah. All right. All right. So let's move on to the next one which has a fantastic name it sounds so

upbeat and friendly the death march so this is a project where everyone on and all the staff involved are expecting this to fail and or you're compelled to continue often with a lot of overwork and management is in denial of the problem right so we've probably all been in in this situation anyone who's been in you know their career for you know any length of reasonable time unless you just started a month ago, you've been in this situation, right? So because the project is destined to fail, that's hence the name, the death march, right? These are projects that are often the result of unrealistic or overly optimistic expectations in regards to the scheduling of the project or the scope of the project or both. And this is often coupled with a lack of documentation or a lack of expertise or training in the given area that you're trying to work in, which kind of goes

back to, you know, often the overly optimistic scheduling because there's, you know, management might be assuming a certain skill level that the expertise just isn't there for. Overall, this ends up hurting the morale of the team because everyone can sense this that you know this uh impeding failure everyone's nervous everyone's stressed about it and what you know a side effect of this is that often your management is going to believe that this problem can be corrected by one of two ways. And this is where the morale is really going to get hurt. If everyone just works more hours, we can solve this problem faster.

And if that won't solve the problem, then we can just add more people to the problem to get the project done sooner, or at least on time. Yeah. And 10% more hours is not 10% more productivity and 20% more hours is not 10% more productivity. No, that's true. And you know what? Like this,

this I've seen and it almost always is a huge disconnect from management understanding the requirements right it's almost always that like this isn't somebody being overly optimistic on an engineering side typically this is almost always hey we're gonna wholesale replace the system and it'll take three months like how did you come up with those numbers? And have you talked to anybody? Have you found out what this actually entails? How does it integrate with everything else? Like in my experience, it's almost always been the manager has this idea of what he wants, but he's not tied in enough to know what that actually means. It doesn't even have to be that. Sometimes it could just be like the complication of the system you're working in too.

Like, as you were talking, I was reminded of a particular story that involved you where, you know, there was a label that needed to be changed. Three days later, the label was changed. But, you know, no fault of your own.

It was just a very complex system So I gotta share this I don't know if I ever have or not So when I met Joe As a matter of fact I had come to work for the company he was at And the very first Ticket I was given was literally

Change the label on the page I mean how hard could that be Why are they even paying me for this Man I'll never forget walking back over to Joe like two days later maybe three days later and a wiki page two pages long I was like look dude like I apologize it took me three days to do this thing and but I wrote up some instructions on how anybody ever needs to do this again to change a label on a page he's like no man everything's like this i was like what what do you mean everything's like what oh i don't remember how it was i know there were xml files and there was they were like stored in a database but there's also some weird caching and so it's

like there's this whole weird cycle going on. It was terrible. And if you remember right, they had little sections and stuff. And then there were like queries that would query like 1500 records out and it would loop over those and then query up 1500 times to the database. I remember going through all this and you couldn't navigate any of the files because unlike regular OO programming where literally you'd have inheritance, right? This wasn't this. They would have one file that would reference version three of the file that would reference version two of the file that would reference. And you were like, oh, my God.

Like, I couldn't even figure out how to navigate the project, right? And I just walked in like a beat dog. Yeah, and someone would reference like the V5 version of this function. Someone would reference the V6. And like, presumably it was intentional i don't know yeah man it's so it's funny that that's a perfect example of something so incredibly complex that well no the opposite the man management doesn't have an understanding right of of what it takes to get something done no fault of their own i I'm not blaming them. It's not their responsibility to know some of those inner workings.

But so they might set overly optimistic expectations of, of what they have a schedule that they want something done and not realize the complication behind the scenes. Now, you know, some of that complication that could honestly, as the, you know, I'm going to say the engineers, but you could call it the developers,

but they might, you know, some of that complication might be our own fault at times. Right. Definitely. Uh, yeah. So we're not like perfectly, you know, um, we're not totally in the clear here, but, but what do you do if you get put on one of these death March projects? Like what, what can you do as do as a person who's on this? The only thing you can do is communicate. All you can ever do in this situation, in my opinion,

is to reinforce to all of the management involved, where the project management and managers, what you think can be done and what can't be done, what is reasonable and what's not reasonable and just be consistent in that message to them and let them make their own mind. Well, I will tell you every death march I've been on, and I've been on a couple of like legitimate death marches where I knew well ahead of time that it was going to fail like there was very little chance for like basically zero chance for for uh for success and uh you know basically raise the flag every chance you get raise to everyone that you can and and keep digging but what i found is that it's not necessarily your manager that's the problem or their manager or even the

ceo or the board it's somewhere along the line, there's some sort of disconnect where there's either a deadline or something that isn't easily changed or isn't easy to communicate with that breaks that chain there. And so what it might be is that when that manager was hired, or that CEO was hired, you know, whoever the board or somebody said, you will have this done by this date, or we're going to find somebody who can. And so that was kind of a part of the deal there, right? So they didn't feel like they had a choice or they were handed some, some documents that said, this is what's going to be done by this date. And it may be impossible. And there may not be a great way. No, it's not like someone doesn't understand or someone doesn't know. It's just that there was a disconnect between who set the

deadline and who's actually responsible for completing it but you know what sucks about this whole thing though is regardless of how realistic especially certain type of people all three of us for sure even though you know it's unrealistic you're still going to kill yourself trying to get it done and that's the part that kills the morale, right? That's really the part right there is certain people have it ingrained in them that they never want to fail, right? Like they don't want to let people down. They don't want to miss something.

Like it's on my shoulders. I'm going to do it. And that's where morale can really take a hit because not only are you trying to get it done, but you're under crazy pressure. You're going to be pulled into meetings and whatever to where they're like, why isn't this done? What can we do to get it going faster? And you're going to say you can't, right? And then you're going to go back and work until midnight and then come in the next morning and do the same thing. And that's what really stinks. And it really is demoralizing and it's terrible. It's terrible for everything. Well, cause there's a part of you that wants to be the hero. Yeah, there is. Hey, this can't be done.

But then if you pull it off, you're like, oh my God, I did this. This is a miracle. But then you're only setting yourself up for future pain because then you're going to be expected to pull that miracle off time and time again. And it may have been just luck the first time

that you got it done. And that's very real. For a lot of Red Bull. That's very real what he just said. You absolutely, whether you're new at development or you're seasoned or whatever, you need to be aware that going too far above and beyond, not in what you want to achieve, but time constraints and that kind of stuff. You're setting the ground to let people know that you're willing to do that.

And a lot of times, if you are that guy, they will take advantage of it time and time again. It's like the 80-20 rule, right? Like typically a boss will find out these 20% of my guys kick tail all the time. They're going to load those 20% up, right? And then those 80% of people that aren't getting as much done are going to float and they're going to be working their 40 hour work weeks while you're spending 60, 70 hours. So just be aware and be, you know, conscious of the fact that that's very real, right? When you do that and you time and time again over deliver on what was a ridiculous schedule, it's almost expected of you. Hey, that's the guy that does

that, right? And when you snap, they're going to be like, whoa, whoa, whoa, why'd you snap? Right? Like this is what you do. So it's dangerous. It's very dangerous. So I think I've been on three like textbook death marches and every single time, like probably at least half the people end up quitting over the time period. It does end up being exceptionally late, like beyond all, you know, like beyond like the hard deadline that was, you know, you just can't miss it. And then the one after that, that you just can't miss. And the one after that, like it, you know, way past the many deadlines. Uh, and also it's a huge flop and everyone's really upset and there's all sorts of bad fallout. And I've also noticed, um, in at least, uh, at least one of those situations, I did end up going to the very top of my chain, like the general manager. So I laid out my

concerns. Like, I know this is kind of breaking ranks, whatever, but you know, this is like, this is, you know, I don't know if you're not hearing this or what, but here's the problem. And I basically got told to get back to work. And I feel like that's, you know, common because for whatever reason, like the circumstances that line up to create that death march are constructed in such a way that like, it's kind of, it's a death trap, you know, and there isn't like somebody being bullheaded there's like circumstances that have just kind of you know the stars have aligned on and it's really hard to get out of yep it's an unfortunate situation yep so quit is basically his answer

you know that you say that and somewhat jesting honestly, a lot of times that sort of is what the end result is, right? Well, I mean, let's put this into a different perspective. Let's reword this situation. You have, you're working in an environment where they're not listening. If you're saying, well, hey, this can't be done in this period of time. And then they're expecting you to work ridiculous hours in order to get it done anyways, even though it's not going to happen. None of that sounds like a fun environment. Right. So I wouldn't be surprised if there was a high attrition rate in situations like that.

Yep. Well, you kind of got it because even if you do stick around, you do put in the time. When it does launch, it's going to be a crap fest. And so it's like, what are you sticking around for? Yep. Because this is going to be rushed, right? A death march will be rushed. Corners will be cut and there will be problems.

And the chances are that you're in the death march because the company is probably going to fail. Your division is going to fail if you don't make it. And so there's some sort of existential setup here where you're against the wall and you're if you don't make it you're going to die and you know you're not going to make it so quitting is i think a valid option for tough it's typically the ideal one so unfortunately all right well we got next well that's some weird advice that we have never given before we haven't really i don't think so no but it's legitimate you know no know what you're up against always well the next one is basically the 80 20 rule that alan just referenced uh here in wikipedia they call it the 90 90 rule which is the 90 of the effort uh all right well i forget

how they say it but basically uh 90 of the time it takes to do a task uh wait help me out here no no you're good keep going i want to hear this there's a resolution somewhere the last 10 of a task takes 90 of the time all. How about if I just read this from Wikipedia? Please do. Save me. The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. That's 190%. I'm pretty sure that somebody's math is wrong there.

But I think they meant it on purpose, right? Yeah. Yeah. Yeah, absolutely. And there's a bunch of different names for this. The 80-20 rule is kind of another similar concept. Another favorite is the Hofstadler's law, which is the one where it always takes longer than you expect, even when you take into account Hofstadler's law

as those kind of recursive definition. And I'm sure anyone who's ever done an estimates run to this, we're like, I think it'll take me 10 minutes so i'll say an hour and then i'll double that so i'll say two hours and somehow it takes four anyway you know i don't know how that happens every one of my happens all the time and um so you know like any example bunch of examples like every blizzard game ever you know it's like released late 2017. And sometimes like 2020 comes around and you're like, wait a second. Wasn't that game supposed to come out?

It's very common software projects. You know, it's complex. Things are hard. We've got death marches. We've got all these other project management anti-patterns going on. So, I mean, it really does happen. It didn't take that long for Duke Nukem to come out. Yeah, Nukem.

Half-Life 3. But yeah, I thought some kind of thing, interesting things point out, we're just kind of like, sometimes there's different definitions of done, like a programmer will often think of a ticket being done as soon as they get that commit in. But a lot of times there's documentation, meetings, plans for how to roll things out or incorporate

the data and things that just aren't easy to account for. And so you might think like, oh, I only have a little bit more code and I have to talk to these guys about how to finish up what I'm doing and then I'm done. But then it's that kind of that question mark that you had there ends up being a lot bigger than you thought because it requires a communication and other people and all sorts of stuff and so putting a bow on something and actually calling it done and shipping is much different than you know get push origin code complete yeah and so how do you know when you're calling into the strip push where origin master it's not it didn't sound like he said origin the first time but i origin origin yeah it was some like this is the next pronunciation question that's going to be in the slack conversation

get pushed where i'm sorry to where origin uh so how do you know when this is uh when you're falling into this trap and i just put on here like have you made any estimates at all if so you're very likely in danger of this problem very likely or it's already too late you've already fallen into it yeah yeah Yeah. Yeah. And so I was kind of curious how you prevent it. And actually Stack Overflow had some really nice suggestions. And it basically broke down into or boiled down to doing things in small chunks. And so kind of like the agile methodology is all kind of built around preventing this sort of thing, right? We do things in small chunks.

We estimate them in small chunks. It makes it easier to do things more accurately. And when we do have a big blowout, you know, usually it's a little bit more contained. So just by doing things inflow answers, which is just try not to estimate if you don't have to. Because it's just setting yourself up to lose. The house always wins, guys. Okay, let's take the devil's advocate approach to this, right? Because we would all love to just be able to program in a vacuum, right? Like, that would be amazing, straight up. Hey, here, go do this thing.

All right, I'm going to make this the most perfect code on the planet. But how do you let upper management know when something's going to be done in a reasonable amount of time? Like that's, that's always the thing, right? Like there's always going to be some downward pressure to say, Hey, we need to get X, Y, and Z done. Right. And then there's always going to be the people who are doing it. They're saying, well, I don't know if we can get it done

in that amount of time. How do you communicate that properly if there's not estimates? Just out of curiosity. Who doesn't have estimates? I feel like there's not a lot of places where you can get away with that sort of thing. But I do think communicating early, as early as possible, even if it's way too late, you should still do it as early as possible. Because it's one thing to say, you know what, this is coming a little hot or this is taking longer than I thought. You know, I said Friday, but it's going to be longer. I don't know. That's so much easier to say on a Monday than it is to say, you know, for your managers from perspective, for everything to be fine Thursday night and Friday afternoon, you're telling me you've got days left. Like what the heck? Right. And that's definitely something that I've gotten in trouble before. I try to be better

about it now, but it still happens. It kind of creeps up on me where like, I really do think like something's almost done. I just gotta, I just gotta, I just gotta wait. It's Friday ain't happening. Yeah. This one's a frustrating one for me because I, I generally speaking don't like dealing with estimates. Like they drive me crazy because it does in my mind, two things. One, it sort of boxes you in, which stinks, right?

Because if, if there's anything that's going to make you cut a corner, it's going to be some sort of artificial timeline. And that drives me crazy. And the other thing is, it's so hard to really estimate something. And sometimes I feel like if you're truly going to do it right, that means you're going to spend as much time trying to, you know, almost micromanage what you're doing in order to get it to that point. And then I feel like it's almost a waste of time, right? Like, I don't know, I it's such a hard thing. I wish there was some sort of way to automate that kind of thing, right? Like when you're working on software, if you know that you're going to be in certain things, like there

was some way to measure that. And then that way, if another thing comes up that touches that it could look back at all the historical stuff and give you that estimate for you instead of you saying, Hey, I think this was going to be, cause I hate them. I absolutely hate estimates. Here's the, the problem that I have with estimates is that in many places where I've been at, this is the way it's treated. Okay. Let's say you have a, a glass jar, right? And you have in front of you a bunch of, you know, earthy materials to put in that jar, right? So you're like, well, okay. Um, let's say that these rocks represent tickets that are estimated at a week long. Well, okay. How many rocks can I fit in this jar? Okay. That's, that's good. So I can get that amount of rocks done and now, okay,

well, there's still some space in here. If I go to some of these smaller, uh, pebbles, right? So let me put how many, you know, maybe each pebble only represents like a three day long task. Okay. Let me put these pebbles in here. And now, um, there's still some more room in here. If I were to fill the remaining volume remaining area with sand, maybe those represent one day tickets. So I'm going to fill, fill the remaining up to sand. And that's the way management treats estimations is that they just think like, okay, if whatever our sprint cycle is, if it's a two week long sprint, for example, then we can load up each developer, uh, based off of whatever these ticket estimates were, we can fill their jar with, uh, you know, that amount. And it sounds

in theory like that should work, but the estimates aren't rocks, right? Like that rock is a hard, non-changing thing, right? Unless you smash it with a hammer, but we're going to ignore that. But, you know,

but the point is, is that the estimates are fluid. They're unknown. Like they're total guesses. We, if we knew, then we wouldn't call it an estimate. It would be,

this is how long it will take. This is it, right? This is the actuality. But it is an estimate and it's just a guess. So we can't treat it as, hey, let's just fill up these jars. I've never been in an environment, but would totally love to be in an environment where instead of the tickets being estimated on how long you think it's going to take to produce something, instead, if it was flipped on its head and the management or the product team or whoever were to assign dollar amounts to it,

and then the teams just go after like, what are the high dollar tickets? The ROI, right? Yeah. We're talking about return on investment. Which ones are going to produce the most ROI to the company? That's the ticket I want to go after because if I succeed in getting that ticket done, that's the one that's going to make me look good to the other people, right? I'll take it a step further because I like that approach. I think though that it needs to be a combination of things. I think you still need to have some

sort of guesstimate on there. Let's call it an educated guess on there. But then you take your ROI and you attach it to the estimates and you say, okay, this one we guess will take about two weeks and the ROI is high. This other one is going to take six months. It might have a high ROI, but the amount of time to get to that ROI may not be as valuable. So I think you marry the two, but I think what you said about the rocks and the glass is a perfect, perfect analogy because really what it boils down to is unless you're working

in a true, let's, let's just say agile right now, unless you're working in a true agile thing where sprints don't readjust in size, right? Like nobody's allowed to add something to a sprint, which hopefully all three of us can agree that that's not necessarily the best way to do business, right? Because there are some things that are more important than whatever you've currently got. The problem is though, is typically what happens is your sprint's going to get interrupted with additional work and additional things that you need to happen. But the expectation of what was originally thrown in there never changes. And that's where a lot of the problem comes in, right? But I don't think we can get rid of estimates, I guess is where I'm going.

But on the flip side, I think that marrying it to something like, hey, what is my return on this? And then looking at it and saying, okay, well, I can get great returns on this shorter term one, you know, versus this one that's going to take, you know, six months and 20, 20 men working on it, whatever, or women. But, you know, I guess that's where I'm going is I. Well, there's another approach to this too, that where, you know, that a friend has mentioned before, where it's like, if the uh the the management team were to assign like i'm willing to have someone work three days on this thing if they can get it

done in three days cool but if they can't right and so that's where like maybe if you knew like the roi with what they're willing to spend on it time wise then you could kind of have an idea about like you know man that's a high dollar roi do i think i could pull that off and then and then maybe have the conversation about like hey let's maybe dig into this maybe we can break this up into something smaller and like iterate towards it yep but um you know, because maybe, maybe the amount of time that you want to spend on it isn't realistic, but, uh, yeah, I, I hate just being given a task, like some random thing and then saying like, Hey, how long do you think it would take to do that? Let me write it. And I'll tell you how long it took me. Because inevitably what's going to happen is if you put too much and they're going to

be like, why is it so much? And if you put too little, they're going to be like, why is it so much? And if you put too little, they're going to be like, Oh, that's another thing. Right. And so, yeah, I mean, I don't want to go too far down this hole because honestly, estimates could take up a whole show, right? Like we could really, I remember like being in school and like, they would say to add a certain percentage, you know, onto your estimates to, to give yourself this kind of, uh, you know, leeway just in case if something went wrong and then sure enough you know you're like i know the math i know how to do these estimates all i gotta do is like take where i really think i could do it in add this extra buffer to it boom there's

my estimate and then like you said hey why did you say it would take five days to do that well do you want the real answer because i really don't think it'll take five days but i was trying to get myself a buffer just in case oh well in that case let's go with the real days right and then you're held to it right and then you're like oh crap then yeah there's this pressure to give these low ball estimates or else you look like a dunce right and like we know we've all been there i'm sure we're like looking around tickets or something you just happen to see one in somebody else's queue and they've got three days on it and you think it's an hour and you're like oh well if that's three days i'm gonna go put five days on some of mine because apparently that's what we're

doing but you know i mean going back to like team morale and uh you know we've talked about the imposter syndrome before right and i think when it comes to estimating efforts, the imposter syndrome, oh, I mean, it weighs in heavy. Oh, yeah. Because if you're like me, then you look at that ticket and you're like, oh, man, I don't know, a lifetime? Like, huh. I mean, it's a label. So it's more like a sentence to you. I've got eight XML files I've got i gotta go and edit find which versions are using

i don't know a month what's reasonable here like you never this is the day because no one's gonna believe me right because that imposter syndrome is very real so it could totally mess with your head and throw off your estimations and then then you got to know that that's probably why your management is coming back to you. Like, why did you say it would be so high? Right? Yeah.

I mean, it really stinks. Like, look, there's no right answer. There, there really isn't. There's,

there's been articles and books written on how to estimate things and they're all wrong. Like straight up, there's nothing right out there because you can't know. Cause chapter one should just be, just don't do it. Right? No,

try it. Try and do good work. And here's the bad side too. If you estimate too low and you get any of those right, then you're going to start getting all of the work from now on. You're going to get hammered with stuff and you're like, yeah, you're going to be overburdened.

It's not a pretty situation. House always wins. Yeah. All right. So mine, I feel like you guys gave this one to me on purpose. I don't know if this was out of order or what. Like, I'm not sure.

I'm a little hurt, maybe. Not really. I don't know. Is this one about scaling? Something like that. To a billion users? Kind of like that. So this one is over-engineering.

Spending resources making a project more robust and complex than it is needed. Now, I am going to preface this. First off, in my very high voice, I don't do this at work. Like I on on real things. I am very much middle of the road versus it. And then we'll get into this, but I usually am seriously between, I want elegant, but I want functional and I want, you know, reasonable amount of time. So that's real life side projects. I am totally this guy, like, Oh my God, like I need this thing to be able to scale across Azure, AWS, Rackspace,

and every other platform on the planet. Right? Like, and I need to write to be able to scale across Azure, AWS, Rackspace, and every other platform on the planet. And I need to write an interface that will make it easy to do this. That's how my brain works. Because that's the perfect world, right? It doesn't really exist, so I'm going to play however I want. It's my backyard. All right. Because clearly this new social platform that I'm working on is going to take off.

It's going to be amazing. Everybody's going to want to join Facebook. So I need it to scale to a billion concurrent users. Yes, across every cloud platform on the planet. So, yeah, some of the points that they had here were designing a product to be more robust or complicated than it is necessary for its application. OK, so that might that might fit my side projects. This is interesting and this is useful to know. Over engineering can be desirable when safety or performance on a particular criterion is critical.

So think about something. If you're writing software for the medical industry right it might be important that that thing works right like well i mean we could take it even outside of the concept of uh software and just say like you know if you're building a plane yeah totally this bolt may only need to hold you know a hundred foot pounds of pressure on it. But you know, if you had one that held 200, that's okay, right? Right. Yeah. So, I mean, there are situations where it matters, right? If, if you're running software for the banking industry, you better make sure that stuff secure, right? So there's probably no such thing as over-engineering and getting security right in that case, right?

Spend enough time on it to make sure that the problem is there. Did I hear you right that if you're making stuff in the baking industry? Banking. Banking. Oh, I thought you said baking. And I'm like, wait, why if I'm... No, I think if you're in the baking industry and you're worried about security you are over engineering because betty crocker doesn't care you don't want nobody stealing your pies i can promise you yeah yeah

chef boyardee yeah so that can be desirable um wasteful it is typically wasteful in terms of value engineering right like if you're over over engineering something you're wasting money you're wasting time you're wasting a lot of things. It's typically a contradiction to the KISS principle, the keep it simple stupid, and the less is more concept, right? Just get it done. Get it done in a way that makes sense. It's not too complicated. A lot of times, like, so I don't know that we've wrapped up those domain-driven design. We'll probably revisit it because there's still some more stuff there, but we needed a break because our brains were melting. But we talked about it there. If you are doing an application that's no more than CRUD, right?

You have a form and it's getting thrown into a database table and you want to populate a grid on a page with that same information. There's no business rules. Domain-driven design is over engineering, right? Make a CRUD application with a very simple setup. That's a way to keep it simple. You can make your user interfaces too complex. They had an interesting notion on the Wikipedia article where, you know, you create a text editor, but now you've got all these various different formats you can save it in. Somebody just wants a text editor. They don't want 30 different decisions when they go to save the file, right? Like, I just want to save this text.

And then the last thing that they had there was, I think, basically kind of what we're getting at is, you know, making things that are way more powerful than what the need is. Who knows if your social platform is going to get big? Look, Facebook didn't build Facebook the way that it exists today. The first iteration of that thing, I believe, was MySQL and PHP. So it didn't exist in the form that it is today when it first started off, nor did LinkedIn, nor did LinkedIn, nor did Instagram, nor did any place else.

Instagram, when they started off, they had no clue they were going to blow up. And they actually, by the way, I've mentioned it before on the podcast, they have an engineering blog where they talked about, man, we started facing some scaling issues. And so what we did is we started sharding things off. So it's an iterative approach. Don't start off trying to do this stuff like I do all my spare projects. So that was mine.

So let's ask the question of how do you recognize that you're over-engineering something? Joe? I was thinking, it's kind of like what we talked about the Carp before the Horse. If you're afraid of the next demo

or you're afraid of setting a milestone or if you write down a list of things that are important for your next demo or milestone and you're not really working on it, then you may be over-engineering. Yeah, I would I might even say that if there are certain features,

so side projects aside, because would, I might even say that if there are certain features, like, so side projects aside, because honestly, like, maybe your goal is to learn how to scale something, right? So that's, that's different than you've got, you're at work, and they say, we need feature ABC, right? And all of a sudden, instead of working on feature ABC, you're like, No, man, I need to turn these things into microservices. Before we do this, you're like, no, man, I need to turn these things into microservices before we do this. You're not working towards that feature, right? So maybe just taking a step back and looking at what you're doing and are you moving towards that goal? Or are you just working on something that's tertiary that doesn't really matter that much, right?

Or it's not solving a problem that exists yet. I think that might be the key right there. If there's not a problem you're trying to solve that is some sort of pain point, then maybe you've gone this route. Do you? Well, I was kind of thinking of, there's the book that we've referenced before. So this one is almost kind of something near and dear to my heart, maybe Joe's heart, your heart too, about related to testing. Because from a management point of view, they might want to consider unit tests as like, we don't need that. Why would we need that? Just focus on getting the job done, right? And I think we've talked about the book, The Art of Unit Testing in the past.

And there's definitely some conversation in there about if you do your testing, the effects of doing unit test before versus after, i.e. a TDD approach, and the effects that it has on the team's ability to develop faster and more accurately, right? And so it's a careful balance in my head from the developer or engineer, depending on your term of choice point of view of writing those unit tests versus the way management might perceive something like that because you know they might think well why do we need this now we don't we we're still trying we're

still in initial development i don't see that as over-engineering though. That's just where... Well, you and I wouldn't. Well, no, because I guess my thing is that is, that's provable to be valuable, right? Even in a simple case, that's provable because you can say, hey, we were able to make sure that this bug didn't go out because there was a unit test in place. But I think where over-engineering might come in, even within the unit test, is if you're trying to get 100% coverage, right? Because I've even heard people say, test the most important parts of your app, right? The most. make sure that that has good

coverage. And then the other parts that really don't get used or changed that much. And then it may not even be that important to have them there. So I would think that over engineering in that case might be just, you know, why are you trying to get a hundred percent coverage, right? Does it matter at that point? But I, I, I would disagree. So yeah, I'm not as diligent about adding unit tests as what you are, for instance. But I do think the importance of it is off the charts. The more I've programmed, the more complex systems I've used over the years, the more I firmly believe that you should have them in place and you should have some sort of framework in place to ensure them that

when they're going to build servers and all that kind of stuff, they're, they're valid. So I don't, I don't see that as over-engineering. I see that as a critical part of having a, a sound piece of software. Yeah. We're all engineers here. i even think management i think so that's why i again because we're talking about like the you know from a project management point of view right they might look at uh it's a waste of time to spend time writing those you know i'm just trying to think of like a what would of what might be a real-world example that we face regularly, right? So, I mean, once you convince your,

once you can show that benefit to your management team, it's like a one-time kind of lesson, right? Like they get it and then it's done. But I think that's the key, right? Over-engineering, the true sense of over-engineering is there isn't that value to it, right? Over-engineering is literally I did it for the sake of I wanted it to be able to do this. But it didn't add any real value at that point in time. I guess that's where I'm going.

Like unit tests have a clear value, right? Especially when done right and done the proper amount. Whereas it's always going too far. The over-engineering is you've got something that works, it works well, but you wanted to take it to that nth level to where it was infinitely extensible or something, right? Like who knows what it is? I guess that's my gut feel on it. Just imagining being at a company and you get bought by somebody and the new company comes in or the new manager comes in and says,

you know what, we're rewriting everything on Spring. We're going to do a plug-in architecture. And we're like, wait a second, there'd only be one plug-in. But that's what the thing does happen. Yeah, over-engineering. only be one plug-in you know but that's what the thing does happen yeah over engineering so hey who's doing the bag this time uh it's been a while before i did it joe lead us with a bag all right i'm gonna beg for reviews because they're really important to us and i know it's annoying when we do this and so many of you have done it and we really appreciate it but it really means a lot to us if you go to www.codingblocks.net slash review we'll have a bunch of links to make it

as easy as possible if you don't use itunes that's fine um stitcher uh is great um podcatcher there's a couple we've got a bunch of links on that slash review link there. And if you just take the time, drop some stars in there, all the stars, say something. We greatly appreciate that. And then if you have something nasty to say, just email us and we'll eventually read it and be sad about it for a while. Yes, we truly will. There should be an anti-pattern for asking for five star reviews and then nasty feedback in email we we didn't ask for five star reviews we just want an honest review that happens yeah i just want five star i mean wait i want we prefer for you guys to leave a

review please leave us a review and tell us how happy we make you. Um, yeah. All right. Well, with that, we, uh, lead into my favorite part of the show. Survey says,

all right. So last episode we asked iPhone eight, it's the iPhone we've always wanted, or it's evolutionary not revolutionary or lastly it's time to switch to android all right let's see i guess since joe just did the bag i'll let you go first alan okay so i know you iphone out there. I know your types. This is evolutionary, not revolutionary. All right. All right.

And I'm going to go with 40%. 40%. I'm going with 40. Okay. Well, I think a higher proportion of developers use Android already just because of the ecosystem. So I think that 40% are going to say time to switch anyway. So I'm going to go ahead and bump this up to 62% for time to switch. 62.

It's pretty big. 0.3. We said how many were going to respond to the survey that way we all know like half the people are going to go out and buy it anyway yeah that's true that's a very good point 62 are going to threaten not to right okay fair enough just like me i don't believe that man well until we see the price right yeah we don't yet know what the price tag is really going to be on it 1200 base price i've seen there have been rumors that, yeah, it's crazy. Yeah, insane. Sad. So when are you getting

yours? Yeah. Al's already in line. Yeah, he's already got it. Actually, he's not sitting. We've got to sit in right now. He's sitting at Best Buy. I'm going to pre-order it September 12th. Yes.

Alright, so you said 40% evolutionary, not revolutionary, Alan. And Joe, you said 62%. I'm going to ignore the fraction. For Time to Switch. And Joe wins it. Really? Oh, my gosh.

No, but that's got to be because most everybody's not an iPhone user that answered that. He wins doubly. Because not only was it the most popular answer, he also didn't go over. That's ridiculous. How high was it? 65% time to switch to Android.

Hey, smart people out there. I'm just saying. But you know, the problem that I have with that sentiment is I want to agree with you, except Android phones are getting up there in price, too. Not that high. Man. Come on. What, the Pixel's like $900, right?

No, man. I got two Galaxy S8 Pluses for... Oh, you got them well after the fact, though. What if you got the Note 8 as it's coming out right now? No, I got it like two months after it was out. It wasn't a long time. Maybe, yeah, two months. They were running good deals on it, and I was like, okay, I'll get them.

Now, I will say some of the phones are ridiculous. The regular price on an S8 Plus is $850, right? But, I mean, look. These things are getting more expensive than laptops now like seriously the yoga and hp specter review that i did the from the sounds of the rumors if you were to get the fully loaded iphone 8 with the max gigs of ram or or storage you're looking at more than what those two-in-one laptops run like decked out with you know 512 gig hard drives and all the ssds and all that like phones are getting ridiculous like straight up insane like pretty soon i'm gonna go to i'm gonna get me a flip phone i mean the new the new Pixel 2 is coming out, right?

The rumors are that thing is going to go up to $870. Up to, but is that maxed out with everything? Because this new iPhone, yeah, this iPhone, they're talking $1,200 base, right? Like that's, come on, man. I'll go buy a used car. Well, that's some of the rumors. I've seen rumors where it was $1,000 base. Okay.

Yeah, still. I mean, they are getting expensive. I've seen somewhere it was like $1,400 maxed out. But yeah, I mean, whatever. It doesn't even matter. It's a lot. The fact that we're even close to four digits for a stupid phone. Yep.

Totally. It's ridiculous. So, yeah, I'll be getting one of those. Exactly. Oh, but I'm not going to be happy about it that's right that's that's what's important here i will be handing that money over with tears in my eye um all right so today's survey is having multiple monitors is great, but are they a handicap or a hindrance or a must-have? Your turn, Joe. Wait, no, no, no.

No, no, no. Oh, we can't answer. Don't mess with the jury pool. Okay, we're not going to mess with the jury pool. Hey, I do have a question for you. You said you were going to bring it up on the show, and we probably should have done it in the news, but it's probably good that we didn't because it was going to go too long.

So we're going to do it now. You've been moving around your house recently in terms of work because typically I'm looking at you sideways because you have your monitor flipped up sideways with the camera on it, right? But you've been bouncing around the house, and I meant to ask you about it because I know you want to talk about it on the show. My guess is you got tired of being in the same spot every day,

all day. Is that, is that what was going on? Uh, no, we will talk about it in episode 67. Oh, come on.

Why are we doing that? What? What? Yeah, man. Don't go messing with my survey man all right then whatever yeah what alan's referring to about the sideways though i don't know if we've ever talked about this but if you have this is the most annoying thing it's so frustrating like i can't stand it but if you have the apple thunderbolt monitor

right and you decide to turn it on end so that you can just see the entire page web page that you're looking at like everything on it right so portrait mode yeah um you can't rotate the camera nope there there's nothing in the software that will allow you to rotate the view of the camera and it's crazy to me that you can't do that the phone can do it just about everything can why why can't a thousand dollar monitor right agreed yeah yeah i mean yeah right now we're putting it into that kind of perspective where it's like a phone that costs as much as the monitor can do it why can't the monitor do it right it should be able to do it it's got more space for more goods and stuff yeah for more guts yeah so all right so i guess i'm not gonna find out until next next go around so we'll be recording

again tomorrow night um not really so that leads us into alan's up and coming favorite portion of the show it's time for some google feud yeah this has moved in my favorite portion all right i got my keys ready wait no, no. No, you're doing it wrong. You're not supposed to type. I'm not supposed to type. How do you forget this every time? I don't know. It's so exciting. It's 11.17, man. I see the 11.17 eyes over there.

I got this. He's like a little kid. He's like, I'm going to type. I got this. This is purposely why I don't put these things in the notes because I know your audience, right? I know that you two guys would be like, got this this is purposely why i don't put these things in the notes because i know i wonder know your audience right like i know that you two guys would be like oh wait let me go ahead and type this see what it does oh i know the answer michael all right so keeping in with our theme tonight

of project management we're going to start with the first one is Kanban is not agile. Okay. I like that answer is awesome is awesome. All board so is not agile is on the board however it is the last on the board but by family feud rules you would take control of the board ding yeah uh top answer is the japanese term for auto-nomation am i not automation auto-nomation auto-nomation yes i said that right yeah you did yes yeah i'm gonna be corrected about it it's probably a kludge all right second answer is kanban is the new bacon i don't get that but i'm excited about it i'm about it sounds good kanban is agile and the number four answer is kanban is based on a model of

we'll never know it just ended there so the reason it said is the new bacon, there's actually a site called agile bacon.com and it came up. That's really interesting. All right. Uh, and by the way, for those who don't know what Kanban is instead of agile, where you just, you know, stick things in a sprint and you say that you're going to get X amount of work done. Kanban is just order the things, the most important, put them up at the top and just have people work through it, right? That's the gist of it. I love that approach. But, yeah, that's what it is.

There's a pretty cool-looking shirt that says Kanban is the new bacon. Kanban or Kanban? I say Kanban. But it's spelled K-A-N-B-A-N for anybody out there. I'm sure I'll get corrected at some point. It'll happen. Can bond. All right.

Keeping along with the project management theme, Scrum is a waste of time. A waste of time. Show me a waste of time show me a waste of time i was close joe this is your opportunity to take control of the board scrum is scrum is long google surveyed a billion users and asked scrum is long all right so your first answer is scrum is dead whoa second scrum is not agile he's seeing a theme here scrum bad. Scrum is built on transparency inspection. And lastly, Scrum is agile.

So both of these have contradicting answers. Yeah, man. Yeah, whatever. That's some interesting articles. All right. So the last one. Some interesting articles. All right. So the last one. Why do project managers.

Your turn, Joe. Why? Why do project managers? Why do project managers? Why do project managers Why do program managers? Project. Project managers. Why do I feel like he's typing this? Why do

I don't know what they do. Why do project managers mean to be in tickets? I don't really have any questions about it. Why do they use agile? That's this one. Why do project managers use agile? I want to say like why do they use agile that's this one why do project managers use agile i want to say like why do they reassign my dang tickets show me why do project managers reassign my dang tickets that was also for the agile yeah yeah i was number one answer why do project managers need to understand strategy?

Next is why do project managers fail? Why do project managers manage project scope? Why do project managers use Gantt charts? And lastly, why do project managers fail to plan? Interesting. Yeah. I wouldn't have thought of any of those.

Yeah. I don't think like a project manager, apparently. Apparently not. All right. I do enjoy that show part. I like that it's now evolved into its own show. Yes, part. Does that mean I get to be the host of a game show?

You can. life came true life lesson came true lifelong goal came true but know that you're going to be creepy like every game show host out there is somewhat creepy like they're just that's part of it what was the original guy's name from family feud richard dawson oh he was creepy. Yeah, he was known for being very creepy. Yes. All right. Well, speaking of creepy, let's talk about scope creep. Yes, sir. See what we did there? We did. All right. So what is scope creep? This is when you are adding new features to the project after the original requirements have been drafted and accepted at any point after the project begins. So this is also known as requirement creep, function creep,

and my favorite, the kitchen sink syndrome. And although this is considered similar, but considered distinct from feature creep. Okay? So this occurs when the project isn't well-defined, it's not well-documented and, or it's not well controlled and it can be a result of a poor change control. So,

you know, your customer or users want new features and the project management team doesn't properly account for those. And instead they just, oh, yeah, we'll do it in this one. Could be a lack of defining a project's success metric. So what are the objectives of this project. Uh, it could be partly due to weak project manager or executive sponsor, which is kind of like the example I just gave where instead of, um, stating, okay, that's great. You know that you want this new feature. We will be sure to include that in release XYZ down the road. And instead, they just included in with the current project already underway. And it could also be part of poor communication, which has been somewhat of a

common theme in some of these topics that we've talked about tonight. It could also be a lack of versatility within the product that might make someone, you know, project manager want to just include it into the current to try to expand the current scope of the project because of the amount of effort that it would take. It might be easier for the, from the project manager's point of view to just say like, hey, let's just include it. Large mega projects will often fall victim to scope creep. And similar to the one that you covered earlier, Alan, I can't remember which one it was.

I think it was over engineering. Scope creep, which can add additional cost to the overall final project. I definitely think that the bigger the project is the more likely scope creep is to be a really big problem i think creep happens all the time i don't even really think of creep as being such a bad thing because a lot of times the stuff that creeps up is all good and important stuff it's just that you hadn't really thought of it ahead of time and that's kind of the problem because you end up kind of reworking and re having to talk and you,

you know, you're changing all these things that you've estimated. And so you're kind of dooming yourself. Um, but if you can kind of keep things smaller, which has also been a reoccurring theme tonight, then I think that you can kind of protect yourself a little bit from this. You know,

two things. I completely agree with what you just said about the scope. Creep isn't necessarily bad because a lot of times it does point two things. I completely agree with what you just said about the scope creep isn't necessarily bad because a lot of times it does point out things that just weren't thought about that couldn't have been thought about because you weren't walking down that path. Right. And I think that's important to keep in mind. Like, don't be that person that's always banging the drum. This scope creep, we're not doing it right. Like that's, that's not necessarily the, the right way to be, but there is, there is a line that you have doing it, right? Like, that's, that's not necessarily the right way to be. But there is there is a line that you have to draw, right? Like this, this doesn't meet the

goal that we're trying to do, or this doesn't meet whatever success metric, right? Like, it's not trying to achieve that. But the other thing is, is this not the very first, like, real terminology that you got when you came into the workplace right like you'd hear it daily oh this scope creep like that i remember hearing this one in school right yeah it's just this is one of those things it's really you don't even need to explain that much because everybody sort of feels it as soon as they start doing any kind of real work i mean it's in it was part of this uh this overall conversation but it does some of these feel very like i mentioned before against the whole concept of the mvp yeah right and this one kind of feels like that as well right because kind of like what you both

said is that maybe that new thing that's being asked for, it could be some great new thing that might be of more ROI. Maybe you should do it. Maybe you should just stop and say like, oh, okay, that's the thing that we should focus on instead. But this kind of implies, it kind of sounds like, when I think of scope creep,

it's because we already have this like big waterfall kind of approach project. And it's like, no, no, no, no, no, no,

no, no, no, no, no, we can't make our deadline in six weeks from now, unless we get this task done this week. And then we need to hit our next milestone the week or two later.

And we got to keep going down this path. And if you introduce this new feature, I don't care how valuable it is. It's going to throw off my ability to get to that six week mark. So I, it kind of feels like you're already in a negative situation if this is even a thing, but it is a real thing. So how do you deal with scope creep in an mvp situation well where it really matters though i think is what you just got at is scope creep only matters if you're still being held to the coals on a particular date right that's always where these things come into play like i don't think any developer would really have any kind of major problem with oh you want this feature

and cool give me the time to do it. I'll put it in, right? It's always when, oh, we need you to get this done, but that date's not moving. And we also have five other features we're adding, right? Like that's when scope creeps a problem. Now, to the point of the MVP, the whole purpose of the MVP is get something out there

so that people can get their hands on it so that you can start iterating, right? And maybe that's why the scope creep comes in because hey we saw this we really like this feature what if we could do it like this right well by the way too the way i was using the mvp term i guess i wasn't maybe we should call it the the mvf because it wasn't necessarily meaning like the just the minimal product but whatever the feature is like let's just get the features out there as soon as we can and if i'm working on some new feature that uh you know somebody's like oh that's going to take three weeks and then somebody asks for a new one that might be more valuable like maybe it would be wise to just go ahead and turn to that one.

Like why, why continue on this long one? Right. Yeah. Cool. All right. So we all like scope creep. We hate deadlines.

We like scope creep. I don't mind scope creep. I like making stuff better. I think. Is this maybe our favorite anti-pattern? This and gold plating yeah so far i was gonna say the only creep that we would like would be if it's done by radiohead otherwise we don't want it yeah oh nice uh next one up uh smoke and mirrors uh demonstrating unimplemented functions as if they

were already implemented and uh you can see this in every e3 demo ever we're not even every demo yeah every demo i like really once this is like it's got a thing in the corner it's like real gameplay footage shown and you get the game you're like uh-uh what game was that i bought that game not this one it doesn't even have to be something intangible though by the way because have you ever been to like a car show where they're showing off like new cars and you're like oh like here's this shiny brand new whatever it is corvette camaro whatever you know here's a new fisker karma sometimes that car that's sitting there on the showroom floor at that at that uh that trade show or whatever it's really not a functional car doesn't have an engine right or

if it is functional it's barely functional like it's enough to drive it on and off the ramp yeah hey but let's get back to this whole thing about joe playing video games this is not technically true he buys lots of games yeah and he doesn't actually play them no yeah none of my analogies tonight have been about actually playing games it's all a bit about me watching them their release dates and getting involved in the the meta game around the games nothing about actually playing them the meta game around the game he's so excited about destiny 2 coming out not because he wants to play it yeah yeah i spent more time researching how i was going to pre-order it than i'm actually

playing it you haven't already pre-ordered it i did i did uh i'm gonna pick it up all right go ahead i apologize anyway uh so spoken mirrors is an idiom for a deceptive fraudulent and substantial explanation description what's funny to me is uh that's such a common term i've heard that so many times in programming scenarios that i i never really stopped to think about like what the term actually kind of means or what it came from um so i thought it was kind of funny and like, and look in the article to actually have it referred to like the illusionists or the magicians you would see that would actually literally have like smoke on stage and mirrors and you know,

little ropes or whatever, little strings doing these magic tricks and kind of tricking the audience into thinking one thing's happening when really it's like, you know, eight people backstage throwing stuff stuff around and you know lining up smoke and mirrors to make things look like they're happening when they're really not and uh so one example recently i just had to mention was american this american life did a great uh episode on um the things really going behind on behind uh the uh the magic tricks and and focusing specifically on the smoke and the mirrors and they mentioned the

80s event where David Copperfield made the Statue of Liberty disappear on live TV so we'll have a link to that but anyway obviously he didn't really make the Statue of Liberty disappear or did he? Not a good recent example is when Volkswagenwagen got a lot of trouble for um kind of

faking the mileage so if they saw they were being tested they would kind of report one set of results that weren't necessarily real and i ended up with uh like there was the head engineer ended up like 40 months in jail and 200k in uh fines over in europe yep so this can get you in trouble but i think everyone's done this so i mean every demo you know we talked about it we always put our best face forward this is something you know it's another way of saying another uh kind of meaning to the word gold playing is you kind of take something you try to make it look as good as possible you kind of fluff in some stuff that doesn't um necessarily belong. And I think this is really common, I guess we kind of alluded to, but the problem is, when you sell something that you don't have, and you can't make,

and the customer buys it, and you can't deliver, or you can't deliver when you know, you say you've got it. So, you know, I put in a little note here saying is this an anti-pattern or way of life and i think pretty much any demo ever you know there's just going to be some some bit of magic going on whether it's caching stuff for page just running too slow in a way that you couldn't really do in production or maybe mocking some data to look you know really nice when that that data is realistically not ever going to look that way um so i've had i definitely think it's both i've had bosses say hey make that data look like a curve it's like wait a second it doesn't like no it needs to fit a bell curve really yeah yep so so you do it and then two weeks later when it gets rolled out to you know production

customers and they're like hey this doesn't look like a bell curve what's up all right your data is bad yeah yeah i often think about like when i think of smoke and mirrors i think of situations where it's like um like if for example you literally just clicked on something and it only showed an image of what you really want the thing to look like in the end but it's totally there's no interaction about it it's just an image but then as you were talking i was thinking of uh do you guys watch have you ever watched silicon valley? Oh, man. It's amazing. Joe, do you watch it? Yep, a little bit.

So do you recall the episode where, oh, would this be a spoiler alert? Maybe not. Do you recall the episode where they hired a company that would just sit there and bang on their app so that their app could inflate their numbers. Yes. Right? Uh-huh. I guess that would be like our modern day equivalent of smoke and mirrors. Yep.

And buy some reviews. Yep. Totally. There's no question that's a good one. Or every beer commercial ever. What do you mean? Well, I mean, I've been to bars. I've cracked open a Budweiser, right?

And the things that happened in those commercials did not happen to me. So I feel like they sold me on an image of what my lifestyle could be if I bought that 12-pack. Let me tell you, it was nothing like it. Well, then gyms would go with the same philosophy you'd have to go with the same philosophy for that right wait that's right yeah i mean like the pictures on the yeah the gyms like all the advertisements show like the you know the the uh 20 year old like six-pack abs and uh that's not the reality when i go in there every every any kind of beauty product acts acts body spray would totally be smoke and mirrors.

It's a good thing, right? Because if they showed you, if the gym ad showed you what it was really like, which is like looking at that little fob on your keyring and feeling bad about paying that for months on end. No one would ever sign up. You can't sell disappointment. You've got to sell the dream, man. The dream.

All right. So we're down to the last one here that we've got. And this is Brooks Law. And man, I really like this one because I've been hurt by this one. So Brooks law is adding more resources to a project to increase its velocity when the project is already slowed down by coordination overhead. So basically what they're talking about is when you try and add more people to a project, when you're towards the end of the project and you're potentially running late and the thought is we'll just add more people and it'll just get done. You know, done. If we've got 10 people on it right now and we add 10 more people, it'll get done twice as fast, right?

Man, that's a lie. No, no, no, no. That's totally true. If you have nine women, they can have a baby in one month. That's not true. Wait, what? If you plan it out perfectly, if you do a good job enough of orchestrating and you can scale indefinitely all right i'm gonna get to the end of this and then i'm gonna scream

um so so there's there's part there's parts to this as to why that's not even possible right so the first one is ramp up time is real so have ramp-up time, and what they talk about by that is it takes time away from existing productive people that now need to educate the newer people on the team, right? That's real. That's happening. It's not like people are just going to come in and look at the code and just start coding, right? They're going to need to get up to date on what the business rules and everything else are. That's real. The newer members may even slow things down further

by introducing bugs because they didn't understand how everything worked in the first place. That's real. Communication overhead is also real, right? You add 10 more people to a project, that's 10 more people that you got to talk to, whether you're synchronizing on what you're doing

or those people are having to intercommunicate on things that they're working on and pieces they're touching. Poll requests, code reviews, everything else increases. I don't even read the emails from the two people I do work with. Now I've got to read it from 10 more? Exactly. And so the communication overhead is real. It doesn't scale. It just does not scale well.

It's one of those things that human interaction, you can't make it go faster. It just doesn't scale like it just does not scale well it's one of those things that human interaction you can't make it go faster it just doesn't happen um and i already did that one so here's another one that i thought was really interesting that is true there's a limited divisibility of tasks and and the example they gave was you have a hotel room right? And that hotel room needs to be clean when somebody checks out. Well, you have one person clean it right now. Okay, add two people. They'll do it twice as fast. Okay, cool.

Add two more people. Are they going to get it done four times as fast as that first person? Maybe. But then if you jump up to eight, these people are going to start getting in each other's way, right? There's going to be bumping bellies in the hallway the whole time. Right. And that's the thing, right? People are trying to get back to the cart.

They're having to wait for other people to get out of the way of the cart. Somebody's in the way of the bed, whatever. It's real. And the part that frustrates me about this is I've actually been on projects where this was the tactic that was taken. And I'm going to give two things that drove me crazy. One was that this approach was taken and it killed my productivity completely. 100%.

I was one of the main developers on a project and we ramped it up like this. Added like double the amount of people to it and things slowed down, which seems crazy, but things got slower than they were previously. But it was because there was so much coordination going on and people had to understand everything so much that time was spent from some of the main developers just trying to make sure everybody was on task properly. Right. That's frustrating. So there is definitely a point where you can't grow it that far. And then the other thing is I had a conversation with somebody one time and it's frustrating.

I'm not trying to belittle people that work in certain environments and probably anybody that's listening to this podcast will understand what I'm saying. But if you have somebody that's a warehouse worker that's stocking shelves, that is something that's fairly easy to train, right? These products go on this shelf with this label. These rows are labeled this way, and this is how you go find it. Treating a software developer like they're a cog in a wheel is not realistic because there is real educational ramp up time for that person to even become productive at a certain level. And then if that person leaves that project, there is now time spent by other people to pick up where that person left off. Like there's a cognitive gap there, right? And I've seen managers before try to treat developers like they're cogs. And that does not work. It doesn't. It can't because there's too much real knowledge of how systems interact, how they integrate, what is copied and pasted somewhere versus what's a standalone. Like these are all things that you can't take for granted. And a

software developer is somebody that has a lot of, uh, they have a lot of knowledge invested in things and that's not an easy transfer. I mean, heck even Joe, uh, you've done a very good job of this in the past that I've seen where if you knew somebody was coming onto a project behind you, you would kind of create like a, like a bullet point document of things that, you know, these are things that you need to know about, right? It took you time to create that, that other person, if they do read it, it'll help them out, but they're still not going to have the entire picture, right? Like the knowledge transfer is not easy. And this one really drives me crazy when I see people try and do this. As you were talking, I was kind of thinking like, it's oftentimes software developers

are treated like, um, you, you said cogs in the wheel, but I was kind of thinking like if we were to make another analogy where it's like, well, how many people, you know, if, if I wanted to build houses, right? Like we're, we're treated, it's, it's, it's thought of some more like that where it's like, okay, well, the more developers I have, the more houses I can build, right? And that might work out fine in that scenario. But, you know, the house next door doesn't have any bearing on the house that I'm working on, right? And whereas software development, you know, your development impacts my development. So it's kind of more like, instead of equating building software to building a house, it would be more like surgeons,

right? You can't just add more surgeons to the surgery to make the surgery faster or more productive, right? There's a limitation there as to like how effective that's going to be. Yep. And that's also why I see it more like engineering. Truly do. Because there's things that all work together. It's not like you're working. Full circle. See what you did there. See? Full circle. This also brings up something, though, that I feel like is important that goes along with this is a lot of times, even if you have subgroups working on pieces, you end up duplicating efforts, right? And now you have things that diverge in various different places, and I hate the term technical debt because it gets overused a lot, but, but it's real because now you have this huge group of people that are all working on things. They're all doing things somewhat the same, but somewhat different. different and so patterns patterns don't get repeated but code gets copied and changed all

over the place and now you have this this huge mess that you can't even really work on in a clean way anymore so like there's just so much wrong with this whole notion of just add more resources to the project right like that's i don't want to say it joking though, but I feel like the nine women having a baby in a month, that's like the canonical response back to this. Whenever it's like, oh, let's just add more developers to it, and then we'll be able to get it done faster or on time or whatever. And it's like, really? That's not how it works.

Well, look at it like this, too. Even with a computer, right? If you get a um dual processor machine it's not twice as fast there's overhead in managing the threads between those processors to make sure things get done right it's the same thing with human communication except we're way slower at it wait a minute are you trying to talk me out of a core i9 no no no the processor itself is fine but if you start getting getting quad processor setups and stuff, it's not four times as fast as that single core.

It's probably three times as fast. Yeah, frame rates drop when you add a second video card a lot of times. Yeah, it's really weird, right? It doesn't make sense, but there's definitely that point of diminishing returns, right? I'm not saying that having four people might not be better than two. It might be, depending on the project size, but then you go to eight and it might cause more problems than what it helped. And it all depends on the task at hand and the project and all that,

but it's not this magical lever you can pull and it just works. All right. Now, could you imagine taking a big software project and saying, let's say it's the three of us. It's like, all right, you get files, files alan that are uh a through j outlaw you've got k through o and i'm going to take q through z all right so you know let's meet back in a week right right it's just it's just not going to happen it doesn't work like that there's going to be a lot of overhead there's going to be communication we add a fourth person you're adding another communication change so it's exponentially increasing the number of communications that can potentially happen.

Well, you're just increasing complexity overall. Yeah. Well, I don't know about you guys, but the first thing I'm going to do is I'm going to rename all my files to start with a, easier to manage.

Could you imagine working like that? That would be horrible, man. Like, Hey, I need to change over this file, but it's funny. So the conversations come up before, like,. Like, hey, I need to change over to this file. It's funny. So the conversations come up before, like, you know,

let's set up teams where everybody's kind of got their, they've all got the same type skills. And I'm like, wait a second, don't shoehorn me in in a UI. Don't shoehorn me in into a server-side type thing or a database type. Like, I like doing all this stuff. Hey, shoehorn me, baby. That sounds good. You want to do some C Sharp?

Come on, man. All day. You know you're going to miss some JS. Wait, every one of your YouTube videos is JavaScript. I don't even want to hear about it. Yeah, that's because it's necessary to make things happen. Oh, dang it. If you want to effect change in the programming world,

you're going to be doing JavaScript. Uh, you said it. Yeah. Dang it. All right. So that, that pretty much wraps all these here.

Um, as always, we make these things funnier and longer than what we had intended to. Um, so, uh, the resource we like for this is the Wikipedia article where we went through the anti-patterns for the project management.

So we'll have a link in the show notes for that. And now it's for my second favorite part of the show. It's the tip of the week. Yes. All right. So I'll kick us off here with using multiple desktops in Windows 10. So if you haven't already been using this feature, you totally should, you totally can. I'll include a CNET does it has a great write up on using Windows 10, multiple desktops and how to navigate between all of them. So I'm not going to go through all of it. Um, but there's, you know, definitely they include visually how to do

it, uh, all the different keystrokes for the different operations on how to do it. But, uh, I will say the one downside is that I really wish that they had, um, like a multi-finger swipe action like Mac OS has. That's the one place where I feel like it's lacking. Because if you wanted to go between desktops, sure, you could Windows key control. What is that? I went to the site and the video started playing. I apologize.

Why would you do that? CNET. That's not apologize. Why would you do that? CNET. That's not awkward. Blast you. Oh, man. So you could use keystrokes to switch between desktops like Windows Control Left Arrow or Windows Key Control Right Arrow, and that's all fine and dandy,

but there is something so nice about like just a three-finger swipe between desktops in uh in mac os man i can't remember but i think if you have one of the uh touchpads for the i forget what they're called but they're like the windows certified i think they had that ability um i don't know that like external hardware would but i know on the laptops it seems like it did i i can't swear to it i'd have to find out but anyway i i do agree the the the swipe on mac is beautiful so anyways all right go ahead sorry yep all the same kind of functionality that you would expect to the ability to move an application from one desktop to the next desktop, uh, things like that.

Yeah. All there. Yes. That's beautiful. I love it. That's, that's amazing. Mine is actually came out of a necessity this past week. I had a, a merge of code gone horribly wrong.

Like I don't know what I did. And I didn't realize it until I had pulled in a few other things. And so I've known that you could do a git checkout hard and go back in time to a particular git commit. I did not know about git ref log though. So I've always done Git log. If you're on the command line, you type in Git log and it'll show you like the past commits and hashes and all that stuff. But Git ref log will actually give you something a little bit prettier and easier to read.

And, and you can literally just say, all right, get reset and then head at 10 or something like that to go back to that one. And it makes it very easy or get checkout hard. And then you know, head at 10 or something like that, and it will take you right back. So get ref log is really what I'm getting at here. And I've got a link to the stack overflow answer that that had gotten me in this direction and kind of saved my hide on something that I had screwed up. All right. That's, that's pretty interesting to,

I didn't expect to get tip from you. It doesn't usually happen, but this one, it made me happy. It looks a little sad. No, I'm happy to talk about looking out the window wistfully. I'm happy to talk about get ref lock.

That's not something you can share because your ref log is going to be specific to you oh is it really? oh that's nice oh maybe that's why it was easier for me to read then because I could look and see what I had been doing that makes a lot of sense

it's your log of actions that's beautiful are you getting ready to get stormed on? yeah it's it's your log of actions that's beautiful are you getting are you getting ready to get stormed on yeah it's like super thundering and uh what it means is my dogs are freaking out and i have them locked in this room with me and so like for the last half hour they've been like bumping into the chair i'm like i'm getting pawed to death they're walking all over the mic stand so even if you don't hear the thunder you're probably gonna hear the bang bang bang of like someone walking on a mic stand. So even if you don't hear the thunder, you're probably going to hear the bang, bang, bang of someone walking

on a mic stand. Nice. This is going back to the episode one through five days, right? This is good. Yeah. Good old days. My tip of the week is haveibeenpwned.com which we've mentioned

before, but it's never actually been a tip. This is a website run by Troy Hunt awesome website you can type in your email address and see if you exist on any of a bunch of different data dumps that Troy has collected from various nefarious

portions of the internet and you can actually sign up for it too so it'll send you a little notification so for example I subscribed to it and when my email address was for the umpteenth time, you know, showed up in some sort of data dump from a recruiter database or from Adobe or from, you know, wherever I got a notification said that, hey, your username and password has been dumped out on the internet, you should consider changing it. And so it's just a nice way of kind of knowing ahead of time what's going on. And you can actually go there and search your email and see what all you've been dumped in.

And I did actually search all our CodingBucks emails, and we are safe so far. But all my personal ones have been phoned. Oh, yeah, totally. It's horrible. So use the password manager. Jeez. The worst part is half of them that i'm seeing on here are like spam lists it's not like they got any data stolen but your email is out there and um also he doesn't put the passwords up um i don't know if he puts the actual like email list i don't think he exposes of anywhere but i know he also does a lot of work to like strip passwords stuff so you can't see if your password's up there but a lot of times

um you know at least for a lot of the breaches he said if you follow him on twitter which i also recommend or also just have i been pwned which is p-w-n-e-d he'll say a lot of times like this data dump of 70 billion records including emails and passwords. So watch out. Ridiculous. A lot of people do still reuse passwords. Good tool. Scary. And I think that's pretty much it for the show.

We talked about project management anti-patterns. We talked about our favorites and the ones we hate the most. So that's about it. So with that, we ask that you subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And be sure to leave us a review by heading to www.codingblocks.net slash review.

And while you're up there, check out all our show notes, examples, discussions, and more. And send your feedback, questions, and rants to our Slack channel at codingblocks.slack.com and follow us on Twitter at CodingBlocks and head over to the website, codingblocks.net where you can find all sorts of social links to the top of the page. You guys have heard of dad jokes, right? No.

No? Like, the corny jokes that dads would say. Al, what do you do on the internet all day? Yeah, man. This is not the first time we've had a problem like this. What is going on over there? Look, guys. Do you even use the internet?

I don't. Like, I literally... Do you even know what a meme is? I do know what a meme is? I do know what a meme is I've seen those I've heard of them yeah you know what

why do you build such a hackintosh if you're not even going to use the internet? that's the thing like I I now treat the internet like like I treat shopping

like I have a a particular thing that I want to find out about and i'm going to go find out about it and then i'm going to sign off the internet right like that we're gonna have to start yes yes knowing with alan i think so you know what joe you've hit on something we shouldn't do this man that's wrong this that that is our objective for the next episode. We're going to yes, yes, no with Alan. Man. That's an amazing idea. All right, I guess I'm going to start reading Reddit.

Okay, well, so, yeah. So there's this thing out there referred to as dad jokes. And those are the stupid little corny jokes that dads would share. Okay, but there's like this programmer equivalent of it that has popped up on Reddit that I thought I might share some of these if you have a moment. I have a moment. All right. How else am I going to get my internet, Phils?

Apparently through us. You know, it's bad. If you think that Google is the internet, then that's when you know that you're not using it correctly, right? Like the internet's the little E, right? I have my very small slice of the world. All right. Why did the function get divorced?

Why did the functions get divorced? I don't know. They had so many arguments. That's kind of good. Yeah, it's pretty good. It's a good dad programmer joke. Why was the string so loud? It was immutable.

There you go, because it was immutable. Oh, okay. Why was the list so uninteresting? It was immutable. There you go, because it was immutable. Okay. Why was the list so uninteresting? It was empty. It was forward only? It was one-dimensional. Oh, my gosh.

That's a reach. Why did the ent drown I don't know I don't know any of these I don't know because it wasn't floating oh come on

uh let's see what would be another did you hear the one about global variable everyone else did i knew you'd like that one i knew you'd like that one I'm gonna have to go before these dogs freaking run me over alright last one why was the class so good at everything I don't know

I don't know it was a super class oh man terrible