How to Estimate Badly

About this Episode

In this episode of the Acima Developer Podcast, host Dave Brady and the panel, including Mike Challis, Kyle Archer, Eddy Lopez, and Will Archer, delve into a satirical discussion on how to ensure time estimates for software projects go wrong. They explore various humorous yet insightful approaches, such as using aggressive negotiation with engineers, ignoring edge cases, and focusing on points as extrinsic values rather than consistency. The conversation is full of playful examples, with stories from past experiences, all illustrating how poor communication, over-optimistic estimates, and leadership pressure can derail projects.

The team highlights how over-reliance on tools like Pivotal Tracker or Jira without considering the actual complexity of tasks can lead to skewed results. They also mock the practice of placing value on productivity metrics, like story points, while ignoring the consistency and accuracy of those numbers. Throughout the discussion, the panel pokes fun at the missteps that can occur when management overrides technical teams' decisions, fails to understand project requirements, or implements unrealistic planning methods, using examples from both personal and industry-wide experiences.

Towards the end, the group turns their satire to broader topics like testing practices, infrastructure management, and project launches. They humorously suggest that skipping QA, bolting on security post-launch, and involving high-level executives in day-to-day decisions can lead to even more dysfunction. Ultimately, the conversation serves as a playful critique of common issues in project management and development, with a clear undertone of how these behaviors should be avoided for the sake of successful project outcomes.

Transcript:

DAVE: Hello and welcome to the Acima Developer Podcast. I'm Dave Brady, and I'm hosting today. We've got a good panel today. We've got Mike Challis, Kyle Archer. We've got Eddy Lopez and Will Unverified. I don't think that's your...

WILL: It's Will Archer.

DAVE: It's Archer. Archer? Yeah. Welcome, Will. So, last week, we talked about some structure, and we thought we would carry over, and I think we're going to table that for a week. Today we came up with, actually, it was Will. You came up with a really interesting question phrased in kind of a devil's advocacy. Do you want to phrase that up for us and tee us up?

WILL: Well, so, if I wanted the worst possible time estimate for my project, how could I do it? How could I really screw up my time estimates?

DAVE: I like it. I may or may not have some stories related to this. I'm seeing knowing smiles around the board. Okay, so I'll give two stories really, really quick. And the second one is actually the counter to the first one.

Negotiate aggressively with your subject matter experts in a threatening manner. Specifically, negotiate story points down because you don't want to spend extra time dealing with the problems that your people are thinking of that might be coming down the pipe. And a great way to do it and sound like you're not doing it is to begin every sentence with, "Why don't you just...?"

And so, you can take something really super-duper complicated...I mean, throwing the ring into Mount Doom that's a one-point story. How long does it take you to drop a piece of jewelry into lava [laughter]? It's super easy, right? Super-duper easy. Why don't you just do that? It's fine. And yeah, it's that kind of thing, right? Where the actual thing, you know, getting to the site to deliver it, you know, OSHA injuries where he gets his finger bitten off, right? That whole thing.

WILL: Take the Eagles, guys! It's [crosstalk 02:00] a one-hour flight. Take the Eagles, duh.

DAVE: Yes.

EDDY: I was going to say, don't you like the idea of having an extra cushion to your points?

DAVE: [inaudible 02:08]

EDDY: Yeah, because if you over-deliver and you get it done, like, two or three weeks ahead of time, the only thing that you get is just applause, right? Like, you got it done earlier.

DAVE: Well, so, I think this is kind of the other way around, right, where it's like dropping this in. We're going to budget two hours for this, which is plenty of time to drop a piece of jewelry into lava. And the project, as we know, is going to end up taking three months from, you know, hindsight. And that's the kind of stuff where...like, engineers often get paid to think about edge cases, and weird things, and, you know, what about this thing, and da da da da da.

And very, very smart people who are low in trait openness...openness is one of the big five psychological traits for gauging a personality. People who are low on this are very certain they're the J type on the Myers Briggs. They're judgy, not perceptive. What's in their head, they will press that down on the world around them.

And this leader that I worked with would negotiate aggressively, and because he was the CTO, every discussion was an uphill push, so, okay. And we used Pivotal Tracker, and Pivotal didn't care. Tracker doesn't care what you think your velocity is. It will tell you what your velocity is. And because the stories were getting smaller and smaller numbers on them, all of Lord of the Rings became a one-point story, which means it took us three months to deliver one point of value.

MIKE: Wow.

DAVE: And he did not like that. We literally watched Tracker go sub-integer. We had a velocity of 0.2 at one point. And that did not make the CTO happy either because he wanted the points to be big, which might be another evil thing is, like, place extrinsic value on points.

The counter to it is the second story, which I'll just tell in just one quick sentence. I had a manager who looked at me, and he said, "I don't care what your velocity is. I don't care what the number is. If it's consistent, I can bank on it." If the team velocity is 180, that's great. If it's accurate, I'm going to ship on time, and I'm happy. If the team velocity is 1.8, that's fine. Points don't matter, remember? And if I can bank on you shipping on this day, and I can queue up the next thing, I'm happy." So, if you want to mess up your schedule, focus on the points themselves as extrinsic things, and ignore consistency in your estimates.

EDDY: So, Dave, for the people that may not be aware, what's Tracker? Can you give an overview?

