NOEL: Hello and welcome to Episode 70 of the Tech Done Right podcast, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin.

We're running a brief listener engagement survey. Unlike most of these surveys, this has nothing to do with advertising. We're just trying to see what kind of shows and guests you like so that we can do more of them. Fill out the survey at bit.ly/TechDoneRightSurvey, all one word. And if you'd like, we'll send you some Tech Done Right stickers and you'll have a chance to win one of the Table XI Inclusion Meeting Cards. Thanks. That's bit.ly/TechDoneRightSurvey, all one word.

If you like Tech Done Right, keep an eye out for our new podcast, Meetings Done Right. Meetings Done Right is 12 episodes of communication and culture experts all focused on how to improve your meetings using the new Table XI Inclusion Meeting Deck and other tips and techniques from our experts. For more information about the podcast and to learn how to buy a Meeting Deck of your own, go to MeetingsDoneRight.co or search for Meetings Done Right wherever you listen to podcasts.

Today on the show, we have Ashley Quinto Powell. Ashley and I have run a workshop together called How to Buy Software aimed at people who want to buy custom software but aren't sure what the process will be like. In this episode, we try to compress a four-hour workshop into a 45-minute podcast. Ashley will talk about what to expect from the sales process and then Ashley will interview me about what it's like to work with a development team. I hope you like it. And now, here's the show.

Ashley, would you like to introduce yourself to everybody?

ASHLEY: Sure. I'm Ashley Quinto Powell. I'm the Director of Business Development for Table XI.

NOEL: Today, we are going to talk about how to buy software. We're going to talk about what you need to do first of all, as somebody who wants to purchase custom software, how you go about that and what to look for. And then we're going to switch things around, and Ashley's going to, I think, interview me about what to look for in a development team. I'm very excited.

ASHLEY: Yeah.

NOEL: So Ashley, how do you buy software?

ASHLEY: That's a great question.

NOEL: I guess that's the key question.

ASHLEY: Yeah, it is the key question. I have been involved in technical consulting sales since about 2008 and I've helped lots and lots of companies go from "I have an idea, I think we need to build something" to having a thing built. And there are so many questions that people have, really it's a nerve-racking, expensive experience. And so, Noel, one of the things that you and I worked on first was coming up with a how to buy software development to educate buyers on what to look for and what to be wary of, how to go about doing it, so that people really felt comfortable and empowered in that space.

NOEL: What are some of the questions that people have or what are some of the common misconceptions people have when they go off? So let's say I am a person, I think I have an idea for my business that requires me get some custom software built, or it might. What are some of the misconceptions I probably have as I start this process?

ASHLEY: The biggest misconception that people have is around the budget. People are very, very afraid to share what their budget is. There are a lot of fears around, "If I tell you what my budget is, that's what the software project is going to cost." And that is not exactly true. Often when I ask about budget, I want to understand what level of application we can build for you. And there are interesting things we can do at a lot of budgets. On a lower budget, maybe that looks like putting together existing software and making some buy versus build decisions because often buying pieces of software is much cheaper than building a whole new custom application. Then on the other side, if you have a big budget, one of the things that you can do is validate that users will like it, that it's intuitive, that it really has a positive ROI before you actually start to spend money on software builds. There's lots of things that you can do, starting with what's your budget is a great way for somebody like me to asses, "Okay, either I should direct you to someone who can help you accomplish what you need to accomplish or at least get close for your budget or maybe that's something we can help with."

NOEL: What are some of the things people should understand or questions they should have answers to about the thing that they want to build before they start? And what are things that they can expect a software partner to help them answer?

ASHLEY: Well, one of the things that I think people underestimate is how important the quality of code is. When I say that we develop outstanding code, what I mean is that it will be easier to maintain, easier to update. It will stand the test of time a little bit better. I think part of it is that apps often look so much more simple than they really are to someone who doesn't understand what's underneath the hood. And so we have this idea that you can spin up a simple looking app for no time and no effort not realizing the facets of design and the backend that really go into it and make it work.

NOEL: So when I come in to meet with somebody who I might be buying software from, like what should I have prepared, what should I have ready to go and what questions should I be ready to ask?

