Why It's Always The Developers Fault

Episode 33

In this episode of the Stretch Goals podcast, Scott and I are going to be talking about why the developers are always the ones to blame.

Find us on Twitter @The_Scott_Davis or @RobDickersonJr

Transcript

Robert: In this episode of the Stretch Goals podcast, Scott and I are going to be talking about why the developers are always the ones to blame.

Scott: Always.

Robert: This is the Stretch Goals podcast where each week we’ll share insights and lessons learned based on our experiences as entrepreneurs. We’ll challenge you to create ambitious goals as you start and grow your business. I’m your host, Robert Dickerson.

Scott: I’m Scott Davis, and hey, we’re trying something new today. We’re actually doing a live video of our podcast so that we can put this on YouTube. So if you want to check us out on YouTube and see our faces behind these crazy conversations that we have, we’re going to be on there now so give us a look on the website. We’ll link it up on social media and you can find us on there.

Robert: Yeah, a little behind the scenes action of how we record, what we’re doing.

Scott: That’s right, and you can see me wearing a white V-neck T-shirt most episodes. Today I’m sorry to let you know-

Robert: You dressed up.

Scott: I did. Yeah, I did. Just for this.

Robert: You were fired up about this topic of why developers are always the ones to blame, so why don’t you start it off and tell us why you were so excited to do this topic today?

Scott: Well look. This is more than just developers are to blame, but it applies to any industry I think but more specifically developers are usually the ones that are the scapegoats for a lot of these problems that software projects have, or just projects in general. More specifically, I think a lot of times what happens is when product owners or even the upper echelon of a company, especially startups, don’t have their shit together, what happens is it all falls downhill and the developers are the easy ones to blame and point the finger when in fact it’s the rest of the company that might actually have some fault laid in their laps.

I’m not saying developers are perfect. They’re not. We’re people, right? But what it boils down to is that people are less accepting of developers making mistakes than others in the company, and a lot of times I think what needs to happen is that people who are at the top need to take a step back and go, “What can I do to help make what the developers are doing more clear or better?”

Then there’s a second thought to this. Let me ask you this question, Rob. Have you ever been at a company, working in a developer team maybe seven, eight people. Someone leaves, finds a new job. What happens? They become the scapegoat for every problem the next six months. Have you seen that?

Robert: Oh yeah, I’ve seen it.

Scott: You blame the person who’s no longer there because it’s easy, and that’s the same thing that’s going on up above. It’s the same problem which is, let’s put the blame on somebody else, and it’s usually a software developer because they’re the ones who are making the projects and missing deadlines and things like that and that’s what happens. And yeah I’m fired up about it because it happens all the time and it’s something that impacts us and what we do.

Robert: I’ve never met a developer that thought somebody else’s code was good or didn’t have problems.

Scott: That’s very true.

Robert: People always try to blame other people. Why don’t we talk a little bit first about some of the problems we see and why people are blamed, and then talk about what are some ways that people can go about fixing that?

Scott: Sure. Yeah, that’s great.

Robert: I think unrealistic schedule is one of the biggest things that I’ve seen when under development is that people have a set budget or a set time they want something done and they have a certain amount of features, and so everyone agrees and starts off but then there’s always feature creep, or people go on vacation or something comes up and they didn’t manage the schedule properly and so things fall behind, and so then it gets blamed on the developers for not completing their work in the right amount of time. Maybe there was some dependency there that if we’re working together, you need to complete something first before I can get started.

Scott: Yeah, blockers.

Robert: And so I start blaming you. Yeah, so there’s this blocker and there’s this blaming culture created because we’re arguing, and a lot of times these companies are built around small teams. Even some of the larger companies build around small teams so there’s not that many people that you can really hold accountable to get stuff done.

Scott: You’re definitely right. I think probably the biggest contributors, number one is scope creep and number two is not defining feature sets. You’ve seen it a million times. You’re working with a startup or you’re working with a customer and you agree maybe not to a statement of work, but you agree to some set of features that are going to be production ready by a certain date, and what happens is you get most of those features ready. They start testing it and then they come up with new ideas or new features which weren’t agreed to originally, and then you start adding those because you’re a developer and you want to help and you believe in the product, and then next thing you know you’ve missed a deadline. That happens a lot.

Then there’s other scenarios where your team just isn’t good enough and perhaps you just aren’t technically ready, but scope creep is huge and then not defining exactly what is needed, so a vague feature for example. Maybe I need to submit my location so others can see it. Okay, well that’s really open ended. Where is your location being sent to? Under what parameters is that location being obtained? Is it every second? Every time you move? Every hour? What format is it going to be in? All of those things have to be defined before a developer can begin working on it, because when the developer starts, if they’re spending their time figuring out those parameters, they’re not developing software and now you’re behind schedule.

Robert: Part of that, and maybe the majority of that, is a management issue.