DAVE: Pivotal is a company that makes software, and Tracker is their time-tracking thing. It's Jira, or VersionOne, or Rally. These are all competitors. Jira is the really big gorilla kind of taking over the scene. Basically, you do this, deliver it, and then it goes into the backlog, and you put points on it. And then, Tracker gives you your to-do list against a calendar. It's like, no, no, this is your...I've been measuring your velocity. This is how many stories you have. This is when you're going to be done. And after you've been using it for about three or four months, it starts getting spookily accurate. And if you don't like what it says, you can change the numbers to be wrong.

MIKE: I had a couple of stories I was thinking of as you were sharing them [chuckles], but I'm going to go a different way. I mean, we were talking in the pre-call about the first line in Anna Karenina, which is all happy families resemble one another. Every unhappy family is unhappy in its own way. Like, there's many ways to ruin your estimate [laughs].

And I saw two kind of opposing examples. In one, product came to our team, and they had a big, international expansion project, and they had been burned by some optimistic estimates in the past. I said, "Okay, what's the worst case that can happen?" And so, the team talked about all of the worst cases and all of the unknowns we had [chuckles] and everything that could go wrong.

And we got an estimate that it was going to be this huge project that was going to take, I don't know, like, eight months or something. And then, the estimate was so big that management decided to...they said, "Oh, that's just...that's crazy." And they quit trusting our software. And this is, like, new management at the time. And said, "We're just going to outsource this." And when they looked at what was going to be involved in outsourcing and how expensive it was, we said, "Well, no, we can actually do it a lot faster than that." Ended up actually getting the project done in 2 or 3 months, way below what the previous estimates were.

But, you know [chuckles], there was, like, a year that that project didn't get worked on because nobody wanted to invest that huge amount. And engineers actually didn't even know that that was going on. We just did what we were asked to do. It was the worst case, so we gave it to you. And, of course, the worst case is not the average case. It's going to be some of the cases. So, you want to probably aim high, but that one failed.

And then, on the flip side, we did some annual planning and didn't have a whole lot of information. So, we planned out a lot of stuff quickly [chuckles], and then somebody went through it and said, "No, I don't think it actually will take that long." And they just chopped the number of our estimates in half [laughs] without any input whatsoever. And not surprisingly, a project that had that happened to has gone about double budget because when that project finally finished, it was about double budget because the earlier estimates were actually pretty good because we compared it with previous work and matched. It can go either way. If you don't trust the past experience, a similar future experience, then you're probably going to have some bad, bad, bad numbers.

DAVE: There's another symptom in what you said that I think is really interesting, which was management sent people off to go make a decision. They didn't have a discussion. They said, "Go away, discuss and decide, and then give us the decision." And then, out of context with no dependencies, or corollaries, or caveats, they're just like, "Here's the number." And because they have completely different assumptions, they made a completely different decision than they might have had they been in the room saying, "Well, what about this? Well, what if we cut this feature, or what if we brought in contractors, or what if..." you know, what if. There's no what if. It's just, this is how it will be, and it's unqualified. This is how it will always be in every universe.

MIKE: So, first key to give a really bad estimate is give numbers with no context whatsoever [laughs]?

DAVE: Mm-hmm. Mm-hmm.

EDDY: Well, I do want to say, just because the idea sounds easy doesn't mean the implementation will be.

MIKE: Well, that's an interesting one as well. Have you all ever been in a situation where product did the estimate and then told you what the estimate was?

WILL: I tell you, man, like, I think a really good idea to get these estimates really messed up...so, what you got to do, right? Engineering is so expensive, right? It's really expensive. And so, really, you got to have a business case for it. You got to have a business case for it, and this case is dependent on impact and timelines, how much money.

And so, really what you got to do is you got to go to the very highest level, like, the business folks with the spreadsheets. And you got to present your case for your engineering idea, your engineering idea to them, right? And you really got to get them, like, you have to get them aligned with sort of an outcome before you even talk to engineering because, like, you know what I mean, it's such a...you got to justify this line item expense, right?

So, you really got to go from the business case, top, top, top-level approval of budgets, and then you go down to engineering. Because, as we know, if something went wrong, it's always easier to piss off the C-level executive because they're really, I mean, they're disciplined, emotionally intelligent. They know all of that stuff. And it's easier to piss off your CEO, who maybe made some promises, even to the board, to the public markets, to all that stuff, rather than line-level engineers that might know things that you don't know. Like, as high as you can go, that is just absolutely critical.

DAVE: There's a phrase that weirdly has come up, like, three times in conversations for me this week. And so, this is number four, which is people are sometimes blind to the fact that if you have a problem and you start percolating it up the chain, your team lead can't help you with it. So, you go to the, you know, the department head, and they can't help you with it. So, you go to the engineering.

Once you're about three levels up, it is very, very hard for that person to solve your problem. It is much easier for them to solve you. And it's the same kind of thing, right? It's like, if I go to the CEO of Rent-A-Center and say, "I need this," he's going to say, "Stop needing that. Go away," right? Because that's the fastest way to solve that, especially if he's got five layers of people that he trusts, which you're going to do if you're in the C-suite. So, whether they're trustworthy or not, you've built them to trust. So, yeah.