ASHLEY: I think having prepared an idea of what the problem is that you're trying to solve. With somebody like Table XI, that's really what we want to know. There are some firms that really need you to come in with, "Hey, this is what exactly what I want built, here's what it will look like. Here are the mockups, here's the user flow." We actually want you to come in with, "Oh, we're happy to take a look at all of that." But we really are interested in what problem are you trying to solve. And let's figure out the most efficient way to get you there. We have occasionally had clients come in saying, "You know, I definitely want a mobile app. I know that it's a mobile app, it's going to be nothing but a mobile app." And mobile apps can be very expensive to create. If we can solve the same problem with a solution that has less custom development, that'll be much more efficient and much cheaper than creating something from scratch. So some of the work that we do is understanding really what the problem is and what is the most efficient way to solve it. It might be a mobile app, it might be a chatbot, it might be something analog and not digital at all. A design team will be able to tell you that before you go into software development.

NOEL: So when you start interacting with a software team, even during the sales process, they're probably going to start throwing around terms that you may not know. What are some of the most important kinds of terminology or what are things that a software development firm is going to say that you need to be able to understand in order to make a good decision about what they're actually telling you they can do?

ASHLEY: You might understand the agile versus waterfall methodology because I think that that really sets apart a firm. You should have a sense of whether you're comfortable with something being offshore or nearshored for instance. And I'm not the sort of person who dismisses offshore and nearshore out of hand. I think that there are some times when that works, if you have the frontend and the backend designs really well laid out, that can be a good solution.

NOEL: So I'm just going to ask you to define the terms... offshore, nearshore being where the development is actually sourced, where the development actually happens, right?

ASHLEY: Offshore and nearshore refer to where the developers are actually working. Nearshore often refers to someone like in your time zone but not in the United States. And offshore is usually in Asia or East Asia. Some of that development can be a lot less expensive than custom application development in the United States. There are certainly advantages to one or the other. I've always worked for onshore development firms in the United States where all of the developers or nearly all of the developers are in the United States. Some of the advantages to that are it's outstanding clean code. People work in your time zone, they understand what you're talking about. There's some freedom for our developers to be creative to say, "Hey, that that doesn't make much sense from a development perspective. Maybe if you rethink it like this, that's a more efficient way to do it." So you get some of that back and forth. But there are lots of ways to do it. And so having a sense of if you're going to prioritize cost above all else, making sure that when you do take some of those, the offshore and the nearshore options, that you have design in particular figured out and can give someone a really good path to creating an application.

NOEL: Yeah. Because one of the side effects of that model is that, although the cost of the development is lower, the cost of the communication, at least the time cost can be much greater because if you're out of sync in time zones, then there's a much longer time back and forth for communication to happen often.

ASHLEY: Absolutely. And also, I can't stress how important the creativity is too, developers working collaboratively with you who are in the United States often feel very, very comfortable culturally telling a client, "Listen, you're the client, we'll do whatever you want, but this is what I recommend. And I think that this is a more efficient. And by that, I mean time and money efficient way to do it. So maybe we should consider just tweaking that expectation a little bit or tweaking that functionality a little bit." And that I think can be really, really helpful. Particularly when you're spinning something up that is, I mean, aren't they all critical to your business?

NOEL: Yeah. If it's not important to your business, I guess you shouldn't be doing it.

ASHLEY: [Chuckles]

NOEL: Do you want to talk a little bit about agile versus waterfall? Or at least in terms of like what to expect about what those might imply in terms of the way in which you'll interact with the software team?

ASHLEY: Sure, one of the greatest advantages to agile, which is what many, many software development teams ascribe to.

NOEL: Yeah. I would say if you're looking at like small web development shops, it's going to be really common.

ASHLEY: Yeah. One of the reasons is because it allows a client in particular to change their mind really quickly. I have yet to see a project that doesn't have some pivot in the middle, small or large, especially in the startup world where you're getting advice and feedback and have advisors and investors who want to see something slightly different as you're building. I've seen all of that up to and including a founder in the shower, getting a great idea and wanting to pivot that afternoon. And agile really allows you to pivot quickly and to have a really collaborative experience with your developers because typically, and many development shops will develop with agile, with a lowercase a for instance where they'll adopt some of the agile methodology and not keep it super, super strict.

