Subscribe
Share
Share
Embed
Welcome to the Ksense Technology Podcast where we discuss the trends in software development, web applications, and how custom software can help businesses scale. Ksense is a full-stack software development company using state-of-the-art technologies to build cutting-edge applications. With over a decade of software development experience, our team is confident we will deliver results for your organization.
[Kelson] (0:00 - 0:08)
But the way that we like to think about software is we're in a partnership with the company that hires us for the long run.
[Calvin] (0:08 - 0:13)
Because there's a lot more to it than just writing code, it's actually understanding how to solve your business problem.
[David] (0:14 - 1:04)
Excellent engineers will always have, you know, some sort of bug come up because bug is a really broad term. All right, welcome to the podcast. I'm here with Kelson and Calvin from Ksense Technology Group, which is a company that builds custom software for all kinds of organizations out there.
And today, I'm excited to talk about what the mistakes are that companies often make when they're doing custom software projects so that we can help people avoid those mistakes and, you know, plan ahead for success. So thanks for joining me, guys. Yeah, thanks, David.
You bet. All right, so let's just jump right into it. You know, we're talking about mistakes, maybe common misconceptions or things that people don't realize before they get started on a project like this.
What would you guys say are those top mistakes that people make?
[Calvin] (1:07 - 3:02)
So there's three main mistakes that I've seen, and they all relate to a similar sort of thing, which is basically just a lack of knowledge about how web apps get developed. Of course, the developer that you choose to hire should be able to guide you through the development process, but it's very helpful to understand the fundamentals of how web apps are developed so you can avoid these mistakes. The first one is basically not having a good enough understanding of what you need to build, and that can happen in many different ways, so we'll talk about that.
Then we have a second mistake kind of related, which is basically not understanding how long things take to build, so that's cost and timeline. And, you know, most people who aren't developers who haven't worked on web apps before, they don't know how long things take, and so that's where you want to have a really upfront and honest conversation with your developer or whoever's your app so that you can really understand, because they're going to have a lot better of an idea than you are about how long things are going to take, so it's important to go in.
Usually the rule of thumb is it always takes longer than you think it's going to take, and that's just because of the complexity of web development. And the third mistake I would point to, which happens more often when you get started with a project, is trying to build too much, and it's sort of related to the other two mistakes. These three mistakes are all kind of related to each other, but trying to build too many features, trying to add too much too early is a huge mistake, because it seems like, oh, I'll just add this feature, it's not going to be any big deal, but actually, you know, it ends up being a lot more work than you thought, so it's really important to really cut the scope as much as possible and avoid adding too much.
[David] (3:03 - 3:21)
Yeah, yeah, that's a really good top three. Let's dive into those a little bit more in detail. On that first one, you know, just not understanding well enough what you need to build.
Tell me more about that. How do you define the requirements for a project? How should people be thinking about that in the early stages?
[Calvin] (3:22 - 4:29)
Well, all you need to really do as a business owner, if you're going to build an app for your business, the most important thing for you to do is to just understand what your process is, and of course, you know your business, but do you really understand exactly how that workflow happens, what order needs to happen in, and how to explain that and communicate that to the developer, to the development team or the business analyst, because you might, you know, you might know how things work now, like if you're using spreadsheets or whatever, you might kind of understand like how that works right now and how like your team works together, but it's another thing to be able to explain the process. Really clearly to someone who's going to build a different solution, it requires a little bit of a deeper understanding of exactly how that workflow works, and once you start digging into that, you'll probably also discover things that aren't really working in the workflow.
So it's good to also know how to describe those things so that we can build a solution, like the development team can actually design and build a new solution for your business workflow.
[Kelson] (4:30 - 5:26)
The most helpful thing, I think, is when a client comes to us with diagrams on how their system currently works, either hand-drawn or built in some, you know, fancy software. That's incredibly helpful because it allows us to kind of have a top-down view of the overall system that the software is going to replace, or a new system that's going to be implemented, and another thing that's just come to mind is knowing all the things that you've tried that haven't worked can also lead us in a really good direction to know really what your needs are. Knowing, hey, we tried a low-code solution, it didn't work for us, or we tried this off-the-shelf software and it didn't work for us.
We can start digging in and asking, why didn't that work for you? And that will lead us closer to a solution that will work for you.
[David] (5:26 - 5:33)
Yeah, it's a good strategy, good thought exercise to just kind of help you identify those things.
[Calvin] (5:33 - 6:09)
The other thing, too, with that is knowing the difference between nice-to-have and must-have. Like, if you have a business process and you want to basically digitize it or put it on the cloud or replace manual processors or whatnot, what are the things you have to have for this process and what are the nice-to-have things? Because that feeds into another issue, which is basically trying to add too much.
That's where it really comes in handy to know, okay, if we don't have this feature, it's not going to work at all, basically. And that'll guide the development process.
[Kelson] (6:09 - 6:57)
Yeah. And one thing to kind of add on to that, a thing that people don't think about very often but is really, really important is the value of verbal communication. I have seen many people that try to hire an agency and think that they're going to be able to get their web app built based on text, email exchanges.
It's not ever going to turn out how you want it to unless you're continually chatting in person or via some sort of video call or phone call. A video call is the best because then we can share screens and demonstrate what's going on. Or in person, of course.
There's nothing that can replace those conversations. As much as you want to try to take a shortcut and write it all out, all your requirements in email, you will never get what you're looking for if you do that.
[David] (6:58 - 7:36)
Yeah, it makes sense. There's a lot of ways that things could either be misinterpreted or a lot of times maybe you think you've given enough information but you're just too vague, so natural conversations help us fill in those gaps really easily without even having to really think about it too much. I wonder if you guys can tell me more about what it looks like if people get too far down the process without having clear requirements.
What are the consequences of that? What sort of challenges do you run into? I wonder if you guys can think of maybe an example of when that has happened with one of your clients when they didn't do a great job of this.
[Calvin] (7:36 - 8:54)
If you're doing discovery, you're talking to whoever's going to build your app, and you are talking to them about what you need, but really what you're doing is just kind of throwing things out there, brainstorming. That's fine, but if you're telling them, okay, we want this, this, this, and this, and half those things really aren't necessary, or maybe all the things you're describing are sort of ancillary and really there's something that needs to be built first. You just have to have a clear idea about basically, okay, here's the features that we need, and we need these first, and then here's the features that we need second, and then here are the nice-to-haves.
If you don't have that sort of mental model of what you're trying to build, then what will happen is you'll be talking to the developers, and they'll do a whole bunch of work either planning or actually building things that aren't going to solve your problem. Depending on how long it takes for everyone to figure that out, to get on the same page, you might lose a little bit of time and a little bit of money, or you might lose a lot of time and a lot of money depending on how long you were working on things that actually you didn't need to work on or that weren't going to solve your business problem.
[Kelson] (8:55 - 9:57)
Yeah, I mean, you could actually take this mistake and break it into a ton of different mistakes, right? You can break it into the mistake of misunderstanding project requirements, where, like I was saying before, if you are communicating via text, like a text medium, then you have the mistake of the developer or you misunderstanding each other very easily. You can have the mistake of scope creep, where you're adding a bunch of things in that would be nice to have but aren't really important to your business process.
Or you have the mistake of incorrect prioritizing of the features that are going into the app, which means that the meat and flesh, the potatoes here of your application are getting delayed. And so the application takes way longer and costs more than it should have. And so you could probably sit here and whittle number one mistake into a lot of different mistakes.
And I'm wondering if we should dive deeper into that and talk about each of the big mistakes.
[David] (9:58 - 10:31)
Yeah, yeah. So you talked about scope creep. I think that's a big one.
How does that usually happen? Because I know this happens to the best of us, right? There are people who are really smart, who have some great experience in business.
They've completed a lot of successful projects. And it still happens where we think we've got a clear view of the project. And as we go, we're like, oh, but what about this?
And what if it worked that way? So how should people approach that? Is it okay to have some scope creep?
And if so, how do you balance that?
[Kelson] (10:32 - 10:36)
We should probably define what it is first, don't you think? Oh, yeah.
[Calvin] (10:36 - 13:00)
Yeah, I can do that. So what scope creep basically is, is where at the start of the project, everyone has a shared understanding, ideally, of what they're going to build and what the scope of that is. Where do we draw the boundaries around this thing that we're building?
What is included in this final product that we're going to build during this phase and what's not included? But then what happens is, it's never really a clear boundary between the things that are included, and the things that are related to those things that are sort of included. Because basically, what happens is you have a feature, but this feature, sort of there's a bunch of implied features that are related to that feature that, you know, could, you know, under some interpretation be included in the scope, right?
So if I, let's say I have a feature to, I don't know, add something to my shopping cart, right? And I tell you, okay, so I need to be able to add something to my shopping cart, and I need to be able to remove something from my shopping cart, right? But then when we start building it, at some point, you know, as the client, maybe I didn't think of this, but at some point, I realized that I also want the ability to see how many of an item I have in the shopping cart, right?
Or maybe to add more than one item to the shopping cart at a time. So these things like, I might say as the client, well, of course, like every shopping cart feature has that. So that should have just been a given, right?
But nothing's a given. That's the problem in software development. Basically, every single thing that you want to build has to be specified explicitly.
And if it's not, then that's where you're going to get scope creep, where, you know, there's a thousand different things that could be implied, or could, you know, could, under some interpretation, be part of this feature. But unless you specify them very clearly, they're not going to get included. And then you're going to have a situation where you're asking for additional features, which is normal.
It's a normal part of software development. And it's one of the main reasons that we don't do like fixed pricing or like, you know, we don't pretend that we know everything that's going to be needed because you never do. There's always something else that, you know, wasn't thought of, or especially since even if you do think of every single thing up front, once you start using the feature, you're going to want to change things and there's going to be additional things that come up, right?
So I guess that's how I would explain it.
[Kelson] (13:01 - 13:24)
And even if there aren't things that you think of and different things that come up, your business is going to change, the market around it's going to change. You get a new business relationship, and now you want to integrate that, or the API that you're using for SMS or whatever is bought out by a different company, and now they're deprecating their API. And so you got to find a new one, just to throw out a couple of examples.
[Calvin] (13:25 - 14:42)
Yeah, I don't know if anyone's ever heard of this example of like, sometimes in school, like this is given as an example of like, in a math class or something where they're talking about being explicit, but basically like someone gets up at the front of the class, and then the teacher tells them, okay, I want you to give me instructions for making a peanut butter and jelly sandwich. And the person's like, okay, I'll start giving you these instructions. So they say, oh, well, take out the bread and, and add the peanut butter and, and jelly and then put the bread together.
And then the teacher starts going through it logically. And you find out that it wasn't explicit enough. You're like, okay, add, where do you want me to add the, you know, should I add the peanut butter on the outside, you never said to put them so that the peanut butter and jelly are on the inside of the bread, right?
So like, basically, there's, if you're not really explicit about how the instructions are given, then you can make you can create a set of instructions that will not lead to the right result. And that's really where scope creep comes from. Because you imagine one thing, you imagine a result, but then the way you describe it, someone else imagines a different result.
And so you end up getting scope creep slash features that you weren't expecting or that don't work quite right for you.
[David] (14:44 - 15:20)
Make sense. Yeah. And it's, I mean, like I said, it happens to the best of us, right?
Like sometimes you should have scope creep in those situations that you described where you realize later on, actually, this is important. We do need these features. We need it to work that way.
Right. And so scope creep itself is not the enemy. The problem is when there's a lack of control there, right?
Or a lack of prioritization, like you were talking about. How often does that happen? Can you maybe think of an example where a client just didn't handle that well and didn't prioritize well when it came to the features they were asking for?
[Calvin] (15:21 - 17:28)
Well, yeah, if you think about it, web development, the entire web development project is nothing but one long series of scope creeps basically, right? So, I mean, that's how agile development kind of works because every single iteration you have scope creep because basically you build something, you let them test it, you let the user start using it. And then now you creep to the next iteration, which is, okay, we want to change these features.
We want to add these features. The key is when you to have control over it, you want to, first of all, keep the, like cut the scope and make it as small as possible. That way, if you mess up or go the wrong way, you're only going a little bit, you know, like if you build, if you spend six months building an app and you expect that the user's going to, you know, it's going to work for them, that's six months where you could have been going in the wrong direction versus two weeks.
So, you go two weeks in the wrong direction and it's no big deal because it's just a one tiny feature. But if you try to build an entire app, you try to write out all the requirements like waterfall, that's the waterfall methodology, right? So, you do that for six months, then you build a completely different app than the client was expecting, basically.
So, yeah, there's been plenty of examples where clients, where that has happened. A lot of times, a lot of times those stem from basically just a miscommunication of what the client was expecting. You know, I can't think of a specific example, but basically that's where Kelson was saying face-to-face communication is really important because we've seen a lot of times where we'll write out user stories and requirements and we'll give it to the client to approve, but they're not going to be able to really read that and just understand and just get like, basically see what our vision is or what we were thinking when we wrote that. That's why user stories aren't actually meant to be comprehensive requirements. They're just meant to be a placeholder for a conversation about the requirements.
And that's why we try to talk face-to-face with the clients when possible so we can have a shared understanding because there's just, it's too hard to replicate that communication through written form. There's too many ambiguities.
[Kelson] (17:28 - 17:53)
Yeah, even the best authors in the world, if you read one of their novels and then I read it, we'll have two different ideas of what the meadow looks like in our head, right? And it's the same thing. There's even the issue with face-to-face communication that there's already enough miscommunications.
Going to just text is a pretty big mistake that you really don't want to make. And I think a lot of people do make that mistake.
[Calvin] (17:54 - 18:18)
Yeah, no matter how you try to write down requirements, there's only one way to write them down with complete logical accuracy, and that is to write the code. Before you write the code, that's why, you know, if there was a way to write the requirements with 100% accuracy without writing the code, then we would just do that. And that would probably be the code for the app, right?
[Kelson] (18:18 - 19:48)
Yeah, so I'd say that the whole process, the entire process, if we were to break it down, would be first define the bare bone minimum of what you need for your operations to work and what things are the cherry on top or the bells and whistles that aren't really needed. Write them all out as thoroughly as you can and understand them very well and who they affect in the business, all the different stakeholders and the users of the application. And then you need to talk to them, talk to somebody about those requirements, a business analyst, and the business analyst will say, this is how we can make software around this, and this is how we should prioritize this.
And they'll break it down into pieces for you and they'll do this on a face-to-face call or a screen share so they can show examples. And then what you do is you take two steps in that direction, you get a little bit of software built, you get it back in your hands, business analyst says, is this what you wanted? And you say, yep, that looks good, let's keep going down that road.
And you keep doing that over and over and over again. The real value of the business analyst isn't just to be able to transform your vision into real working software, it's to be able to tell you, no, this is not the right way, no, we need to cut this out, this is unnecessary scope to add, or this is a direction that's going to end up costing you a lot of money. A good business analyst is really worth a lot of money and they're very, very valuable to have.
I wouldn't build software with that one.
[Calvin] (19:48 - 21:16)
I mean, it gets even more complicated by the fact that to solve one problem, let's say you have a problem, you need to be able to track how many orders your clients are making per week or something like that. Well, there are many different ways to solve that problem. And those different ways of solving it are constrained, first of all, by what system are we building in?
Is it a brand new system or are we building in an existing system? If it's an existing system, then we have to work around the code that's already there, the software that's already there. So then that cuts out some of the options on how it can be solved.
And then there may be multiple different solutions within those options. Like one of them might take five times the amount of time to build as the other, but they might do the same thing. So sometimes there's another way to do it, maybe it's slightly more convenient, maybe you might like how it looks a little bit better, but then it's going to take five times as long to build.
So the business analyst should give you those two options, say, well, this one will achieve your goal. This one will achieve your goal a little bit. It'll be a little bit nicer to look at, but it'll take five times as long to build.
And that's when you can say, okay, it's not worth it. Because as a non-developer, you're not going to be able to know. To you, it's going to look like those two things should both be super easy and they're going to take the same amount of time.
The business analyst can tell you, actually, this one's going to take five times as long.
[Kelson] (21:17 - 21:37)
So do you think my framework is pretty accurate? I know that there are a million different ways to cut it up. There's a million different strategies to approach requirement gathering.
There's whole books written on the topic. But do you think, Calvin, that my rudimentary little framework that I presented is a pretty good approach for people who are starting out?
[Calvin] (21:37 - 23:45)
So the first step is, first, the business owner writes down what they want the software to be able to do and who it affects. And sometimes, if you don't what you want it to do, because that can happen. Sometimes, you don't know what you want the software to do.
You just know how your business currently works and why it doesn't work the way it's supposed to. Then you can say, okay, instead of listing how you need the software to work, you could just list a problem that you want to solve. That's an even more general level, because it's solution agnostic.
So you say, this is the problem with our current system. Then the business analyst can look at that problem, and they'll think of many different solutions, right? Many different.
If you say, well, the problem is I can't see. I don't have visibility into my shipments. And I can't see when each shipment is going to arrive at the warehouse.
I can only see if they're shipped or if they're unshipped. That's my problem. Business analysts will think, well, so you, as a warehouse manager, you want to be able to see what stage of the journey your shipments are in.
So then they'll say, oh, well, what are the different stages you want to see? Every time it's checked into a different warehouse along the way, they'll start digging into how the business works. But yeah, I think that framework is good, because it starts with the business logic or the business rationale.
Just like if you were trying to improve your business process without software, you first start with how does the business work? What are the bottlenecks and issues? Who are the people that need to be able to run the business or go through the process?
And then that's all the stuff when we're talking about this first mistake of not knowing what you want to build. That's the stuff you need to know as the business owner is the stuff that you would need to know even if you weren't building software, the stuff that is business specific. And then the person or the agency that's helping you build the software, they're going to know once you explain that to them how to think about those requirements in the context of software.
So yeah, I think that's a good way to break it down.
[David] (23:46 - 24:05)
Perfect. Let's dive into mistake number two. You guys said basically underestimating the cost or the timeline for the project.
Obviously, that's really related to the scope of the project that we were just talking about. But tell me more about that. What do people do?
What kind of mistakes are they making?
[Calvin] (24:06 - 25:50)
So not understanding the cost and timeline is pretty much a guarantee. The thing with engineering is it always takes twice as long as you think it's going to take. It always costs twice as much as you think it's going to cost.
The reason for that is that we're building something that has not been built before. So if you take a blueprint for a house, that exact house has probably been built before. And if not, every component in that blueprint has definitely been built before.
A set of stairs, there is a right and a wrong way to build those stairs. And it's known. It's completely known by the people who are going to build them exactly what the step-by-step process is to build those.
And it's been done a bunch of times. With software, if it had already been built before, then either it would be a product on the market that you could just go purchase, or it maybe was built by a company who you don't have access to, and they built it for themselves. So you have to now rebuild it for yourself.
So since it's never been done before, and it's an engineering problem where someone has to create something from nothing, that's why it is usually going to take longer than you think. People tend to underestimate the difficulty of engineering problems like that, because it's a lot easier to not think of the details than it is to think of every single detail up front. You're simplifying it down in your brain.
You're thinking, okay, I can imagine what the software needs to include. But if you tried to think of all the details, you really wouldn't be able to because there's just too many different details, there's too many different edge cases, different scenarios.
[Kelson] (25:51 - 26:06)
It's like the sandwich example, right? You think of it in a very macro sense, right? But once you really dive in, there's so much more under the surface than you think, right?
[Calvin] (26:06 - 26:38)
Yeah, like you say, okay, I want you to spread the peanut butter on the sandwich, and then the teacher takes their hand and says, okay, and just dumps their hand in the thing. No, no, not with your hand, with a knife, but you never told them to use a knife, right? So yeah, there's always more, like there's a bunch of implied steps that usually when you think of the solution, you're just skipping those.
You're just assuming that, oh, well, of course, a database, it's easy just to spin up a database, but that's actually a huge task, and there's many things like that.
[Kelson] (26:39 - 27:47)
Yeah, there's like, how do all of these pieces work? Like the pre-built pieces, how do they work with the custom pieces, right? What off-the-shelf technologies are we going to use?
What frameworks? How are they all going to work together? There's all the technical side of things, and that's an engineering problem of itself, but the discovery process also takes a lot longer than people think it does, and the example that I like to give people that kind of drive the point home is, imagine that I'm a writer, and you're hiring me to write a novel for you, and you said, how much is it going to cost?
How long is it going to take? I'd kind of throw my arms in the air and say, I have no idea. It depends on what type of novel you want me to write, and then even after we start breaking down, you know, the main characters, and the general plot line, and you know, all the ideas, the locations, everything, and we even, maybe we even break up all, and we even have all the chapters defined, and what they're going to, what we're going to talk about in those chapters, it still depends on, like, your vision of it coming together with mine. However long that part takes is going to take however long that takes, right?
[Calvin] (27:47 - 28:13)
Yeah, you could spend, you could just spend, you know, a whole day on a single sentence, or a single paragraph, maybe not a whole day, but like there, think of how many different ways there are to word one sentence, like, oh, I just don't like how that sentence sounds, and then you're talking about entire book, so the question is, how long is it going to take for me and you to agree on a sentence that sounds good enough for you, like, to solve your problem?
That's kind of how the software works, too.
[Kelson] (28:14 - 28:26)
Yeah, and it's not done until we both agree that the novel's done, right? But you're hiring me, so it's your decision when it's done, not necessarily mine, right? So it's going to take as long as you make it take, right?
[Calvin] (28:26 - 30:16)
What happens a lot of the time when you're building a feature is it starts out where it seems pretty clear, okay, we want an email notification system, and that system needs to send an email each time someone adds a record, let's say. So if you're building that, it sounds straightforward, it's like, this trigger happens, and then this event happens, send the email. But once you start digging into it, there are all sorts of different things that could happen that then need to be accounted for, what if you might have said, well, it needs to send the email to anyone on the list, right?
But then you find that with that direct implementation, if that person is on multiple lists, they might be getting many duplicate emails. So I'll look at my inbox, and I'll have five emails because I was on the list as a user, and I was on another related list that overlaps with that list as a user or a user role or something. So I'm getting duplicate emails.
So I guess I don't know if that example is super clear. But basically, that's a new scenario no one thought of, oh, we didn't think of the fact that you only need that email to show up in your inbox once, you don't need it to show up every single time the trigger happens, right? Just once will be enough.
So then you got to build a filter, you got to build a feature to deal with that. So these different edge cases happen, and they require their own solution. So it's impossible to think of all those up front.
And that's just with one simple feature. And as you're building the app, every single feature has like 100 different things that might happen that might change the result. And as a business, you're going to need it to work a certain way.
So you just got to keep fixing those as they come up, which is why it ends up taking so long.
[David] (30:17 - 30:41)
What are some of the costs that people don't think about? I hesitate to use the phrase hidden cost. But you know, when somebody is thinking about a project like this, usually they're thinking, okay, development is going to take, you know, this much time, get an estimate on how long, how much it's going to cost.
Are there other costs throughout that process that they're not thinking about that they might consider a hidden cost?
[Calvin] (30:41 - 32:50)
Yeah, there are a lot of costs. One that comes to mind is the cost of deploying software bug free. So what happens is you'll, let's say you have your app, and the version one is complete, and it's working with no bugs, or very, very few bugs.
And some users are now using it. So that's on the production environment. Then you go and you want to build a new feature.
So the developer start, you know, building a new feature, think of the analogy of like a construction site, you know, if you put up the first, I don't know, like the frame of the building, and then you come in to start putting up the plumbing and the electricity and all that stuff. So the construction workers, they have to set up all the scaffolding, they have to bring in, you know, the bulldozers, it gets really messy, there's a big, you know, all there's a big mess being made around the construction site now. So now, all that stuff has to be cleaned up before it's ready.
So in the software example, you know, a feature that was working just fine. Well, we might have made a change now that with this new feature, and that this change might have broken something that was already working. So now we have to test the whole app, usually, to make sure that everything is still working correctly.
And the more control that you need it to be, like, if you cannot allow any bugs on production, the more resources have to go into testing. Every time we make changes, we have to test the whole thing again, to make sure it's still working. And that's why oftentimes, it can be useful to have beta users that are okay with bugs happening on production or on in their environment, because then we can go a little faster, we don't have to spend so much time like testing every single thing, every time we make a change, we can test it a little bit, you know, we test the new features that we built, we can push the changes to production.
And then those beta users can find, you know, if we accidentally broke something, they can find it, and we can fix it in the next version. But yeah, that's a cost that people don't think about is to keep a version of the app running with zero bugs is very cost intensive.
[Kelson] (32:50 - 35:04)
Yeah, let's talk about bugs a little bit more. So another hidden cost, I would say, is bugs in general, especially troubleshooting bugs, because we can deploy the application, show all the stakeholders, and everybody signs off on it. All right, we're ready to go.
We're ready to take this into production. And then we start getting bug reports. And, you know, once we start getting those bug reports, now we have the time to investigate.
And that time is billable, right? Obviously, no one's going to troubleshoot the app for free. So what is the troubleshooting involved?
Well, first off, we have to find out, is this user error? Right? Is this person?
Are they unfamiliar with how it works? Yes or no. And then after we figured that out, we have to decide, wait, is this person just misunderstanding how this feature works?
Is it working as intended, but they just don't understand how the feature really needs to work? Yes or no? Okay, we've decided that it's not the users using it correctly, and they understand how it works.
So now somebody has to go and dive into the code. Was this a third party failure? Was this something an upstream error is what we would call it?
Is this a service that we rely on like AWS or something that we have no control of causing a problem? Or was this a syntax problem, you know, a forgotten semicolon in 100,000 lines of code that only happens under a very specific condition that we didn't catch? And so there's all of this troubleshooting time that happens even before we're able to patch those errors.
And so that's something that, you know, people don't think about a lot of times when they're building applications. And there's a lot we can do to kind of offset those costs to make it so it's not, you know, 90% of your app is fixing bugs and 10% is building new features. But at the end of the day, it's just something that it's part of software development.
You have bugs, they exist, and they need to be fixed. So somebody has to do that work regardless.
[Calvin] (35:04 - 36:04)
There's like a long tail to every single feature you build in the app. So like, there's the first, you know, part where you're planning and building the core feature. So you're building it for the first time.
That's, you know, you might think of that as like, like the vast majority or if not all of the development time, right? Like, you have to build the feature. Once it's finished, you think it's finished.
But really, there's this long tail of bugs that will occur as a result of that feature or relating to that feature. Because if there's a bunch of code for that feature, there's many different ways that that code can break, that that code needs to be updated later, that a new feature will come in and change how that code needs to work. So there's this long tail of different errors that can happen, or, you know, not even errors, but things that require maintenance or changes that has to be accounted for.
So that long tail is something people don't think about, because that's going to need to happen until the app is stable and no longer really being changed.
[Kelson] (36:05 - 37:03)
Given my example of the user just doesn't understand how it works, right? If we give that example, then what is the client, you know, the client signed off, they signed it off, and they said, Oh, this works perfect. They understand exactly how it works.
But then they find out that not like 5% of their user base doesn't get it. So then what happens, they end up coming to us and they say, Hey, we need to rethink how this is, this thing's built, because some of our users, they don't get it. And then that is how a new feature is introduced.
Right. And so you can see that feature would have never been thought of before, because everybody was on everybody was satisfied with it. But once it's out in the wild, we find out that certain people, you know, that they have different understandings or and their different levels of familiarity with how web applications work, or, you know, different computers, levels, you know, a technical boils down to new features needed to be built.
[Calvin] (37:06 - 38:02)
And like, if you use these apps, like Amazon, Facebook, these apps that have millions and millions of users, what they've basically done is they have slowly over time moved towards the implementation that the most people understand and can use. So there are a million different ways that you can do anything on an app, right? There are a million different ways that it can be organized on the screen or laid out or whatever for someone to use.
But for each one of those ways, there are trade offs, like maybe for some people, this way of designing this feature is clear, but for other for like, you know, maybe 70% of people, it's clear for like the other 30%. It's unclear. So okay, how can we change it so that for the most use, like the most people, this is intuitive, you know, it makes sense, right when they open it, they can kind of see how it's supposed to work.
And that just requires exposure to real users, users are actually using it, you're not going to know what people are going to misunderstand.
[Kelson] (38:03 - 38:59)
And a lot of times the misunderstandings are just because people aren't familiar with how web applications work. Think of it like this. If you're I'll draw an analogy.
If you're familiar with first person shooters, then I can give you any first person shooter on a console, and you'll be able to figure out how to shoot the gun within seconds there, you won't need a tutorial, you you need no handholding whatsoever. But give the the controller to somebody who's not at all familiar with first person shooters, they'll have no idea. And the same thing rings true in web development.
We all know where the search bar is. It's at the top of the page. If you put it at the bottom of the page, people aren't going to understand how to use it, they're not going to, that's not where they're looking for it at.
So you have to think about these common trends, and then just hope that the trend is common enough and that your user base understands those trends, and they're familiar with them. Otherwise, there's going to be confusion.
[Calvin] (39:02 - 39:26)
Yeah, that search bar at the bottom of the page, technically, that fills the requirement that the user is able to search for, you know, records in the table. Yeah, if that's the requirement that's fulfilled, no matter where the search bar is. But then when someone uses it, that's, you know, it's not necessarily a bug, but it is it's a UX UI bug.
It's a user experience bug. Because, you know, if you look at that, you can see, oh, I can see how people are going to be confused about the way this is working. Let's change it.
[Kelson] (39:26 - 39:49)
Yeah, or you have like a Mac, you have like really good mock ups of of a page where click on the magnifying glass, and it opens the search bar. I've seen that before. And then next thing you know, people can't figure out how to search because they didn't know that the magnifying glass means this, like that is a search bar.
That makes sense.
[David] (39:49 - 40:30)
Yeah. So, you know, people a lot of times expect that if you're developing the app well, that there shouldn't be any bugs, right? Sometimes people just have that expectation.
And what I'm hearing and what I've seen in the past, excellent engineers will always have, you know, some sort of bug come up because bug is a really broad term, right? So I think you guys did really well hitting on some of the different kinds of bugs and how, you know, a bug could happen down the line after you've been using the software for a long time, just with, you know, maybe a third party changed how their services work or something like that. And you gotta, you gotta figure out how to adjust your app.
[Kelson] (40:30 - 41:08)
Just to chime in on that really quickly. Like something that is kind of interesting just to think about is that at any given time, in any given moment, the Facebook react, which is their UI library or UI framework, whatever you want to call it, has between 1,000 and 2,000 reported bugs at any, any given moment. There's probably close to 200 people or sorry, 2000 people actively working on that project.
So if Facebook is not able to get rid of all their bugs, what makes you think anyone's going to be able to?
[David] (41:08 - 42:49)
Yeah. And I was, I was thinking about this because it's, it's interesting to me how transparent you guys are about this, you know, because I think one of the problems, one of the reasons why this is still such a big misconception is because nobody wants to say, oh yeah, the product we developed for you is going to have some bugs. Right.
And so what you guys are saying is that's always the case, no matter what, what we're going to do is make sure that we meet these requirements, that we do really thorough testing and quality assurance to make sure that it's working properly before we deliver it. Right. And then we're going to be here for any feedback you have, any adjustments you need, any new scenario that comes up that nobody thought of, we're here for you.
Right. And so that level of transparency, I guess, is really cool. I think if more people talked about it that way, people wouldn't be so confused about, you know, why is there a bug?
This shouldn't happen, you know, and, and, and you're also, I guess I could say the same thing about your conversation around requirements because you're saying, hey, get really specific because miscommunication happens. Right. And I think a lot of companies wouldn't say that because they're just going to say, oh yeah, we're experts, we'll understand.
And then you run into the problems. Right. So, so I guess, I guess what I'm saying is I like the way you're framing it, the transparency, the, the way of communicating and saying, here's what we need to be aware of.
These are the challenges that any developer, any engineer is going to run into. So how can we make sure that we've got that good communication upfront and, you know, we're thinking about these things in the right way so that we can handle whatever obstacle we run into while we're trying to build your app?
[Kelson] (42:50 - 42:59)
A hundred percent. Yeah. A hundred percent.
There's a lot of push for dishonesty in any capitalist society, right?
[Kelson] (43:00 - 44:17)
Look in the construction sector or, or how cars are built. But the way that we like to think about software is we're in a partnership with the company that hires us for the long run. And we truly believe that software can solve business problems and it can be very, very valuable.
The ROI can be massive. That's why tech companies are some of the most highly valued companies in the world. So it's not in our best interest to try to sweep it under the rug and say that these things don't exist.
It's in our best interest to say, hey, these are all the problems. Like, yeah, it might be a little scary, right? I mean, this whole conversation probably is turning people off from the idea of building software, but yeah, there's a lot to be afraid of.
Just like building anything, right? Especially when you're engineering something for the first time. But if you know that somebody is there and they're experts and they've done this a lot of times, then, you know, you can kind of take the leap of faith and, and when these issues happen, when you do see bugs, you'll have a good understanding of why that's happening.
And I don't know, in my opinion, the more knowledge, the less fear you'll have, right? Yeah. And so that's what we're trying to do is just put out as much knowledge and set the expectations as the best that we can.
[Calvin] (44:17 - 46:03)
Yeah. And the benefits of software, even though they are like custom software is not easy to build. It's not easy to engineer something new that, you know, no one's ever built before that is custom tailored to your business.
But the benefits are enormous because, you know, if you can eliminate, like I've my, some of my clients have eliminated, you know, multiple full-time staff or move them to different departments or whatnot, because the software now just does that. And that's without any AI or anything like that. That's just the software automating processes.
So as a U S based agency, you know, we, we need to like ours, our differentiator is the fact that we not only are just going to, you know, build what you tell us to build and just do the minimum and, you know, charge you $15 an hour, like someone in India might, but it's that we understand the bigger picture of not just how to build software, but how to actually create a business, you know, some business infrastructure that's going to fit with your process and actually revolutionize how you do things, because there's a lot more to it than just writing code. It's actually understanding how to solve your business problems with the software, how to design the software, and then how do you implement it in a way that's actually going to provide value right away, you know, like as soon as you have working software in your hands. So that's, you know, it's like Elson said, it's in our best interest to do that because, you know, if we know that as long as we can provide you with, with more value than you're paying, you know, like more value than like provide you with net value, you're going to keep coming back to us.
Because, you know, the more powerful your software, software is, the more you're going to be able to scale your business.
[David] (46:03 - 46:55)
That brings up an interesting point, because we gave some examples earlier of, hey, be super specific, because, you know, maybe you'll just say we need a search bar, and maybe they'll put it at the bottom. In reality, we're not that dumb, right? Like, there is a certain amount of, of effort, and just assumption and intuition that goes into saying, okay, this is the best way to build this feature, or this is best practice in general, right?
So there is a balance there. It's not like, it's not like you guys are, are just, you know, needing them to specify everything, but you're bringing the communication to the forefront of, of every part of the project, right? Just making sure that, you know, clarifying when possible, and like you said, having those iterative cycles so that you can, you can show it to them, right, early and not wait, and they can go, yeah, that's exactly what I was talking about.
[Kelson] (46:55 - 47:30)
Yeah, back to the sandwich example, it's like, we can get a recipe that you want us to build, and we're not going to be smearing the peanut butter and jelly with our hands, right? We're not, yeah. But at the same time, you know, if you say, hey, I want it to be, I want to have some, some, some sauce where there's like a million different varieties, we're going to need to say, oh, well, look, this is the benefit of this one.
This is the benefit of this variety. These are how they'll taste different in the sandwich, like, which one do you want? That's kind of the role, the clarifying role of the business analyst in the, in the requirement gathering stage, right?
[Calvin] (47:30 - 48:02)
And it's the difference between an agency who takes a full stack approach and a full service approach where, you know, it's not just a developer, it's the entire team. It's the business analyst, it's the developer, it's the DevOps person, it's the CTO or the solutions architect. Difference between that and just, you know, a single developer who may, may just put the search bar at the bottom of the page, or they're going to do whatever you tell them to do.
And, you know, having those other skill sets is really important, especially for a full fledged business application. Right.
[David] (48:03 - 48:47)
Yeah. So the sandwich thing, it's a fun exercise to teach kids the importance of clarity, right? But in reality, you wouldn't hire a professional sandwich maker if they, if they made your sandwich that way, is what we're saying.
Yeah. So, so yeah, there's a certain amount of, of professional knowledge that, that you bring to the table and, and you can help guide those conversations. But, but yeah, ultimately just making sure that the communication is there.
Let's jump into our last big mistake that we talked about. I almost feel like we've already covered it because like you said, these are really interrelated, right? But our last one was just building too much or, you know, just going too far, going all in on the application.
So tell me more about that.
[Calvin] (48:47 - 50:53)
Basically, we're not trying to tell you that to not to build the features you want. What it really comes down to is first build the most important feature. And then only once that's done, move on to the next one.
That's really what it comes down to because building one feature and, and getting that in your hands and then using it and make sure, making sure it works correctly, that will inherently make the next feature easier to build correctly. Building both of them at the same time will increase the likelihood of misinterpretations and, you know, incorrect implementation or bad use, bad UI, bad UX. Because on that first feature, what's probably going to happen is we're going to build a version of it and it's going to be quick because it's just one small feature.
And then you're going to look at it and you're going to give us some feedback about, you know, what needs to change or how it needs to be adjusted. That same feedback that you're giving us for that one feature will automatically to some extent be applied to the next feature. Because now we already know, oh, you like your tables.
You like your, I don't know, your forms to look this way. So when we build the next feature, it's already a given that that's the case. If we build both features, we just spent the full amount of time to build both features.
And so that same feedback, we have to redo that work twice now. Whereas if we just build the first feature, we have to redo it once because you gave us the feedback. But then on the second one, we already know that feedback.
So it's really just the concept of building the minimum viable feature before trying to build the next one and building them in order of priority because that'll automatically solve the problem of trying to build things that you don't know for a fact you need. You know, if you're going to spend this much money to build a custom feature, you might as well pay for the most important one first because it's going to cost the same amount as the least important one. So, you know, if you're, if you're building them out of order, you're going to spend so much more money and your value is going to diminish.
[Kelson] (50:54 - 51:45)
Yeah. Calvin said the feature you think you might need. And I really think that there's a tendency to, to try to build for features based on imagined scenarios that may or may not ever happen.
And that's something we see as a pretty common pitfall here. Another one would be the assumption that more features means it's a better application or more features mean it's a better user experience. And so those are some of the reasons that I think people push to have, you know, as many features as possible.
You know, they're like, oh, my, my competitor has this feature. I need that feature too. Oh, this situation could happen or, or the stakeholders may want visibility into this dataset.
Things like that end up costing a lot of money.
[Calvin] (51:46 - 52:51)
And sometimes you have, there's a feature that you know, you want, like maybe it's a, some sort of user experience feature or something to make things like maybe it makes it a little faster or it makes it look a little better. You know, you want that feature. The question is, is it worth what you're going to pay for it?
So I've seen a lot of different situations where the client throws in a feature, say, oh, and actually, can you adjust the table like this for me? And that like, but what they don't understand is that it's going to take another three hours. Is it really worth that much time, you know, or why don't we wait?
Because really the time that you should add a new feature like that is when you're already using the app and you can tell that it's not working the right way and you need that feature versus imagining how it's going to work and making changes before you even have anything to change. Like you're trying to make changes in advance to the feature that's not even done yet. First, wait for the feature to get done and then make the changes that you know you need.
And that's going to save you a lot of money.
[Kelson] (52:52 - 53:27)
Yeah. And ask yourself, how much time am I actually spending to do this? Like, what is the inconvenience that I'm really experiencing here?
Because there's a tendency for somebody to have a one minute inconvenience and then throw in a ticket and say, hey, we need this feature to be built because, you know, 15, 20 times a month, I have a one minute inconvenience when they don't realize that to fix that, it's going to be 50 hours worth of work. And so we're spending 50 hours worth of time to save you minutes or hours. Right.
And so it just doesn't add up.
[Calvin] (53:28 - 53:30)
And so it'll pay itself off in like 10 years.
[Kelson] (53:30 - 53:43)
Exactly. There's there's certain circumstances where it's just better to do it manually, like just deal with the inconvenience. It's just not it's not worth overengineering in order to save you a little bit of time.
[Calvin] (53:43 - 54:57)
Yeah, makes sense. And to be honest with you, just to transparently, like from the development agency's perspective, like we make so much money if you if you have a spilled out useless features, what we try to do is we try to cut those out for you, because we know that in the long run, you know, you're not you don't have unlimited money, you don't have unlimited resources. And in the long run, we're both going to be better off if we build you an app that you're really happy with for a good value, because an app always has new features that can be added to it.
We're not worried about running out of features to build you like if we just decide to encourage you to build all these useless features, then in a year, you're going to say, hey, I've spent a million dollars on this app, and it doesn't really work well. So let's, you know, I want to stop working with you guys. Whereas if we cut those useless, if we help you cut those features out, then in five years, you'll still be working with us because we've provided value every step of the way.
And there's still never, we're never going to run out of features anyway, to build you. So that's why we take the approach of trying to help you cut out the features that you don't need, because it really is better for both of us. And it does take some experience to know how to do that, because it's just, there's always a tendency, there's such a temptation to add unnecessary features.
[Kelson] (54:57 - 56:00)
Yeah, it's the same thing as, as our push to try to make components of common features that we can put into people's apps in minutes, right? We've got our user authentication, I think it used to take us like 10 hours to do, log in, log out, forgot password, right? And then in the user account, the forgot password, email, what that looks like.
And I'm sure there's things I'm forgetting about how that all the different things that go into user auth, but I think it used to take us about 15 hours. And now we've got it down to like three. And we're not worried about the difference of those hours, right?
Where is the difference of those hours going to go, it's going to go into a feature that provides you with additional value, right? We're instead of working on user authentication, we're going to be working on something that something else, because like Calvin said, there's no end to the features that we can build. And so it's in our best interest to make things faster to be able to use shared components between all of our clients.
And, and really provide the highest quality solution we can.
[Calvin] (56:01 - 56:39)
But it requires the experience to know to number one, like we have the resources to build prebuilt components, you know, because we're an agency, we have a lot of different clients that use them. And number two, the experience to know how to cut features, because it's not as straightforward as it sounds, which is the reason one of the main reasons you choose, you know, a more expensive US based agency, because sure, it's an Indian agency or an Indian developer or any developer, they might, like the same logic applies to them, if they can provide you with more value, it's better for them as well.
It's just that not all of them can, because they don't have the resources or they don't have the experience to do so.
[David] (56:39 - 58:11)
Yeah, or the incentive structure to make that make sense for them. I think something I was thinking about while you guys are talking is I think a lot of us struggle with this problem of trying to put too much into a project, because, you know, our whole life, that's kind of what people ask of us. It's like, hey, I have this idea.
Okay, keep working on it. What else can you think of? What else could you add to that, to make it better, right?
And that's kind of just how we go through our whole life, whether it's school work, even an art project, right? It's like, okay, what could you, how could you keep working on that? And with software, it's kind of counterintuitive that, you know, you kind of want to, you know, brainstorm, think of everything, and then shave it down rather than go, how can we push this even further?
There's like an acronym, KISS, K-I-S-S, that the Navy used. I think they still do. That means keep it simple, stupid, or a nicer version, keep it super simple, right?
And we used to say that all the time on some projects that I worked on where we had to remind ourselves, right? Because sometimes your enthusiasm gets away from you. You want to do a really great job.
You want to build the best possible product or, you know, do the best possible project for your department. And sometimes the best way to do that is just keep it simple, stupid. You don't need to be chasing all these different squirrels.
You need to be focused on this is the objective I have. And if it works this way, it's going to bring me value. It's going to bring an ROI for me.
[Calvin] (58:11 - 59:38)
Like, I think Kelson already touched on this, but basically like the reason people over automate is for an emotional reason that they really like the idea of automating something. I do this myself all the time. I like the idea of automating it because it would be super nice and cool to just have it automated and have a super sleek solution.
And when you're getting into building a custom web app at the beginning, before you really understand what you're getting into, you know, you might not really know why you shouldn't over automate until you realize that the reason you shouldn't over automate is because just to build the bare minimum app that you're going to need is going to be, you know, already a massive undertaking. So if you're over automating upfront, you may not be able to afford the actual app you need. So you want to start first build what you absolutely need and then automate in order of priority.
And I guess what we're trying to do here is hopefully communicate the reality of web development so that you can understand before you even get started, that it's a huge undertaking to build a custom app and it's going to take way longer than you think it's going to take. So you should try to be a little bit more conservative and avoid over building upfront. And that way you can actually get what your business needs out of the app first and then continue to automate.
[David] (59:39 - 59:45)
Awesome. Well, you guys, do you have any final thoughts, Kelson or Calvin, anything you want to stick in here at the end?
[Kelson] (59:46 - 1:00:57)
Yeah, I do. I think that if I was to add a fourth one onto the end, it would probably be to stay away from fixed cost projects. And that's because I think we came up with these three based on the understanding that we're working in an agile methodology.
But as soon as you start working on fixed projects where the developer or agency says it's going to cost this much money to build what you want and this is when we're going to have it done, it really exacerbates all of these issues to the next level. Because what ends up happening is you run out of budget every single time, largely due to these mistakes. Then you're back to the negotiating table and they kind of got you by the neck because what are you going to do?
Are you going to have your app finished or three quarters finished? You don't really have an option out, right? So you end up having to pay more money.
And that's why when we were talking about the incentive structures and stuff like that, that's the reason for that is sometimes it's in people's best interest if they are on a fixed rate project to just burn that spend as quickly as possible without delivering any value because they know that you're not going to leave until the app's done.
[Calvin] (1:00:58 - 1:01:02)
Just remember, a fixed cost is nothing but a down payment on your app.
[David] (1:01:04 - 1:01:09)
Yeah, that's so true. Awesome. Well, thank you guys so much.
Really appreciate you joining me today.