MIKE: Will touched on something, the person on the ground who's familiar with the system. A great way to have a really out-of-whack estimate is to completely ignore what they say [laughs]. It's very easy if you're in a leadership position to say, "Well, I know what I'm talking about." You get inflated ego. It's a malady that has been present throughout history [laughs] that people will think, if I'm in charge, that means I know what I'm talking about. And a great way to get to get the estimate that you want to hear is to ignore what people are telling you and just don't even ask, right? Like, well, you know, this should be [chuckles], take the eagles, right? There's an easy way to get to Mordor.

DAVE: The thing that I'm hearing a lot is, like, committing to the map instead of to the terrain. We see this a lot. There's a specific case that I will tell people. Sorry, I need to phrase this in the evil way, right? You should make your decisions as early as possible and stick to them because, later on, you're going to get more information, and that's just going to annoy you. So, make your decisions at the point of minimum information. Never, ever, ever defer a decision, even if making it now would be hard. That's a good one.

WILL: Ooh, I got one, just to pile on. Hard launch everything. It's so cool. You have this grand unveiling, right? I mean, it's like you're showing somebody a finished product. They can get excited rather than a bunch of Tiki-tac incremental stuff you can't hardly do a press release on it. Hard launch, always hard, hard, hard launch, big unveiling. Think Apple, you know what I mean? Like, just the biggest possible spectacle. That's the way to do it.

MIKE: Nailed it. Nailed it. And let me take that a step further. You know you're going to have that big launch. You better plan everything you're going to launch on day one. Make sure you have all of your plans up front.

DAVE: Waterfall. Yep.

MIKE: Plan that --

DAVE: Don't start designing anything until you have planned everything.

MIKE: Everything. Yeah. Absolutely. And follow that plan to the T. Bonus points if you can get out ahead, you know, that means that you're really good at planning. So, if you've got, like, a two-year plan, make sure to do all that planning upfront.

WILL: And the people who did the plan should really be in charge of the estimates, too. And when you give those estimates, right? So, you lay out, this is the product; this is the timeline; this is our hard launch. Get all that stuff done. And when you present it, you should present it with a timeline, right? And this is really important, right? It's like the intuitive mind, right? When you present the thing, you want people's gut instinctual reaction, preferably in a public meeting with everybody there.

So, you just want to get people right around the table. And you want to be, like, you just want to shoot from the hip, boom. First thought, best thought. You want that creativity. And you want people...like, the accountability is critical, right? So, you got to make sure that you say like, "I think this is two months. What do you think?" so that people feel empowered to speak up in front of their peers and say, "I'm going to disappoint you and your boss. I'm not going to be pressured. I'm going to give you the real estimate because this is an art, not a science." You got to let people just go with their feelings. Let it flow.

MIKE: The more public, the better, right?

WILL: Absolutely. Absolutely. It's their time to shine, right? So, the bigger the hats you can get in the room, you know, get a CTO in there. Get some VPs in there, really, like, you know, elevate your team so that they can show what they're capable of because everybody wants to move up. And you don't get to see these guys all the time, right? So, they can really get a feeling for your ability to say, "Yes [laughs]."

DAVE: 100%. I had a scrum master that I worked for 15 years ago who loved that step 11 is the commitment. The team must commit. And we had all these blank checks. We had tickets that had been pointed that literally were, "Click to add description." Stop me when you've heard me bang on about that one, right? And it was like, no, we've got this many points in the sprint. Does the team commit to this? And I said, "No. The team commits to work as hard as we can and give it our best level effort, but this is the plan, and it's not going to go that way."

And I got a lot of pushback. So, make sure you push back on the people like that. Call them disloyal. Make sure that they do not feel psychologically safe pushing back on that [laughter], and whatever you do, never, ever, ever consider the possibility that you have not refined tickets well enough to commit to making it work.

EDDY: I do want to say that some of the things that I've noticed in my two years or so is that it's really easy to overestimate how fast a project is going to get completed based on the number of cooks you have cooking, right? Because you could add more talent, but you spend more time bringing that talent up to speed than it would take to have people who already know the context to just do it themselves. So, in a sense, sometimes it slows down the process by adding more people who don't have the context to do it. So, from experience, anyways, it's like, help is great, but you got to be smart about it.

MIKE: Well, no, throw more people at it. It'll always speed it up, right? Like, a good example is pregnancy.

DAVE: Brook's law.

MIKE: Nine women, you can have a baby in one month.

DAVE: One month. There was...I worked at...

EDDY: I think someone told me, as a response, sorry, Dave. But I think someone told me --

DAVE: It's okay.

EDDY: They're like, "Oh yeah, you can't have nine women cook one baby quicker." And I'm like, okay, yeah, but the retort was, "Yeah, but what if you impregnate all nine women? Suddenly, now you have [laughs]" –-

DAVE: Parallel development, yeah [laughter]. I worked at Acclaim Entertainment, which was not my proudest moment. They're not a great company. But we were working on a video game, and they always get into crunch time as the Christmas season approaches because you got to get your games manufactured to be on the stores before Black Friday and that sort of thing.

And they had brought in a whole bunch of contractors from our London studio, flew them over to Salt Lake, and literally just throwing bodies at the problem. And this was when I read Brooks. And so, I wrote, "How long does it take to make a baby if you assign nine women to the problem?" And I came back the next day, and somebody had written, "Two weeks, because we're going to hire nine more contractors."

[laughter]