NOEL: Right. So there's a distinction here because there's actually a formal methodology called Agile and then there is a like more informal set of practices that tend to be referred to as agile. That in the main tend to prioritize small scale decision making, not doing a whole lot of upfront planning and being able to respond to change over time.

ASHLEY: And constant communication.

NOEL: Yeah.

ASHLEY: So scheduling times to meet with your client and the team, scheduling times to look back at the last two weeks and say, "Okay, how'd that go?" Those are really good opportunities to sort of check in with the development. One of the things that is scary about software development is upfront, you need to make a decision about whether you're comfortable on a time and materials contract or a fixed bid contract. And that probably is like the biggest factor. I think people sometimes will consider them side by side, but that tends to be a mistake because -- I'll back up a little bit. Time and materials contracts mean you pay for the hours of our development team that you use plus any expenses. If it's a three week project, you pay for three weeks. Done, very simple. Then a fixed bid contract is where you say, "Hey, I have this idea. How much will it cost for you to make it?" And the firm comes back and they say, "I think it'll be about X." And so at the end -- or realistically maybe spread out but you'll pay X at the end. The problem with that is there are all sorts of ways that your vision can be misconstrued or misunderstood, or if somebody just doesn't get your vision right and then you don't have an opportunity to change and pivot or even to make really good corrections through the development process.

NOEL: Right, because typically a fixed bid contract is dependent on a fixed set of outputs. Usually the estimate depends. So it tends to be less flexible to change. I think there's also a question about one difference between these different kinds of contracts is who is taking on more risk financially.

ASHLEY: It's a good thing to consider. Certainly on a time and materials contract, the client takes on the risk to some extent.

NOEL: Right, because in a strict time and materials contract, the client is paying for the cost overrun.

ASHLEY: Correct.

NOEL: If there is one.

ASHLEY: If there is one. But also if it's less, if it's slightly less than they expected, the client isn't paying for it. On a fixed bid basis, there is a premium built in. It's an insurance policy for the development firm who's making a guess about how long this will take. Noel, I've heard you speak so beautifully about why estimation is hard. Estimation is really hard. I've legitimately never seen anyone get it right. Not get it right all the time, just get it right, period. Be really, really good at estimation. And the fixed bid firm, we'll add in a premium to make sure that they're not bleeding money at the end of this.

NOEL: Yeah, something to sort of mitigate the risk a little bit. I have, in fact, worked for a company that very shortly after I left went under because of a fixed bid contract. They had agreed to a fixed bid contract and then the client would not agree that the software had been done, completed, and never paid them.

ASHLEY: What a nightmare.

NOEL: Which is a risk.

ASHLEY: Yeah.

NOEL: That's why software companies tend to be a little skittish about fixed bid contracts. But there's all kinds of sort of compromise that we use sometimes or we have used in the past is to lower the hourly rate after a certain amount of time has passed to spread the risk more evenly between the client and the development shop. There's all kinds of ways to get creative there.

ASHLEY: My favorite is to suggest a contract that's time and materials with a cap. So, "Listen, this is not going to overrun wildly. And if it does, we have a set point that the contract can't go any further. And if it does, we can all have a conversation about why it's going further and what's happening." But it does put some controls and some safety. Really, it's psychological safety for the client that this is what it will take on a time and materials basis, not going above X.

NOEL: Right. The thing that's important there in both of these is to have a sense going in of how both sides are going to manage changes because there's going to be changes. The client's gong to request changes because something's not going to look the way they want. The tech team is going to request changes because something turns out to be more complicated than they thought. And however you're doing this, the contract or the terms need to be able to adjust to changes in the terrain.

ASHLEY: So, that's really interesting. And also, a really lovely pivot to what to expect when you have hired somebody. You've figured out the contracts, you've been really open with them about your expectations and your vision and you've picked the people that make you feel really good about how they're going to bring your vision to life. So Noel, what are some of the best ways to interact with a development team, especially if you're not a technical person?