Scott: Absolutely.

Robert: Because a job as a manager is to basically create those schedules and create realistic expectations and remove blockers from your team so that they can get the work done, and if you’re not managing properly then all these different things can happen and even as an entrepreneur, as a leader of your company, you’re going to be the one looked to to remove these blockers, to set the scope, to set the schedules, and so if you don’t provide consistent, clear communication to your development team of what you want them to do, if you’re changing your mind everyday, that’s going to cause scope creep. That’s going to cause them to fall behind on the features that they were trying to get done, so you really need to make sure you provide clear communication, clear goals, clear expectations, and then you get buy in from the team that you get their feedback whether this is a reasonable expectation or not that they can get it done.

That’s something that I always do when I work with other developers is I have in my mind how long I think it should take and I lay that out for them and I get their feedback as do they agree? Do they not agree? That can often be really enlightening because they’ll tell you, “What about this, this, and this?” Maybe things you didn’t think of that you could include in, and sometimes you can’t always include all that stuff in your schedule but then you can maybe cut back on the features some in order to fit it within the timeframe and the budget you’re looking at.

Scott: Sometimes scope creep isn’t necessarily the customer adding new features but maybe changing the way that the feature works. It may not be, “Oh, add five new buttons,” which is scope creep. It might be, “Can we change this to look a little bit different and change this font and update this color and move the drop shadow over here.” All those things, that’s additional work. That doesn’t come free. It requires time. All of those things add up is basically what I was getting to, but I like your approach.

It’s, “Hey guys, here’s my expectation of how long this is going to take. Do you agree?” But the problem is, and this happened. I have some real world experience with this recently is, not all people can deliver on those expectations. If they say, “Oh yeah, we’ll have this done today,” or, “We’ll have this done tomorrow,” and then you communicate to your contact, superior, whatever, that yes it’s going to be done today or tomorrow, and then they don’t deliver, now you’re left with your pants down. How do you deal with that scenario?

Robert: We’ve talked about this in a couple episodes actually is that you need to build in that buffer time. If someone tells you two weeks, you don’t say two weeks to a customer. You give yourself a month. And really, a lot of that comes from experience and just doing it and understanding how long the design process takes, because if a developer tells me two weeks, does that include testing?

Scott: Usually not.

Robert: Does that include launching it? No, it probably takes them two weeks to write the feature. It depends on how you’re writing your code. Are you building in the tests as you go? Are you getting feedback from customers as you go? Because you have to build in time to refine your design. We all have our internal ideas of things that we want to do but after you launch the feature or after you start using the feature you find things to tweak. You find feedback that you need to incorporate into the design. Those kind of things always have to be involved. With experience, I think you get better at this and probably the first couple times you’re going to crash and burn and you’re going to be late with features, but give yourself a buffer and try to use that to launch your features and your new products.

Scott: Sure, and one thing it’s hard to do too is if let’s say you’re the lead developer on a project, or an architect or something, and you’re spending your time in meetings or trying to communicate things to people within the organization, that’s time away from the code that you don’t necessarily account for. You assume that you’re going to work eight hours a day. I’ve seen these studies where it suggests that most developers might get in four to five hours of code a day for a typical eight hour workday. The assumption is that yeah, this is going to take me two days at eight hours a day. If you’re thinking that, that’s 16 hours. That’s probably four days of work when you break it down due to email distractions, meetings, communicating with the business owners and things like that.

Again, it all comes back to the developer. It’s easy for the developer to be the scapegoat, and I think really what needs to happen is maybe developers need to stand up a little bit and push back and say, “Look, you’ve not given me what I need to complete this job.” I think that will help, especially for freelancers. You see a lot of freelancers fall flat on their face and miss deadlines all the time, and that’s because generally speaking there’s a lot of scope creep and probably not enough time dedicated from the developer’s perspective. There’s the nature of freelancing, but I don’t know. What do you think?

Robert: I think the important thing is that you do that at the front end, not at the back end. Don’t wait til the last day to say, “Oh, I can’t get this done.” You need to be transparent at the beginning and as a manager you need to be receptive of that feedback so that if you adjust your schedule to take three weeks, you need to hold people accountable for that.

That’s another thing I see so often, especially in large companies. There’s no accountability for those deadlines of what people signed up for, and I think as a developer if you’re going to tell someone that you’re going to take so much time, you need to meet that expectation and get the work done in that period of time and if you don’t think you can you need to tell people upfront, and you also need to be transparent about it during the process. If things are going to take longer, let people know as soon as you can so the schedule can be adjusted. By giving people that accountability and that they’re understanding they meet those deadlines, you can create a better team to get things done.

