56: Mitigating Risk in App Development

Murphy's law of "Anything that can go wrong will go wrong” doesn’t exclude software development (unfortunately). There’s many risks associated with any development project, from communication breakdowns to changes in scope and timeline to a developer moving on. But there's also many ways to mitigate these risks when you start working with a tech team. In this episode, Tim outlines common risks associated with app development and how to get on the same page as your development team to have systems in place to mitigate them.

In this episode, you will learn:

• How to prepare for developers moving on
• How to mitigate risk should the tech agency you’re working with go out of business
• How to set clear expectations around communication
• Why modern best practices with software development handle a lot of the risks associated with deliverables
• How to prepare for app store rejections
• The biggest hurdles affecting the timeline of development projects
• How to address changes to scope
• What empathy has to do with estimating software development

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded November 20, 2020 | Edited by Jordan Daoust | Produced by Jenny Karkowski

Show Notes:

The Mythical Man-Month

Murphy’s Law

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at all things technical. I'm Tim Bornholdt. Let's get nerdy.

Today, we are going to talk about ways you can mitigate risk when you start working with a tech team. There are a lot of risks associated with any development project. And while this episode isn't meant to invoke any specific anxieties or fears, there's a fair warning that there's a good chance something is going to go wrong during your project. An advisor once told me that the beginning of a project is the best time to plan for all the bad things that could happen at the end of the project. Because at the beginning of the project, you can think things through while you're on good terms, as opposed to trying to figure it out while you're in the thick of it. So when you're working with a tech team, it's good to know the strategies they have in place for handling those sort of risky events before you even start working together.

So let's go through a few risks that we have encountered here at JMG and kind of explain how we think through mitigating those risks, starting with developers moving on. This is life. The other day, I was at this conference. Well this wasn't the other day. This was a year ago, because we're in COVID right now. Last year, I went to this event where they were talking about what are the odds that you will at some point get rid of your business? And the answer was 100%. Because at some point, everyone dies, right? Everyone leaves on, everything moves on, nothing is permanent, nothing is forever. And developers are no different. People are going to get new jobs, people are going to move, people are going to be uninterested in developing anymore. The way that you mitigate those risks are, first and foremost, whoever is working on the project in the first place, that developer should be documenting and commenting on their code so that everyone understands what's going on. And they should also be committing their code to a central code repository while they're working on it. That way, if a developer leaves, then we can bring in another developer, and they can pick up pretty quickly and move on from there. And if all of our developers are busy, you know, we also, because we're an agency, and we're friends with all the other agencies in town, we have a pretty good network of people that we can turn to in a pinch and get a feature done quick while we continue to find a different person to take over that code base. Those are the things you should be thinking about when you're thinking about developers moving on to the next part of their career.

Another risk would be the company that you're working with going out of business. You know, it's hard for you to mitigate this risk sometimes, because things happen. Again, every company ends, and especially in a time like now, when there's so much uncertainty in the air, companies are going in and out of business all the time. So it's important when you start a project to understand at least their near term position. Are they sitting good with cash? Do they have a good amount of projects that they're working on? Are they hiring developers right now? Have they laid off a bunch of people recently? Try to understand where they are right now. Is this like landing their project, if they land you as a customer, is that going to completely change their world around? Is it going to be just another cog in the wheel? These are different things to kind of keep in mind with this.

At the end of the day, the important thing, too, is to understand who owns the code? Because some development shops own a lot of the code that you're working on. And if they go out of business, what happens to the code at that point? Do you get to still use it? Or does it go to whoever buys the next company, or whoever takes over for where the other company left off?

Another risk is a breakdown in communication and of the risks we've talked about so far and that we will continue to talk about here, I would say, based on my nine years of professional software development, this is the highest likelihood of occurring. It happens all the time, especially when you talk about projects that are the size of six figure, seven figure projects versus a four figure or five figure project. Sometimes those smaller projects get put on the backburner. And we've been guilty of that too, with our own shop. So the way that we've found to mitigate that over the years is to establish a consistent schedule by which us as the development shop and you as the client would chat and share progress. And it goes both ways, because it's good for us to know that you're actually working on things too on your end. But once you have that kind of every week, you know you have to have this conversation, you know you need to be chatting and give a progress update, that gives you a good incentive to actually get some work done. So any project that we've had that we did not establish at least a weekly discussion, sometimes daily, it gets to that point when you're really in the thick of it, but at least weekly. If you're not doing that, then things just kind of fall to the wayside. Even like monthly is not enough of a interaction. It's really got to be at the very most biweekly, but I would say weekly is the schedule that we've found.