NOEL: The important thing about dealing with a technical team, if you are not a technical person, and also if you are a technical person, hopefully this will give you some guidance as to what the non technical people are expecting. The thing to understand is that from a technical perspective, you're very much in the position of an auto mechanic, telling somebody that their brakes are shot. The mechanic or the developer has expertise into seeing that there is a problem the other person can't see. And I'm asking that person to pay possibly a substantial sum of money for it. So, it's incumbent on me to, first of all, try to explain the problem and to build up the kind of trust where when I say like, "Here's the thing you didn't expect and can't see that it's going to cost money that you're paying me" that you believe me. So from the client's side, what you want is you want to have that trust in your development team. There are some things to look for and some things to expect. You should expect that if you want, there should be as much communication from you as you want. And I've dealt with clients who are comfortable with a wide range of interactions. I've dealt with people who are very hands off. I've dealt with people who want to talk every day. But the developers should be willing to accommodate you and they should have somebody who is there to answer your questions. Another thing that's important is that you get to see and interact with the software incrementally as it's being built. The key, one of the reasons why these processes that we call agile are so important is that you can make more fine tuned adjustments over time if you work in smaller steps. And one of the keys to that is presenting the client with incremental pieces of software that aren't finished that only have some of the functionality that the person can interact with and first of all, potentially find bugs. And second of all say like, "This is what I want to see and this is not what I want to see." You don't want to deal with somebody that is not going to be able to deliver software to you regularly. And in development process, regularly to me means daily or every other day. You should have continual incremental process.

ASHLEY: Agreed. Tell me about estimations. Why are estimations hard for everyone?

NOEL: Estimating software is tricky. Estimating anything is tricky. I think that we, in the software community, tend to believe that estimating software is like uniquely hard. But if you've ever asked anybody to do like house renovations or landscape work, you know that estimation is actually just tricky. Like those projects are also often known for going longer and costing more than they originally do. And there are a couple of reasons for that and there are a couple of things that a good software team will do to try and make the estimates as trustworthy as possible. One of the reasons why the estimates tend to be tricky is developers tend to be optimistic and tend to not necessarily think of all of the complexity. In that respect, it's much more common to miss complexity than it is to imagine complexity is not going to be there. If you think about, like one of my analogies is like how long does it take to get to the airport?

ASHLEY: I love this. Yes.

NOEL: Yeah. I always say it takes 20 minutes to get to the airport, which is an estimate and it assumes that traffic is going to be running cleanly and that I'm going to be able to find parking and that there's not going to be a rainstorm and all of that stuff. The net effect there is that all of those things make the journey longer. And no matter what happens, like I can't get from my house to the airport in 10 minutes, no matter how great the traffic looks like, it's just too far. So I think that software teams tend to be really good at noting the complexity and noting like the minimum distance to the goal. But there's a whole set of interactions along the way that are easy to miss. They're easy to not realize. Sometimes, you don't realize exactly how complex something is until you really start doing it.

ASHLEY: Yeah.

NOEL: That's sort of unavoidable.

ASHLEY: You know, in the development firms that I've worked with, I've always worked with really brilliant, honest developers who have always wanted to under promise and over deliver. And when it comes to the estimation, nobody wants to have underestimated something. And so there's this joke between software developers that if you're estimating something, you should double it and add a zero. If you think it's going to be 10, you should actually say, it's doubled and then add a zero, it's 200. And so, because the developers that I work with tend to be such wonderful, nice people, I think this is one of the things that makes estimates so troubling. They way over estimate something and then it's difficult to land a client if you have way over estimated something.

NOEL: Right. There's a lot of trick. There's a lot of things going on there because what happens is over time, if you're a software developer and you've done a lot of these estimates is you sort of develop kind of rules of thumb. Like, I don't know exactly what the complexity is going to be, but I know there's going to be something. And that's where like these sort of jokey like double and add a zero kind of things come from is that there's a legitimate, like I know something's going to come up, but I don't know what yet. If you've ever watched a home improvement show where they trying to flip a house or something like that and they open up the wall and suddenly they see that all the studs are rotted and the job becomes a lot more complicated. That just happens sometimes. There's kind of a sense of, "I know something's going to happen, but I don't know what." And on the other end, there's this tremendous financial and also social pressure to bring the estimate in low. Clients want to see a low estimate when they sign on. It's comforting. And if you're being asked by a salesperson to produce an estimate, there can be a fair amount of like, not exactly pressure, but there's an understanding that you want the estimate to come in as low as possible because you're trying to get the work. And that becomes a tension where on the one hand, you want to double everything and round up to be conscientious, but at the same time you also want to do the work because most software development companies like being paid by clients.