Scott: One thing that is a bit frustrating though. Let’s say you’ve got a project perfectly laid out. You’ve got all the details you need. In my head I see a project visually. I know how I’m going to attack it, how I’m going to architect it. I almost see the code and the solution in my head, and if you start changing priorities and the orders at which things are supposed to be worked on based on your subjective opinion, that affects my architecture and how I’m going to develop something. I don’t know if that’s the case with all developers but it definitely is for me so when you start switching things around in terms of priorities and, “Oh we really need this feature done first.” Well what if that feature has necessities that are upstream, prerequisite? There’s a little bit of that too that I think product owners need to maybe understand is that when you shift priorities you need to communicate downstream to your developers and make sure that there are no large impacts to what they’re doing.

Robert: Communication is the single biggest flaw I see in every company, and it goes not only to developers but management, from executives. It’s everywhere. It’s the thing that you need to improve most within your company, and it’s just so critical that you communicate your expectations and that people communicate what they’re working on. There’s a million tools out there for doing this but still we struggle with communicating with one another to figure some of these things out. That has got to be the number one priority, especially if you’re leading a company that you open the lines of communication and that you are crystal clear about what you want people to do. A lot of times I find that you need to do that in writing. You need to write down what you want people to do, because if you and I sit here and talk about something, you’re going to take something different away than what I told you so you need to get it down in writing, and that’s a way that we can both agree on something.

Scott: Even still though things change and it’s hard. That’s a one way street though a lot of times. You hold a developer to a deadline, but there’s usually no protection to the developer for scope creep and things like that, so as a developer or as a freelancer or whatever or company, you need to protect yourself from that. Put it in your contracts. This is based on these features definitively. Any change to these features results in additional time and blah blah blah blah blah.

Robert: That’s why I don’t like fixed price contracts, because if I’m charging you by the hour and you change your mind and want to do this other feature, fine. We’ll do it. It’s just going to cost more money and time. If you can get away with that then it’s usually better off in the long term.

Scott: The other piece of it that I mentioned was a developer leaves and the developer immediately becomes the target of attack from other developers on the team. They become the scapegoat for the problems for the next three to six months. They’re the easy excuse for why things can’t be done or why things need to be refactored. That happens all the time.

Robert: It’s just hard with a small team because everyone has their specific area that they’re working on that they’re building, and there’s not a lot of overlap in small teams. As you’re starting your company, you’re going to have just enough funding to get each of these individual people to do their own piece of the puzzle and so you can’t have two people working on it and sharing the responsibility. So when one person leaves out of that team, that’s a huge chunk taken away from what people were working on, and so to blame them … There’s got to be agreement on the solution and what that person’s doing.

If someone leaves, there shouldn’t just be this big thing of, “What was that person working on? I never looked at their code.” There’s got to be that collaborative approach. You got to build it in. In my corporate jobs I was trying to get people to do reviews all the time so that people could have discussions over what they were doing and we weren’t just working in these silos alone so that if someone left or if you have to go work on their code, the other people would know how to build a product and what they were working on.

Scott: I think too it puts it back in the developer’s lap if you have code reviews and things like that. If a developer’s like, “Well, Steve left and he didn’t write this that well,” well guess what. Didn’t you review his code? Didn’t you say everything was cool? Okay, well guess what. You got to deal with it.

I just think it’s funny. I’ve seen this my whole life. A developer leaves the team and it basically becomes a bunch of piranha attacking that developer in their absence. If they had a little ghost over there in their chair they’d be mauled to pieces. It’s the reality. That’s just what happens, and it’s kind of upsetting because most likely you’ve worked with them and you’ve not said anything about their code to them. You’re just like, “Hey, good job on that feature.” But then when they leave you’re like, “Jerk, you had horrible code.”

Developers don’t make it any better. Like you said, most developers are elitists, which is, “My code is the greatest code that was ever written by anyone at any time and it always will be.” And the reality is, most of us probably don’t really write the most beautiful code. We write the way that we think will resolve the problem. But it’s always frustrated me about that in the tech space is that developers turn on each other very quickly, and it happens-

Robert: Developers like to think from the ground up. They want to develop the solution themselves. That’s part of the fun of it is creating something from scratch. I’m very similar to you as I can see solutions in my head and I know how I want to work them, and when you already have somebody else that wrote some code, now you got to go around that. You got to integrate with that so your solution isn’t as clean in your head as you wanted it to be, so that can frustrate people because you have constraints that now you have to work within. That’s why we see all these different libraries and people trying to reinvent the same thing over and over again to make it better, because they want to start from scratch. They want to build it up.

Scott: Code’s always evolving. It’s always changing and it always will. It kind of has to. Technologies change. Platforms change. All that good stuff, and then things get deprecated and things get updated, and now you’ve got new features and things that make more efficient, so yeah it’s always evolving and every time you almost have to look at your algorithms and restructure them completely. I think developers need to be a little bit less elitist and more collaborative and you’ll get a better experience. But my biggest frustration though really is, I’ve seen it a lot over my career and it’s very easy to blame a developer, and then sometimes there’s unforeseen items that impact those timelines. Difficulties or architecture changes that maybe increase the estimated time to complete things, but you’re absolutely right. It comes back down to communication and that’s something we can all do better at.