Another important thing with communication is setting clear expectations at the beginning for when you're available to chat. A lot of times, because we're in a technical space, and we're in kind of the digital world all the time anyway, it's not uncommon for someone to shoot an email at nine o'clock at night when they're thinking of something. I mean, I'm guilty of this too, in my own Slack team. I find articles that I find interesting, and I post them at 11 o'clock at night, because I'm just up thinking about it. You have to kind of set that expectation with your team of when is it appropriate for you to communicate with me. We've had projects where our clients have reached out to us multiple, multiple times at like eight o'clock on a Friday night, when there's no expectation of that, right? Like, we need to have our time off just like you do. We need to recharge our batteries, so we can come back and hit the code hard. So setting clear expectations up front for you can communicate with me by email, you can communicate with me by Slack, and I will respond within these hours during these days. That's really the expectation, just being clear and upfront about that, everyone will be on the same page and really appreciate that.

Another risk inherent with communication is there's oftentimes we find we can't get in touch with you, which you think is weird, because you're paying us as developers a lot of money to get this stuff done. So you would think that it would be important to be in good communication. But sometimes we've found some clients, you know, the app isn't necessarily their only thing they're working on, so they get busy. But if there's certain times where we're not able to get in touch with you for an extended period, then that's going to delay the project, that's going to be a big risk. So we basically to mitigate that we just consistently reach out to you to make sure that we're just constantly following up, staying at the top of your inbox, on the top of your mind so that when you are able to respond to us, you can get to us as quickly as you possibly can.

Another risk in app development is the deliverable. So typically, the deliverable here would be the code. And really with modern best practices and software development, it really handles a lot of the risks associated with deliverables. Because back in the day in the 70s, and 80s, when people were developing with punch cards, for example, it's like, if you got one punch card out of order, your whole project was screwed, right? These days, you can pretty much commit your code into a central code repository, like we talked about before, and it's there. It's not gonna go anywhere, and you can make backups of it. So really, there isn't a whole lot of risks associated with the actual code. It's more in different areas related to the code. So I would say that the biggest risk in a deliverable would be underlying platforms that support the app going out of business or changing their terms.

For example, back in the day, there was a platform called Parse where everybody built their back ends to point to this Parse platform. And it was like, in 2011, 2012, that era, it was like kind of the big, big thing that developers used. Well, Facebook bought Parse, and it was supposed to be this big, you know, everyone's cheering and saying, Hurrah, yay, Facebook owns it now. But then like, six months later, they turned around and said, We're gonna shut down Parse. Which meant everyone that had a back end associated with Parse was completely hosed and had to find a whole new back end to their system. So those are kind of the risks with the deliverables that we kind of worry about. And the mitigation strategy is just like if anything happens in any project, it's basically alert you of the change, come up with a strategy to work around it, and execute the change. And part of the coming up with a strategy of working around it is adjusting the timeline, because we didn't bake in that the entire back end was going to go away, right? So you need to kind of work with us to figure out how we can adjust the timeline. It's not anybody's fault in particular, it's just, again, these are all risks that can and have happened. So it's good to just think through what might happen going forward.

Another common risk in app development, and particularly in the mobile app development space, is getting rejected by Apple or Google when you submit to the App Store or the Play Store. The best way to mitigate this risk is, first of all, understand the rules up front as best you can. They are a little opaque. There's a little bit of murkiness and interpretation in some of the rules. I mean, there's even rules about push notifications that you're not allowed to use them for promotional reasons. But I mean, every app sends out promotional push notifications, right? So if you think you can do it, and then all of a sudden Apple cracks down, that's an issue. So the best thing you can do is really understand those rules up front. Don't try to circumvent them on purpose or create an app that's clearly out of bounds. You're going to get rejected and waste all your money. And there's nothing that we as developers can really do about that.

When a rejection does take place, and again, they do and they happen for all kinds of reasons. We've been rejected for all kinds of just crazy things that we didn't even consider in our own QA. But you know, it's kind of nice having sometimes Apple reject apps, because it gives you a reason to think about things that you might not have considered to this point. So when a rejection takes place, what we do is we try to understand the rejection and really the reason behind it. If we can find a way to diplomatically work it out, then we do do that. And App Review has gotten a lot more diplomatic over the last couple of years that it's easy for us to just say, Hey, yes, we recognize that there's this issue, and we will fix it on the next release. But can you push it through now, because we have a ton of bug fixes that need to get through. And lately, especially because of how much hot water Apple has been in, they've been much more open to accepting that. So the first thing is to just try to work it out diplomatically. But if they are sticking to their guns and say, No, you have to fix this problem and add this thing in or change this, then we work with you to put up an estimate of how many hours we think it's going to take to make that change, and then just negotiate with you to get it fixed. And that's really all you can do. That's a part of the name of the game when you're living in the world of the App Store.

Another big risk in app development is timeline issues. So the biggest things that could impact the timeline are breakdown in communication, like we had already talked about before, and also changes to the scope, which we'll cover in a little bit. But one thing that I wanted to touch on with the timeline specifically is, when there is a breakdown in communication, and there's bad news regarding the timeline, the thing that I've found is humans have this like inclination to not want to deliver bad news and try to find a way to get around it. And maybe it's not humans, maybe it's Minnesotans. That's why I really respect my East Coast peers is because they are not afraid to just rip the band aid off, dive right in and actually solve the issue. And I think that's something I've been getting better at as I've been running this company is, it doesn't help anyone to try to delay giving out bad news, just get it on the table. It's gonna stink, people are going to react the way they react. It's your job as a professional to help find a solution to this problem. So the faster you can get the bad news on the table, the faster all the feelings can get out. And then you can actually get down to business in solving the timeline issue.