ASHLEY: [Laughs]

NOEL: Yeah, it's just a thing.

ASHLEY: Yeah, it is tricky. I honestly think it's because you know, that's a difficulty I'm willing to take on because I work with such good, nice, honest people and I'd rather have that sticking point and occasionally wrestle with, "Come on, you and I both know that's not going to take six months." I'd occasionally wrestle with that over working with crummy people any day.

NOEL: Yeah. It becomes really hard because then you're like, "Will it take six months?" "I thought it would, but let me think about it again. Maybe it'll be four months." It could? It could be a great four months. Who knows? And that becomes hard. To some extent also, a lot of the mechanisms, there's sort of two ways to estimate a project. One of which is to say like at a top down level, this project is very similar in size and scope to X other projects that we did and that costs this amount of money. And the other way is to kind of try and list all of the things that you need to do and estimate all the individual little things you can do and sort of count them up. Say like, "We have 300 individual one day things to do in this project." And as much as it sounds like the counting things and building things up method is going to be more accurate than the sticking your finger in the air and saying, "This is about the same size as this other project." I actually don't think that at the beginning of a project that one of those methods is significantly more accurate than another for somebody who's got some experience putting estimates together.

ASHLEY: Yes. And particularly, if you're not going to be the one actually doing the work, I think that makes it really tricky. You don't want to find someone else up for some really aggressive deadlines and it's hard to tell, "Noel, you're our principal developer and you're an outstanding developer. You can do things very, very, very quickly that other developers just can't speed through."

NOEL: Yeah. I actually think that there's a significant issue here when you're dealing with people who don't -- there's a certain amount of time where sometimes people who don't have as much experience estimating or doing larger projects will just legitimately not know about certain complexities. At the same time, you sometimes get people like me who have experience and become somewhat hidebound and don't know that there's a newer way of doing something that might be faster. So, everybody comes to it with certain blind spots and it's tricky. Another thing that's tricky about this is that if you talk to a number of different software firms, you may get estimates that are across a wide range of things and there's a certain temptation to like, "Of course, my long-term cost is going to be lower with the company that is going to give me the lowest estimate." That is not necessarily true in part because of some of the quality issues that you talked about earlier. A low cost software that gives you low quality software means you will be continually paying not just for bugs but also you will be paying because the cost of making changes will be higher because of the quality of the software. And a lot of times, a lower estimate, you have to ask carefully, like who is producing the estimate, what's in the estimate, what value are they going to be able to bring? It can be tricky.

ASHLEY: Yeah, absolutely. Especially when if you're not technical yourself, oftentimes you really only have a price to go on and how you feel about working with somebody. So out of hand, you can probably say, "Well, these people give me not a great feeling. I don't know how I'd work with these other people. So I'll narrow it down to three and then pick the lowest price." And I think that would be great, except it assumes that anybody does estimations perfectly. And really, we're just trying to do the best we can.

NOEL: Yeah. Another thing that is kind of important to know when you hired a development team and that they're already starting to build this incremental software for you. Another thing that's really important to understand is that, especially through the development process, there will be bugs and there'll be software that behaves not quite as intended. There'll be things that don't do exactly what you want. There'll be things that don't do exactly what the developer wants. Things will happen that are unexpected. And it's not great, obviously, but that's part of the process. Part of the process is finding those things. Especially early in a web project, I find that a lot of things that come up really early on are super quick to fix. If you're like testing the software, almost any bug looks the same to you. It looks like I no longer get the webpage. I get a page that says 'oops, there was a crash'. But that can mean almost anything on the developer side. It could mean that somebody typed a word wrong and it will take literally 10 seconds to fix. Or it could mean huge conceptual problems. But most of the time in the early going, it's closer to the typo. It's worth getting a sense for how responsive your team is going to be to those kinds of things. I think a good team of developers will be really responsive to that kind of thing. And especially, we'll try to keep especially the small problems clean and try to prevent, especially because by cleaning up the small problems, it makes it easier for you to test the software. So yeah, that's another thing to look for and to think about as you're building it incrementally. Like no software team wants to leave bugs in, but there are always going to be things that don't work as expected the first time out.