WILL: I'll tell you what's another real needle mover in terms of team efficiency is, when the deadline starts to slip, the more people you can get on a project asking for status reports, and timelines, and when that's supposed to be [laughter], it motivates. It allows team members to have that sort of clarity of purpose because they know how important it is. Otherwise, I mean, developers, I got to be honest with you; sometimes, when we're behind on a project, we can kind of drift. We start taking long lunches. We go for walks around the office, playing a lot of ping pong.

Without that focus, you could kind of...honestly, sometimes we just forget that we're behind on these commitments. And sort of if you can have somebody every hour, every 30 minutes or so really getting the status reports, it's such a weight off everybody's mind. I forgot. I was like, "What? Oh my God. Stand-up was two hours ago." I already forgot that this project is way behind, like; oh, thank goodness. I could have wasted the entire day not updating you on where the thing was just because, like, oopsie [chuckles], what was I doing?

KYLE: I think having as many of those status updates as meetings that really speeds things up, too. So, make sure that all of those are meetings and scheduled throughout the day.

MIKE: And you want everybody to be aware of it. So, make sure to bring the whole staff in, right?

KYLE: Yeah. The entire staff.

EDDY: I was going to say, make sure everyone who's able to attend to attend; that way, it's more efficient.

WILL: The really critical people, the people you've got to have even more so than product managers who...I know they're coordinating the tickets, but I'd say the people you really, really need to get in those meetings, as many meetings as possible, is the senior technical leaders like your senior engineers, your team leads, the people who are the people who really know the critical bottleneck issues that need to get plugged to enable maybe the junior level team to do work. It's like, you got to know what's really, really going on, and you got to have technical expertise to get those real serious moment-by-moment updates.

DAVE: Yes, if you're going to clean the supply closet in a hospital, make certain that every surgeon in the building is required to be in that meeting, every single one of them.

WILL: Are we going too dark? I feel like we might be going too dark [laughs].

DAVE: I'm here for it, but yeah.

[laughter]

EDDY: I do want to also just say, someone who didn't pick up on it, just for our listener out there, all that was satire, by the way [laughs].

DAVE: Oh yeah, this is a sarcastic episode.

EDDY: [laughs] Please don't take this to heart.

DAVE: Are you being sarcastic? No [laughs]! Yeah [laughs], good times. I think we touched on this a little bit, but make sure your businesspeople are making technical decisions. Make sure your technical people are making business decisions. This is important. If you're at the keyboard typing away, writing some software and that last function just won't work because of this problematic workaround to it, just cut the feature. It's too hard to do; just change the feature to the way you want. If it doesn't comply with some stupid law, whatever, that's somebody else's problem. Businesspeople, at the same time, don't tell people how much stuff is worth. Insist on that you know the price. And we had talked about that. Make sure you're telling people what their estimates are, so...

WILL: I will say, I think, it's really important to make sure you go up the entire chain to product if you want to do something like what color should this button be, or the copy should it be, like, select, or okay, or see all. I'm going to need to check in with marketing, sales. I can't make that decision on my own. I'm just an engineer. I got to have sign-off from VP of marketing on what the okay button text should be. What is the design thing? Should it be white or off-white? I don't know. These are critical questions. Completely above my pay grade. I can't use common sense. I'm an engineer. I'm half autistic, you know what I mean [laughs]?

DAVE: I have worked at a shop where the art team would hand us comps, and they had to be pixel-perfect, or they would just stop the whole team. It's like, "No, no, you rounded this button with a three-point fillet, and I specifically specified a 3.5." Yeah, I can slice pixels. I don't like it, but I can do it because I had to do it.

MIKE: Well, if you really want to make sure your project gets done on time, you don't want to ever have your developers idle. So, make sure you get them started working on the project immediately while you're gathering the requirements.

DAVE: Maximize utilization. Absolutely.

MIKE: Absolutely.

DAVE: Absolutely.

MIKE: It might take you several months to get the requirements for the project. So, you need to make sure that they're really busy working so that when you get those requirements, they already have most of the work done.

EDDY: You know you're being efficient when you're reverting a bunch of the work you're doing because you're releasing a lot of code.

DAVE: I may have put that on a pull request this week. I love it when I can add features by deleting code, yep.

KYLE: [laughs]

DAVE: I think it was yours, Eddy. I think it was your PR that I did that on, so...yep.

WILL: I'm not going to lie. I actually...

DAVE: It wasn't your code that we were reverting. For anybody listening, it was some legacy code that was no longer relevant, so...

WILL: Anyway, I don't know, like, unironically, not devil's advocating, I like just sort of getting to work, you know what I mean?

DAVE: It's very satisfying.

WILL: I like the aspect of, like, well, just agile sprinty. I mean, unironically, I'm not being the devil's advocate. Let's just throw something up and let people look at it, not release it. But it's like, "Here. Do you like this?"

So much ambiguity can be resolved by giving somebody something that they can touch and feel and put their hands on. I'm no longer being ironic. I like giving people prototypes, and they can click the buttons and be like, "Oh yeah, it clarifies so much." I don't know; I've found there's, generally speaking, a difficulty among people who haven't sort of managed a lot of software projects to think about things in a fully fleshed-out way in the abstract. If I showed you a form, and a button, and a widget, and a web page, even if it's connected to nothing, I can get much better feedback, much faster, you know what I mean? I like that.