Robert: Why don’t we talk for a couple minutes about how do you fix those things? I think we’ve talked about a couple of the issues. One is communication, so maybe try to refine the processes that you use to communicate with your teams. That doesn’t necessarily mean have more meetings. It can mean maybe having a daily standup or a weekly standup or something to talk through issues, talk through problems, but figure out how you can communicate in writing, what works best with your team. There’s different tools. Different teams work different ways so figure out what the best form of communication is and also how you can solicit feedback from your team to make sure that those expectations that you’ve set are reasonable and that people can be held accountable for what they’re buying into when they become part of your team.

Scott: For sure. I agree.

Robert: The other things that I noted here was along with communication is don’t throw stuff over the wall. I see this a lot of times too where people will come up with something and they’ll, especially if they’re not familiar with the development process, they’ll come up with an idea or a concept and they’ll throw it to their development team and the development team will say, “Okay, we’ll have this done in a month.” And so there’s no communication for a month and the person expects it to be done. They just threw it over the wall. That never works. You need to be involved, even if you’re not a developer yourself. If you’re running an organization you need to be involved and really get feedback on a daily basis of what’s going on to make sure that you can direct people and direct the flow of what they’re trying to do.

Scott: Right. Yeah, I agree with that.

Robert: Other things. I talked a little bit about laying expectations, when you were talking about communications. That’s definitely a big one. Getting involved in all the steps. I guess the final thing is, we talked about building in the buffers into your schedule and that really comes with experience. The more you do this, the more you work at it, the better you’ll get and you’ll understand the variables that are at play. As you get to know your team better as well you’ll get better at it-

Scott: There’s a-

Robert: And maybe start … Go ahead.

Scott: Sorry. There’s a fundamental flaw in that though, especially if you work in the startup space, and that’s, you never have enough time and they want it fast, fast, fast. And so if you say, “This is going to take three weeks,” they’re going to say, “No. You’ve got 7 days.” Okay, well … So it doesn’t necessarily work, and that’s a cyclical and very degenerative problem in the startup space is that you’ve got to get things done quickly. A lot of times you have to cut corners to do that. What ends up happening is that creates bugs, that creates problems, that creates scalability issues, which is why companies like Snapchat then have to raise $200 million to scale the product because they wrote it poorly in the first place. You see that’s an open ended door. It happens all the time, but by not allowing developers to take enough time to build a product you create problems for yourself down the line, and a lot of founders, “Yeah, yeah, yeah. No, we just need the feature. Give me the feature as quickly as possible.” But you don’t realize you have to think about the bigger picture.

Robert: I think you need to not be afraid to push back sometimes too, and I think with experience you understand the limitations. Maybe you understand the underlying problem that they’re trying to solve. They’re trying to work all these features to solve this problem. Well how do we actually solve that problem? Do we really need all these different components? Maybe we can do just two of these instead of 10 of these to get to that solution that you really want to solve, whether it’s I want to make my onboarding process better, or I need this key feature for a customer. You need to really try to identify what the underlying problem is and push back and make sure that you’re not building a bunch of things that you don’t really need to solve that problem.

Scott: Absolutely, and like you said, that comes with experience but it also comes with communication. You have to be able to communicate like, “Hey look, I understand what you want but what I’m telling you is that here’s the downsides to going with that approach. Do you agree with those risks? Okay. All right. I’ve warned you.” That’s the thing, and really what it boils down to is like I said is that oftentimes developers can be the easy target when things aren’t achieved because they’re the ones creating the products, but sometimes there are things that aren’t controllable by anybody in the team that can cause those delays, but then other times it’s directly a result of communication from upstream and also feature and scope creep.

Robert: I agree.

Scott: Cool.

Robert: Let us know, have you been the blamed developer? What was the reason? Hit us up on Twitter and let us know. We’d love to hear it.

Scott: Give us a shout on SoundCloud and iTunes and let us know what you want to hear about next.

Robert: And come check us out on YouTube. Check out this video and see what you think.

>

Scott: See you.

Robert: See you next week.

Subscribe For New Episodes

Each week we'll share insights and lessons learned to help you create ambitious goals for your business.

Robert Dickerson

@RobDickersonJr

Robert Dickerson is the Founder and CEO of Mapout a mobile learning platform that uses video courses to educate customers and train employees. He helps companies develop and launch their products.

Scott Davis

@The_Scott_Davis

Scott Davis is the Founder and CEO of MobX, a mobile development software agency. He has 20 years of experience developing software for Government, Finance, Sports and the Telecommunications industry.