ASHLEY: Hey, Noel.

NOEL: Yes?

ASHLEY: So somebody is nontechnical and is just starting to work with a technical team. What are some signs that it's going really well and what are some signs that should raise alarm bells?

NOEL: I think a sign that it's going really well is that the developers are very happy and eager to talk to you and excited to show you new things and are occasionally coming to you and saying, "Hey, we finished this faster than we thought. You may be able to do X other thing." Developer happiness is often a good proxy for how well things are going.

ASHLEY: Awesome. That's a good metric.

NOEL: At least in my experience. Things to look for that are kind of warning signs. If communication suddenly cuts off or slows down, that can be a problem. If you start to see these errors in this incremental software and they're not getting fixed, it could mean the team as being overwhelmed. It could mean that the team is having some quality issues that are making these bugs hard to fix and that's something to look out for if the team is consistently in the micro level underestimating stuff. In other words, not that, "I think that this project is going to take eight months and it really takes nine, but I think I'm going to have this thing ready tomorrow," and it's not ready and tomorrow I say it's going to be one more day and it winds up being one more day for like two weeks, that is often a sign that the team is getting overwhelmed and things are slipping behind schedule. It is exceptionally hard for a software team to gain on the schedule once they start to slip. In particular, it's like a fairly widely accepted software engineering move that adding people to a team that is already behind schedule does not necessarily help move the team back on schedule.

ASHLEY: [Laughs] Is that primarily because people have to come up to speed?

NOEL: Yeah. If you're adding people to an existing team, one thing we like to say is that teams are immutable. You don't actually change a team. You get a new team by adding a new person. So, not only do you have to bring a person up to speed, which is taking time away from the people who are already on the project, but there's all sorts of new lines of communication and things that sort of have to get worked out. Although in the long term, an eight-person team can produce more than a six-person team. In the immediate term, it's not going to help the six-person team catch up. And if you start to fall behind schedule, the best thing to do is to like regroup, try and figure out where you are so that you don't slip further behind schedule. Really think about what's important in the project and try to salvage that as much as possible. A lot of times, teams will, especially teams that are trying to do agile, will try to work in kind of priority order where they try to do the highest priority things first so that if you do start to fall behind schedule, at least the highest priority things will be done.

ASHLEY: Yeah, I like that method quite a lot.

NOEL: For me. I think it's really important to have communication and to have people that you trust that you believe when they say that they're going to do a thing and that when they come and say, "This is more complicated than we expect," that you believe them.

ASHLEY: Yes.

NOEL: And that's the most important thing to a successful project.

ASHLEY: Yeah. Well, I am happy to answer any questions. I love talking to people before they're looking for custom software development. If there's anything that I or Table XI can do to help walk you through that, we'd be happy to do it.

NOEL: Yeah. Where can people find you if they want to talk to you about how to buy software?

ASHLEY: I'm on Linkedin at Ashley Quinto Powell. They can email sales@TableXI.com.

NOEL: Thank you very much for being on the show this week, Ashley.

ASHLEY: Thanks, Noel.

NOEL: Tech Done Right is available on the web at TechDoneRight.io where you can learn more about our guests and comment on our episodes. Find us wherever you listen to podcasts. And if you like the show, tell a friend or your social media network, or your friend's social media network, or tell me, I really like hearing nice things. And leaving a review on Apple Podcast helps people find the show. 

Tech Done Right is hosted by me, Noel Rappin. Our editor is Mandy Moore. You can find us on Twitter @NoelRap and @TheRubyRep. 

Tech Done Right is produced by Table XI. Table XI is a custom design and software company in Chicago. We've been named one of Inc. Magazine's Best Workplaces and we're a top-ranked custom software development company on clutch.co. You can learn more about working with us or working for us at TableXI.com or follow us on Twitter @TableXI. We'll be back in a couple of weeks with the next episode of Tech Done Right.