EDDY: I would argue that's part of your UX design person. It doesn't really fall on the developer.

WILL: You go to war with the designers you have, man. They're art school kids. Like, that's not their gig. It's okay. They're going to make it look good. That's their job. Like, I don't know, if I can make it easier, if I can work harder technically to get a better product, then I'm going to do that, and I'm not going to complain too much about it. Like, that's my job.

MIKE: And, unironically [chuckles], right? I agree with you. I was thinking of an example of, you know, go spend three months working on backend without requirements, without providing a single prototype. And yes, I've seen that kind of thing happen [chuckles] in the past. And it goes about as well as you'd imagine. The [chuckles] services you're building don't match what's actually required because you need to do...to your point, Will, again, unironically, that quick feedback is so critical that if you can't loop on it, it's terrible, which is a good reason to build out one small domain out of your project first so that you can have something that actually works.

WILL: Yeah, yeah, that is an important caveat. I would say that this is kind of frontend only. You can't show your VP of sales a slick API. I don't know who the VP of sales is, but I have a pretty clear idea of, like, that is some slick JSON, you know what I mean? [inaudible 28:00]

MIKE: [laughs]

WILL: But you can show people interfaces. And if you show people a frontend, you know, the backend exists to serve the frontend. Like, the backend is your problem. Get the dorks on it. Anyway.

DAVE: There's a web mockup tool that was designed...it's called Balsamiq. And I don't know if it's still like this. I haven't touched it in years. But when it first came out, it looked like napkin sketches. Like, on your computer screen, it would draw somebody with a ballpoint pen on a napkin, and they did it very deliberately.

And I have had this happen to me where you mockup a quick prototype, business looks at it, and they go, "That's great. Ship it." You're like, "No, this is literally a prototype. There's nothing wired behind this. This is 4% of the system." And they're like, "That looks like 90%. Ship it. You've got a week," and you're like, "No."

And so, Balsamiq literally shipped sketch stuff to stop that, to let the businesspeople understand that this is nowhere near complete. And it's related to what you were just saying, Will. I think knowing your trade-offs is super important. There's a time when you want to spike, and there's a time when you want to just knuckle down and trudge. And we've got good estimates, and we think we're right, and there's a lot of work to do. Let's sled along on this, or let's...versus jumping in ahead and working on the wrong things, but, spikes, sure. And they do happen frontend, backend.

I have literally spiked a mockup of an entire website, full-stack, database to frontend with just Rails, generate, generate, generate, generate, in a car on the way to an investor meeting, because my boss had said, "No, we're not switching to Rails. We're not switching to Rails". And, in the car, he's like, "How long would it take?" And I'm like, "Probably mock it up in the car." And he's like, "No, you can't." I'm like, "Bet." And I did. And so, we switched to Rails.

But that spike there was nothing shippable in that spike. I built it to throw away. It served its purpose, which was to say, "This is possible. This legacy codebase that we spent five years building, here's the prototype. And based on the prototype and our existing codebase, I'm thinking 18 months." So, I was able to give him a realistic estimate off of it. So, knowing where your trade-offs are, I think, and --

EDDY: If that doesn't tell you how powerful Rails is for a start-up company [laughs], I don't know what does [laughs].

DAVE: To be fair, this was Rails 3.0 when you could still write a blog in 15 minutes on it without having to know Stimulus and a front-end packer, and a pixel shipper, and the, you know, the asset poop line, and all that messy stuff, so...

MIKE: So, if I'm going to go...I'm going back into the snark.

DAVE: Yes.

MIKE: Advanced warning [chuckles]. One great way to make sure that a project gets done on time is to bring in as many teams as possible. But make sure they work independently and never coordinate with each other because you wouldn't want them to have any inefficiencies of communication. Also, let them design the interfaces independently, and then we can just fix that communication layer at the end because that's not the important part. The important part is that we all make sure that they're all working, and they're all heads down. We can handle any and many communication issues later. Make sure the APIs are in line. That's not a big problem, right?

DAVE: Yes.

EDDY: Well, if you want a way to speed up your service, just don't write tests.

DAVE: Oh yeah.

EDDY: Just ship your code.

DAVE: Fair point. Yeah. And there's a generic form of that, which is never check your work, right? Never cross-check. In fact, we should put that as part of the waterfall. Make sure coding is 100% done before you start debugging. That's literally part of the original SDLC when they were saying, "Stop doing this."

EDDY: Yeah, also, let your developers be the sole QA. That's good, too.

DAVE: Make sure your creators are editing at the same time that they're trying to create.

EDDY: 100%.

WILL: I mean, software QA exists. The entire career exists because I cannot be trusted.

MIKE: [laughs]

WILL: That's it. That's it. There's nothing a QA can do that I can't and don't. You cannot trust me. I cannot be relied upon. Like, I can't do it. You can't, like, jump. Oh, wait, wait. Hang on. No, no, hang on. I said that wrong.

DAVE: You got it backwards, yeah. How dare you be candid?

WILL: Bro, why do you even have a QA? Devs know how it works. Like, they understand it better than anybody. QA is just a waste of time. Like, you have an extra person? They don't even know how to code, bro. Like, What? Why even? It's a nonsensical position to have. Like, the devs could do it. They did it. Just shut your work, guys, duh.

DAVE: If they can't code, we could have them doing tech estimates for us, though. There's that option, so...