Like we just talked about with timeline issues, the next thing we'll talk about here are changes to the scope. So this is a risk that happens in every project as well, right? And that's why there have been so many things that have been done to help alleviate this specific risk over the years, the most prolific response to this issue has been the whole agile methodology of breaking down projects into two week chunks of time and trying to figure out how you can just make two weeks of progress, evaluate where you're at, make another two weeks of progress, evaluate where you're at, instead of the classical waterfall approach, where you kind of figure out everything in a project that has to happen upfront, and then just start checking things off the list. If you have everything laid out up front, you are going to see that things will change. By the time you get from beginning to end, things are going to change in your project. It's just, that's the way software is. Even if everything about your app is the same, iOS might drop something completely random on you, or the next version of Android might have something way out of left field that you never even considered that you have to address. And that's just part of the business. That's part of what we do here.

So how do you mitigate changes to the scope? Knowing that we're not going to mitigate that risk, it's how do we address that risk? Well, first of all, we want to be clear about what the additional work is going to cause. Are we talking about an hour of work, like changing a word or changing something smaller? Are we talking about 100 hours of work where we need to adjust things on the back end and on Android and on iOS and the web? You can see how sometimes changes to the scope can be huge or small. And so it's good to get on the same page with your development team to understand how that's going to impact it.

And the one thing that you should keep in mind as an app owner is that as technologists, we're happy to build anything you want. That's kind of the cool thing about our job, the world's our oyster. Just understand that it takes time and that there aren't really a whole lot of things you can do to speed things up. There's a very common trope in software development called the mythical man month, where you can't take nine women and make a baby in a month, right? You just can't. It takes one woman nine months, that's the way it is. And that's the same way it happens in technology. There's just some things just take time. And especially as you're adjusting the scope, you have to be cognizant of that so that you're not expecting the world out of developers when all we can deliver is consistent code in inconsistent intervals.

And finally, our last risk to app development is changes to the budget. Yes, this happens sometimes, right? You need to understand upfront how you're going to be billing for a project. Because sometimes projects are fixed bid, sometimes they're time and materials, sometimes they're on a retainer basis. The budgets can change and just like how software changes, budgets change. Things need to be fluid. Now, as a technologist, I understand I don't want to tell you it's going to cost you, say, $100,000, and it comes back at a million. Like that's not fair to you. And it doesn't make a whole lot of sense, like that would be wildly inappropriate. But it's good to understand when you're adding features, when timelines change, when all these things adjust, a lot of times people forget that the budget needs to adjust as well to impact all of these things. So that's one thing that you're going to have to work through with your development team is figuring out how you mitigate that specific risk.

One thing that I will point out is that estimating software build outs is really hard. So try to keep an empathetic ear, just as from my end, I'm trying to be empathetic to what your actual final budget is. Sometimes, if you want it to fit into a certain budget, be empathetic to taking features out in this part of it and putting them back in once you've been able to build up more budget and get some more revenue from the app. Upfront estimating software, we might have a really good idea of what it's going to take. But there are so many variables that can cause projects to really spiral out of control. And it's important to meet up with your developers and find a way to meet halfway when those things start to spiral so that you're not spending a ton of money that you didn't think you were going to need to spend. And we're also making sure we're getting compensated for the time we're putting into actually fixing whatever those problems are.

Some final thoughts. It's really impossible to mitigate all risks, right? But that's kind of the big thing of working with an experienced team. A lot of times people try to find cheap ways of building out apps. And this is the stuff that they don't see coming is all these risks that we've dealt with. And that's why we charge what we charge for building out apps is because we've mitigated these risks in the past, we have systems in place on our side to be able to control a lot of those issues that we've already discussed in here, and that's really why you're paying what you're paying. If you find a cheaper team than somebody that's doing it for half the price, they might not have these in place. So you might end up spending as much, if not more, when they drop the ball or can't deliver on a certain code or something happens. We have those processes in place so that you're ultimately spending less money by working with a team that can help you mitigate these risks up front.

That's all we have for today's episode. Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by the benignant Jordan Daoust.

If you have one minute quick before you leave, we would really love it if you left us a review on the Apple Podcast app. You hear this all the time. I talk about it all the time. It really does help and we don't really get a whole lot of reviews. So yes, you listening to this right now, take a minute, go to constantvariables.co/review. We pop up the link right on your phone. All you have to do is fill out a quick one minute thing about how much you love us. And that's seriously helps a lot. So please, again, that link is constantvariables.co/review and we would seriously appreciate it if you would take the time to do that.

This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development and mitigate risk, give us a shout at JMG.mn.