MIKE: [laughs]

EDDY: And you can have your product guys go ahead and help you commit a bunch of stuff. When you're short-staffed, you know, just rely on other departments.

DAVE: Yep. We talked a little bit earlier about Fred Brooks, about how many women and da da da da. Fred Brooks wrote a book called "The Mythical Man-Month" that's all about this. And Brooks' actual law that he quotes is, "Adding people to a late project makes it later."

EDDY: It's true.

DAVE: That's where it comes from, yeah.

WILL: And I'd say another note on QA. I'd say the best people to do the QA are the high-level executives when you're doing your demo, your final presentation, preferably even after it's already been out to production and you got your VP out there.

DAVE: [laughs]

WILL: They're pretty loose people. Like, they're not detail-oriented. They don't have real visions. And even if they did, they found something; it's not like you're going to look like an idiot when your VP of product is checking stuff in prod, and your links are broken. And, honestly, those guys, they don't even notice half the time. They're just like [inaudible 34:30], whatever. They're just so chill. They don't even care.

MIKE: They don't have any relationships outside of your business either, right? And they're too busy working with people in the company. They don't have the CEO of your partner's company on their speed dial because, yeah, they don't have time for that. There's no way anybody would ever, you know, important business partner would ever reach out to them at 3:00 in the morning wondering why the service is down. That's just not their job.

EDDY: You know, one way to really ramp up the way wave to meet the deadline is to just ship it, even if it's broken. You met the deadline. Just merge --

DAVE: Yeah. We can ship DLC later.

KYLE: I've got a controversial one, I think.

DAVE: Oh, please.

KYLE: DevOps is a culture, not a team. I've seen where, you know, that's on the developer. They can do their own DevOps and manage their own infrastructure. And --

DAVE: It's called DevOps for a reason, Kyle. We're the devs. We do the ops.

KYLE: Yeah. So, we don't need a specialized team for any of that.

DAVE: Yeah. And all you need to know as DevOps is just chmod A plus X minus R. Just go nuts, just 777 for the entire hard drive. Yeah, it's fine.

WILL: It's called CI/CD, bruh, continuous deployment. I'm just going to throw that thing up. New endpoint? I don't know. There's probably no scaling requirements. The server was fine before. I'll just throw this new API up there. Let's roll, YOLO.

DAVE: Ooh, related to this, Mike's going to wince a little bit, but don't do any tech debt. If your CI machine catches on fire, get some marshmallows. That's the best thing you can do for it, yeah. So... [laughs].

EDDY: Well, you don't have tech debt if you just delete [laughter] [inaudible 36:16] you've broken.

DAVE: Mike is covering his mouth. There may have been an incident at work this week, so...

EDDY: You can't have [inaudible 36:36] that's broken, Dave. You just delete the code.

DAVE: That's right.

EDDY: Just delete it. It's not broken no more.

DAVE: Yep. Actually, touching on what Kyle said about DevOps, if you really want to mess everybody up, divide your company horizontally. Make sure that the database team are in their own spot, servicing all the database clients, because then you've got all your experts in one place. And anybody that needs anything from the database team now has to go up through their boss and their boss, and then come down through the data management people, and they've got objectives that they need done. Same thing with your sysadmin, same things with your DevOps, same things, you know, if you've got anybody that's writing backend and frontend, get them on separate teams. Whatever you do, do not under any circumstances have a full cross-functional product team.

KYLE: I think another good one is launch your service or whatever deliverable you have before you consider security.

DAVE: Yeah. Yeah. Yeah, you can just bolt that on later, come on. There's no security. That mockup that I showed you that, you said, "Ship it," and gave me a week; we can just do security later. It's fine. 100%.

EDDY: Mockups don't have permissions. Dave, are you crazy? You don't need to scope permissions to your users. Just whatever --

DAVE: If you can see the mockup, you can access the thing, yeah.

MIKE: You'll never have a user who will try changing the URL to see, you know, another user's data. Our users are never clever like that.

DAVE: Ooh, slightly related to that, I'm not sure how to phrase this, but as you're developing, if you trip over something, don't flag that. Just step over it every single time. Definitely don't put rules in your engine. Don't write an RSpec thing to check to make sure that there's no implicit scopes or default scopes on your Rails models. And you want default scopes everywhere. You want to tenant your customers at the default scope. That's really, really important --

EDDY: Make sure you unscope, Dave. Like, that's –-

DAVE: And then, what you'll also do is you'll have your scope that says, "Valid," which is going to select for things that have not been deleted so that then when you say "Unscoped," we throw away the deleted at so that you can pull all the records, and we also throw away the tenanting. And now you're looking at every single customer in the system. I had that happen at a company where showing somebody else somebody else's data involved federal oversight. Like, you messed up. There was a department that you had to report to and say, "We did that."

EDDY: I was going to say, Dave, that's kind of oddly specific [laughs].

DAVE: And if you press me further, I will deny it, yep.

EDDY: [laughs] [inaudible 39:13]

DAVE: I've never worked with an entire company full of idiots. I self-select out of that environment. I've seen all of these design...most of us have, right? All these design hell problems, and they usually come about based on really good partial information.

EDDY: I was going to say, something that can really speed up is just always, always, always going against your framework's convention. Like, it works 100% of the time.

MIKE: Well, I can one-up you there. You want to get out quickly. You don't have to deal with the constraints of a framework. So, make sure you implement from scratch because, that way, you can...

DAVE: Roll your own.

MIKE: Yeah, roll your own. That way, you won't have to memorize the conventions. You won't have to deal with, like, libraries that will fight back against you when you're trying to do direct database manipulation. Just build everything yourself. It's a much faster way to work.

DAVE: This week, I am maintaining some code that has some custom snippets of SQL wrapped up in a custom DSL that are wrapped up in the source code. And it's just a joy to work with. It's absolutely fun. I have not ripped out any of my fingernails. I have not shaved my head defensively to save tufts of hair from being ripped out. It's, yeah, it's just been a dream, absolutely a dream. So...

EDDY: You know, another thing that's helped me, Dave, and I want to say, like, [inaudible 40:41] loading has been wonders. Like, you want me to ship something? Yeah, copy and paste someone else's work, you know, that's done before. It doesn't matter if it's being used in that context or not. Just [inaudible 40:53] is always --

DAVE: Yes, going back to the good intentions, end up in hellish places; drying things up to the point that they become chaffy is fantastic. You should compress everything and especially, you know, that SQL DSL that I'm working on, get into RSpec, and there's an include, not, like, include shared context. It's an include module, and the module was in the support directory. And I opened that up. And when you include the module, it creates a shared context and includes it. And the shared context creates lets. I have told that nightmare story here at work multiple times, thinking certainly that I would never see it. We saw it this week, so it's pleasant. It's kind of fun.

EDDY: Mine is a controversial one.

DAVE: I will say that I am sincerely saying that I'm enjoying working on this because I feel a little bit vindicated when I work on it. Also, in defense, because I did actually say something about a real company that is doing real work, and I don't want to get yelled at for this, I do want to point out that the developer who did it that way did it in 2015 when it was a best practice. I've written a lot of code that had shared context and riffling the deck to shuffle all the pieces so that they, like, laminates on an overhead projector with multiple layers to make them line up and that kind of thing.

It's very satisfying to dry that up in your text editor because you've got it all in your head, and you're like, oh, yes, why should I duplicate this? Let's put this over here. It's not until you come back later that you realize that you have just burned off every entry point for intuition and for someone else to be able to follow your path.

MIKE: I was thinking about a real-world story as well about avoiding the framework. I'm going to go back a lot farther, I think, like, 2003 [laughs]-ish.

DAVE: Ooh, okay. So, probably not Rails. It might have been Rails, but probably not Rails.

MIKE: Not Rails. I don't think Rails was out there. Anyway, this was actually some sort of Visual Basic. I don't remember the exact flavor of it. And there was no database library used whatsoever. It was all just raw rights to the database. And it only takes one unsanitized database input. It only takes one to lose a million dollars [laughs] of your customer's money.

EDDY: Yeah. Just don’t --

DAVE: What's the .NET... .NET has a SQL thing, like linker, SkLink. There's a name for it. But yeah...that would've been coming into existence about two years after 2003. So, yeah, if you're going to write SQL, it's going to be in the code. It's going to have to be in the code.

MIKE: This is back...I remember Hibernate was just getting started in the Java world and, like, wow, this is great. You can use some library and convention to write your SQL rather than hand-coding it all [laughs], but not so in the application that we took over [laughs].

DAVE: Oh, never switch. There's some people on this call that are going to feel seen and attacked at the same time, but this is actually not. But if you're going to add a new technology, add it. Don't change the existing stuff. You want people to have to maintain both. It's even better if they don't know which one they're working on until it's too late. That's a good one.

MIKE: As many text stacks as possible?

DAVE: Mm-hmm. Mm-hmm.

EDDY: Ship --

DAVE: For real, I used to walk into stand-ups...if I wanted to terrify everyone, I would give my stand-up report as, "So I did a quick spike, and I rewrote this in Rust." And, if you can sell that with a straight face, you can get, like, the blood to drain out of other people's...they're like, "You're doing what?"

MIKE: [laughs]

EDDY: Also, make sure you support multiple versions. I think that's --

DAVE: Oh.

MIKE: Simultaneous.

DAVE: Arbitrarily, arbitrarily. Don't just do it for the interface stability reasons. Do it arbitrarily.

MIKE: Well, if you don't have three versions of bootstrapping in your codebase, you're not a real project.

DAVE: What are you doing right? Yeah, and Angular 1 to Angular 2, they redesigned everything. So, you're going to need both, or you're going to be missing stuff out.

EDDY: It's a good thing that you can't support multiple versions of Ruby, though, like, satire aside, right? Like, you can only have one true Ruby version for the project. You can't support multiple. Is that correct? I see you smirk, Dave. Like, I wonder [chuckles], is that possible?

DAVE: It's absolutely possible. Like, Ruby 1.0 shipped with a library, dRuby? Distributed Ruby. And it made remote procedure calls very, very easy. You could write your program in two places. And if they knew how to find each other, you could call the function here, and execute it over here, and send it back, and nobody uses it. It was an interesting experiment, and nobody uses it. But 100%.

And, honestly, we do this here, where we've got service-oriented architecture. So, this team is on one version of Ruby, and this team is struggling because they've got this really important science library or finance library that isn't up on the latest. So, they have to stay back on an old version. Yeah, you do see that. So, what you have to do is you have to get out of the processor. You can't share memory with each other. I'm not going to say that super confidently. Somebody will say, "Here's a proof of concept."

MIKE: [inaudible 46:34]

DAVE: But, to my knowledge, if you're going to have multiple versions, they're going to have to drop to a protocol and communicate with each other like separate programs.

EDDY: Not ideal.

MIKE: We've come up with a lot of great ideas. I think that we could come up with an estimate that's pretty much whatever we want.

DAVE: We might be able to bring down the whole system.

[laughter]

EDDY: I was going to say something controversial, but some people may or may not agree, really just depends on your perspective. But I was going to say, as a satire, make sure you always do integration tests, and use factories to make sure you're testing the real data so that it gets committed to your database, but --

DAVE: And committed without any trade-offs.

EDDY: But I feel like some people do agree with that, and that's an interesting [laughs] topic.

DAVE: As long as you're ignoring your trade-offs so that you've got your test where you need to go really, really fast, as long as they're writing to disk and doing everything slow, and exercising the full-stack, and the stuff where you just need to test an accessor method that doesn't even talk to anything else that should be talking to the database, too, then, yeah, you'll be fine. You'll be fine.

MIKE: Well, you need to make sure that everything works, right? So, make sure --

EDDY: Make sure you test Ruby and Rails, too, like --

MIKE: Well, yeah, you can't trust the framework, and you definitely can't trust your third parties, so make sure that you make live API calls to their sandbox in your integration, you know, in your CI environment.

DAVE: Oh, yeah. If you come up with a workaround to a problem, solve it as far up the tech stack as possible. Like, I worked with an engineer who would recompile Ruby to add features to it, and we set him straight pretty quickly because [laughter] we're like, "We're not shipping your copy of Ruby to all of our servers. It's not happening. Stop asking." To be fair, he was a genius. He could shatter a human mind at 50 paces just by thinking about it, and he was very, very, very clever, and sometimes he was too clever for all of our good, so...

KYLE: I'd say –-

DAVE: I had a funny idea for how to end this podcast, which is to say, "Okay, now we estimated this much time," and then cut off right in the middle of the sentence, just no outro.

[chuckles]

EDDY: Kyle, you were going to say something?

DAVE: Sorry, yeah.

KYLE: I was just going to say, and don't worry about the performance of your code. We can always throw more hardware at it.

DAVE: Right [laughs].

EDDY: It's your computer that's slow, dude, [inaudible 49:11] [laughs].

KYLE: And we can ship that into the cloud if we need to.

DAVE: Yes.

EDDY: Develop to the cloud; it has unlimited resources.

DAVE: And I will see you in raise. You should care about maximizing performance at the start.

MIKE: Yes [laughs].

DAVE: You want to make the code as hard to read and as difficult to maintain as early as possible. And unrolling anything that's readable into something that's just hyper-efficient, go for it. That way, you're guaranteed to optimize things that aren't important. So, we will still need to scale up into the cloud to get around all the bottlenecks that we didn't even look at.

MIKE: And make sure that you do lots of planning around that optimization during the beginning of your waterfall process.

DAVE: Yes.

MIKE: Because that's what's going to matter the most is that optimization.

EDDY: I was going to say one thing, too. I was going to say, don't add comments and be super brilliant to what you're doing, so it's complicated for everyone else.

DAVE: Yes.

EDDY: So that you --

DAVE: Never ever pave a path through the code. You need to vanish into the jungle and be lost without a trace. Anybody who needs to follow you needs to solve it from first principles. That's important. It builds character.

EDDY: 100%. Like --

DAVE: And you need to prove your worth.

MIKE: So, if you don't have tricky code to read, well, then you're probably doing it wrong, right? I mean, how smart are you if everybody can read what you're writing?

DAVE: Yeah. We can go into a whole tangent about, like, your ego is more important than right and wrong, and that should be protected at any cost.

KYLE: I think one thing that goes really good on readability is the largest PRs as possible.

MIKE: Oh yeah.

DAVE: Definitely.

MIKE: You wouldn't want to waste time with QA having to review a bunch of small PRs. So, make sure you release the whole feature in one, that way, they can just test it once –-

KYLE: Save testing time.

EDDY: And test in production. That's the best way --

KYLE: Oh, that's the best one. Yeah, we can go to production first.

DAVE: Yes --

EDDY: Who better to tell you that your feature sucks than actual users, you know what I mean?

DAVE: I have a suggestion for a good final one, which is, if you're listening to this podcast and you think we're making fun of you, ignore it. It's fine. Don't take any lessons away from this. Remember to just stick by your guns, no matter what. Nobody has done any of these things in real. We're not talking about you; it's fine. Yeah, definitely don't take a hint from this to maybe try to improve steadily and stably. If you are going to react, make sure you overreact. I think that's the important takeaway here.

MIKE: We'll take the same advice because, of course, we've never run into any of these things ourselves.

DAVE: Mm-mm. Mm-mm. That's fantastic. Are we at a good stopping point, gentlemen?

EDDY: I think so.

DAVE: This has been a lot of fun. Thank you, guys, for coming out: Mike, Kyle, Eddy. Will had to drop off for a family issue. But so glad you guys came out. This was a lot of fun. And thank you all for listening and watching The Acima Developer Podcast. We'll see you again in a couple of weeks.