Pragmatic 45: Not Part of the Plan

Welcome to Pragmatic. It's all part of the plan. Pragmatic is a weekly discussion show contemplating the practical application of technology. Exploring the real world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. is as simple as it seems. This episode is sponsored by Harvest. Harvest lets you time your tasks wherever you might be doing them and easily analyze your time sheet to track billable or non-billable hours and turn those into invoices for your clients with both PayPal and Stripe integration. Check out Harvest at getharvest or oneword.com and sign up for a free 30-day trial and start tracking your time and invoicing others simply and painlessly. Once your 30-day trial is up, Use the coupon code 'Pragmatic' at checkout and you'll receive up to 50% off your first month. But hurry, because this offer expires on the 15th of January 2015. This episode is also sponsored by Mandrill. Mandrill is a transactional email service that easily ties into your website and apps when you need to send one-off emails like responses, password resets, acknowledgments and so on. Visit mandrill.com and sign up today. Why not? it's free and use the promo code pragmatic to get 50,000 free email transactions per month for six months. Normally there's only 12,000 a month, that's four times the normal amount. Integrate, deliver, track and analyze using email infrastructure from Mandrel. We'll talk more about them during the show. I'm your host John Tidgey and I'm joined today by my guest host Seth Clifford. How you doing Seth? I'm doing well John, thanks for having me back. Oh no worries, thank you for coming back. Before we dive into today's topic, I just want to quickly do a little bit of pre-show blurb. It's now possible to see the list of topics I'll be covering on the show in coming weeks and months at techdistortion.com/topics. If you're not a member, you will be able to see the list, but if you sign up, you'll be able to vote on the existing list and also suggest whatever topic you'd like covered on the show. I'll be locking in episodes a week or two ahead of time and people can see the topic and co-host or guest host ahead of time so they can tune in and know what to to expect. Go check them out. I've also started releasing an equivalent to the After Dark/After Show/B-Side thingies, whatever you want to call them. I'm calling it Adenda. It's at techdistortion.com/podcasts/adenda. So go check it out. It's also on iTunes. You can always search for it in there as well. And finally, if you're enjoying the show and you haven't yet rated in iTunes, feel free to do so. Always appreciate it. Always very much much appreciated. I've also changed servers recently and put a new VPS up that's now located in San Francisco so it should be a little bit zippier than before and it'll clean out all the cruft and it's all nice and squeaky. Brand spanking virtually new because it's virtual. Anyway, there you go. That wasn't very funny. Never mind that. Okay, so this This is a bit of an interesting topic that you want to talk about, Seth, and it has to do a lot with how design is, shall we say, I'd like to say guided, but it's not so much guided. It's more a little bit bullied and a little bit shoved around by different interests, shall we say, like, well, there's marketing and advertising and obviously the customer as well, but I thought it might be interesting to sort of look at how we focus when we're being pushed around by all the different competing demands when we're trying to deliver something. What do you reckon? Yeah, I think there's probably plenty to talk about there. It's one of those things that we had kind of chatted about prior to the show, you know, several weeks back. And I think it's the kind of thing that depending on where you work and with whom you work, you either have a great handle on this or you struggle with it or you're constantly battling it. And there's a very, there's a tough line you need to draw as a person working in a creative field when other people are actually paying you directly for it, but also influencing your creativity. And you have to kind of compartmentalize how you feel about that to perform at your highest level. So I think there's probably a lot of interesting directions we can go with. Okay, well I think where I'd like to start is I'd like to start by thinking about how we divide this up. So when you're developing a product and I guess the design is for either, we could classify it as either for a single individual or an entity. And when I say like an entity, it's like a truly, honestly, single point of authority. So I guess that's sort of the way I differentiate because you can still develop something for an entity that has one overriding voice. Whereas you can also have an organizational customer such that you have five, six, seven, eight different people that you're trying to satisfy. So I think there's a bit of a difference between like sole customers and organizational customer sort of affects a little bit about how you go about pleasing who you please. Sort of just might help in sort of breaking this down a little bit. Also I think it's worthwhile breaking down the design being for internal or external organizations and I may sound a little bit you know douchey but I mean honestly if you're developing something in-house for your own internal needs you know which you know we've both sort of done but a lot of the work that we've done predominantly has been for external organizations and when you're doing things in-house, you can sort of bend rules and change the way you can change your direction a lot more with a lot more agility and a little bit more free will there. Whereas if you've got an external customer, it's a very different story, it becomes more of a negotiation. So I think that's worthy of breaking down as well. I don't know, I guess you could break it down further in terms of if there's money involved, but that's probably beyond the scope of this really. So, okay, I'm thinking about a matrix like a quadrant. I don't mean like a matrix where you plug a thing in the back of your head. I mean like a 2x2 matrix whereby you can look at elements of a design as being in terms of their implementation as being straightforward or complex. And I realize that that's a simplification, but I mean, let's just say that there's something that some other party wants. It doesn't matter if it's the customer or if it's someone who wants something from a marketing perspective and say, "Oh, this would be a really marketable feature. We got to have this." Irrespective of what kind of feature it is, it could be either straightforward or it could be complex. I guess my point is that that would be one axis. On the other axis of the matrix, we could say, "Well, something could be a completely independent feature." In other words, it doesn't affect any of the other features in any way. It's very, very isolated. It has its own little, it can build in its own little style. It doesn't affect anything else. Or it could be very interdependent such that if we add this feature, it's going to affect one or more other features of this product. So if you think of it like a matrix, this is the way I want to sort of try and tease this out a bit, is the four quadrants of that matrix kind of do the whole straightforward and independent, which is totally easy. Someone says to you, hey, you know, we want to add this. It's really straightforward feature and it's completely not gonna affect the rest of the product. It's like, you know, snap your fingers. Yep, okay, no problem, that's easy. But when things get a little bit more complicated when you say, okay, well, maybe a straightforward feature but now it's interdependent. So in that second quadrant, it's like, okay, well, now we need to consider all of the different interdependencies. We don't wanna affect like, yes, okay, the customers, the marketing guys say it's gotta be blue 'cause blue is pleasing to the eye. Who was the company that did all the studies about the different shades of blue? Was that Microsoft or Google? Someone did. - Oh, I don't even remember. I think it's one of those two. - Yeah, I think it was. And they came up with blue being the most pleasing color and therefore it was a predominant background color in one of their wallpapers or something, but anyway. So there's that. And then there's the complex and independent in that third quadrant where you got something that problem is very, it's complicated to implement, might take a fair bit of time. And that comes back to cost, schedule, prioritization. And you could put a person to hack away at that for a long time and see what they get as a result. But because it's independent, they can sort of do that on their own. And that's that. And then finally, the fourth quadrant where everyone is angry. And that is if it's complicated and it has a lot of interdependencies. And it's like, OK, now what do I do? And usually those are the ones we end up having to say no, because it's like, well, you know, we've got a fixed budget, we've got a fixed amount of time. It's too complicated and there's too many dependencies. I'm sorry, but we just can't accommodate that. Oh, I don't know. What do you think? I think that's as good a place to start as any. I think that probably encapsulates most of the kinds of decisions we're talking about. All right, cool. I guess the thing is the easiest position you can take as a design lead is to say, "I'm going to take the uncompromising position." I'm going to say, "You know what? If as lead designer, I don't want it or it's not in the contract, it's not happening." Now that's the easy way anyone can say, you know, it's not in the contract I don't care, you know, but the problem with that if you want to take that path You just you're not gonna have very many happy customers. You just not you're not gonna get repeat business You're not gonna get a good reputation. Yeah, and it's easy, but it's not It's it's easy for you on paper, but it becomes less easy for you sustain, you know to sustain that kind of behavior going forward Yeah, exactly. And it'll hurt you in the long term. So, the reality is I've worked with organizations like that and there are some aspects of the organization that I may or may not currently be involved with that'll have some of those aspects in common, in certain areas only. But yeah, it's frustrating as hell because you realize that, you know, no one's doing themselves favors by taking an uncompromising attitude like that. So, not recommending that for a second. But I guess the thing is, I also, I see the flip side of that. And the flip side is, I want you to develop a product for me. And I have to give you an idea of what I want. But I can't design it all and think it through all up front. I can't put every single requirement down on a piece of paper such that we have a complete map from start to finish of everything that I want you to create for me. for me because it's only happening in your head and you're limited by your own head. You're limited by the space in your brain. There's only so much you can think through and therefore there's only so much you can write down at the time of writing a contract and say, "Well, here's kind of what we want. This is what we want as an end result," sort of. But I can't tell you all of the little details and this is when things get tricky because in that uncompromising position, you know, you can sort of say, well, you know, this is a gray area now. It's like, well, you said you're going to give us, I don't know, messaging or something as part of the feature set in the app. And what we'll know that wasn't, it didn't explicitly say that it was or wasn't in. So I'm going to count that as scope creep and I'm not going to help you. So I guess the point is that you need to be able to tweak the design a little bit in some small ways as you go along and whether or not you... you know what I mean when I say scope creep? Yeah, I'm familiar with scope creep. I actually think that I did pick that up in North America because I worked in North America for a while and there's my buzzword bingo. But the point is, yes, I think scope creep is one of those things that's a bit misunderstood. So rather than me jabber on about it, how would you describe scope creep? Scope creep is this phenomenon that occurs when you may, you know, let's assume you have business requirements for the thing that you're trying to build. And the business requirements encompass, you know, these five areas. But the five areas may not be as well defined as they probably should be. Or there might be aspects to elements of those areas that aren't as well defined as they should be. building the product, you know, let's say for argument's sake, let's say it's the contact page on a website. And in the first meeting you say, "Well, what do you want on this page?" And they say, "We just need people to get in touch with us." And you say, "Okay, well then we're going to -- this will be a static page and we'll put up some information and people will see, you know, an email contact and a phone number and your address and that's And everybody goes, "Okay, great." And we move on to the next thing. And you build that page and you start doing other things and somewhere down the line, the client looks at it and goes, "We were kind of thinking that maybe we should have Google Map integration." And you're like, "Okay, so how important is that to you?" And they say, "Well, it's pretty important just because our office is really hard to find." and you go, "Okay, well, we think we have time in the schedule for that," or you say, "Well, we absolutely don't have time in the schedule for that," but if you say you think you do, then you either... The smart thing to do is say, "Okay, we're adding this. We need to reevaluate how this impacts the other stuff that we've already, you know, committed to," but you add it and everybody's happy, and you go, "Okay, we, you know, we accommodated them. They're happy. That's not such a big deal." And then a week later, somebody goes, you know, we had another meeting about this. And what we would actually like is this proprietary kind of Street View thing. We actually have a partnership with a company that does this kind of thing with Street View. But I think they have an API. And you're like, OK, well, now we're talking about far more than the static content we had initially agreed on and more than the Google Maps integration that we talked about last week, and it just becomes this kind of thing where people keep meeting and talking and what they actually thought they wanted may be there, but it's not quite what's the topic of discussion that week, and so you end up taking a static HTML page that was supposed to be text and putting all these kinds of things in it. And that's like a super stupidly simple example, but it's the kind of thing that starts out simple and continues to balloon. In a lot of cases you have a really complex feature that is very well documented and somebody says, "It would really be great if it did this one other thing." And you're like, "Well, it would be great but unfortunately that one other thing means two more weeks of engineering and another week of QA." And you know, it could be anything that's added to the project along the way that swells both the overhead involved in project management development, design, QA, and then finally, you know, how long it takes to deliver that feature. And it happens all the time and it's one of the toughest things to deal with in a client service industry because you want them to be happy and you want to please them. But to do your best work you need to be very mindful of when that is happening and you need to be very forthright in describing what's happening to them and letting them understand that we recognize what you're doing, we hear what you're saying, we want this to be a thing that you can have, but you can't have it now. We can phase it in later, we can talk about when it is an appropriate time to add this. Or if you really must have this, then we're going to compromise and find something else in the project that isn't as important now that we can drop and use the time for that. So it's that kind of scenario that we usually face. Okay, cool. So when... And I have had similar experiences in different contexts as well, and I think that's a pretty good definition of scope creep. I guess the way I would say it is scope creep is new functionality beyond the original scope such that if it was omitted, as in not implemented, then the product would still meet the original design intention. And so if it falls inside that category, that you can consider that to be scope creep. And I guess when you, this is more of a more curious question than anything else, is when you do quote, when you quote for a job or factor your rates, Do you include an allowance for, I hate to say scope creep in that context, but miscellaneous general and say, well, you know what, we can handle maybe a week or two of additional tweaking here and there as a buffer. And then once that's gone, it's gone. And because I have to admit, I'll put my hand up and say, I've actually have done that on some fixed price quotes. I've actually gone and said, you know what, I've got a buffer here of X number of weeks of engineering hours to account for, like for example, if I've got a vague spec that I'm quoting to, I will put in a lot more time because I know that there's gonna be creep beyond what is in the spec. Is that something that you have come across? - Generally speaking, we try to plan as accurately as possible. We don't really buffer things like that because we've gotten to a point, thankfully, where we are very, very tuned in to the, the conversations up front and getting the documentation that we need and nailing everything down. And so we plan specifically to the features that need to be built. And certainly sometimes things take longer, and that's, that's a different issue. But we don't really like add time in that way, because we do a lot more upfront research on what we think it will take to do this feature, that feature, this other feature, and then also to test those things and make sure that they're all functioning properly so that we can have those conversations later and say, we are on time, we're on schedule. These are things that we've agreed to build. We want to accommodate you, but we either need to move things around in the schedule or we need to push the date, or we need to do, you know, like you have those levers that you can push with clients and say, if you've got a date that's immovable, then we need to have a conversation about, you know, what is important and what isn't important to ship by that date. If your date is flexible, then we can have another discussion about adding other things in. But I think it's important, I think it's important to not have too much of that wiggle room because it forces you to be extremely focused on what needs to get done and in what timeframe. And as you do this more, you learn to have those conversations earlier with clients and you learn to be as clear in your language as possible because when you don't adequately describe to them how this is affecting the overall product and project, then they're not gonna understand it. Like that's for you to explain to them. So I think a lot of people do build in that kind of time just to allot for that. And there's nothing wrong with that. It's not, it's, I wouldn't label that as like, you know, some kind of weird nefarious behavior because you understand what is being asked of you. And if your business requirements are flexing or they don't know what they want, you may just have a conversation with them and say, "Look, I'm gonna say it's gonna take this much time "because we don't know what you guys want yet." I think that's perfectly acceptable too, but it's all part of having those conversations early and in clear language so everybody's on the same page. One of the other approaches that they take in my specific line of work is they will do a… well, sometimes people will refer to as a budget price. So they'll have a very brief framework of a specification and it'll go out to market and they'll say, you know, you come back with a budget quote and the budget quote will have a very wide percentage on it. So it'd be like, you know, plus or minus 35, plus or minus, you know, 20%, whatever. And you put in that value with a median expected value and, you know, a positive, like an over under on it. And, you know, then they'll do a shortlist from there, develop the design a little bit further, and then go back and say, right now we want your fixed price quote. I mean, that's fixed price quoting and in engineering, like in construction industry, which is a very different industry from developing software. But even so, I think, as you say, I think it is a valid approach to do that, but you have to be very careful that you don't look like you're putting in way, way too much buffer. Otherwise, first of all, you won't be competitive. And second of all, if they ever see the cost breakdown, 'cause half the time they want to see a cost breakdown of your hours, even if it's in part, is it's difficult to hide that. And a lot of customers will come back and say, well, hang on a minute. What's this big miscellaneous thing for ten million dollars? I don't I don't agree with that. So, you know, but then, of course, then you're up against the battle of, well, do you break down your costs or do you not? And, you know, I've I've had different managers who have said, well, you know, you should if they ask for it, then we should. And other ones have said flat out, no, they get one price. We don't break down our prices. We don't care. and if you're hungry for the work and you're up and competing against others, we'll break it down and you'll be breaking it down whether you want to or not. Anyway, yes. So I guess rather than go on too much more about that, I'll just actually very quickly talk about our first sponsor before we get into the next section, and that's Harvest. Now, many people listening to this show spend their time working on home projects and work projects, too, and you lose track of time. We've talked about this on the show previously, about being realistic, about how much time you have available to you. Now, one way you can track your time is by using Harvest. And they have a simple to use web app where you can create tasks. They also have mobile apps for both Android and iOS. It's easy to select the task or an activity, start and stop a timer from any of them. On the Mac, it installs as a neat menu bar icon that detects when you've been idle for a long time. When you come back, you can then choose to deduct those idle minutes or hours from the total. Yeah, it's little touches like that. Very cool. Anyway, it's a great way to track where your time is going. And after you're done, it's really easy to look back at your time sheet to see where the time's gone. That's handy enough, but if you're working on a project with a team, your coworkers can track their time, and it makes it really easy to manage everyone's time on a project as well. So Harvest also makes invoicing easy. And it's quick and painless to set up clients and multiple points of contact those clients if you have that, and build invoices using that information. Very, very quick once you've built once you've set it all up. Better than that, Harvest lets you pull your hourly rates and your time sheets to create those invoices based on those rates, integrates nicely with PayPal and Stripe. Now I've been using Harvest invoices for the podcast recently, and it's now taken over as my invoicing system of choice. I think it's really nice. Check out Harvest at getharvestalloneword.com and sign up for a free 30-day trial and start tracking your time and invoicing others simply and painlessly. There's no credit card required, no obligation. They just want you to see how great and how handy it can be. There's no excuse not to give them a try. Now, once your 30-day trial is over and you've realized how great Harvest is, use the coupon code "Pragmatic" at the checkout and you'll also save 50% off your first month and that applies to any of their plans. Hurry though because this offer expires on January the 15th, 2015. Thank you once again to Harvest for sponsoring Pragmatic. Okay, so where were we? I was thinking about... Okay, so I want to talk a little bit about the difference between marketable features and core features. And I guess the reason I think this is important is that... I don't know. I get the feeling a lot of people don't appreciate enough of the difference and some people look at it as an either/or and it really isn't. It's simply two different sets and the sets can overlap and that's perfectly fine. So the way I see it is and I'd like to hear your take as well, but my take is a core features you have to have otherwise you just do not have a product that you can sell or hand over. Whereas marketable features, you know, marketable features essentially are designed more to drive sales and they sound great, but they don't necessarily have to be core features. And the issue comes, ideally you want to develop where they overlap. You want to develop the marketable features that are also core features, because if you're spending time working on too many core features that are not obviously marketable or don't appear to add much value to the product, then it becomes less, less, well, less marketable. You're spending your time on that solid foundation stuff. And that's a dangerous game to play in some respects because if you start saying, well, I'm gonna whittle away my core functions 'cause they're not marketable, well, at the same time, you gotta balance that with, I've gotta have my core functionality, otherwise it will not be saleable at all. So it's really more the other side of that where the, not the overlap, not the core features, but the marketable stuff that's just there for marketable reasons, for marketing reasons and sales purposes, and it's not really a core feature, it's not really a huge deal, or it only addresses a very small subset of potential users, spending a lot of time and effort on those is perhaps, I would suggest, not ideal. What are your thoughts? - I would agree with that. I think that probably when determining what's a core feature and what's a marketable feature, it comes down to what the initial idea is. Like what are we setting out to build? Is it the kind of thing that only a subset of a subset of a specific demographic would be interested in? Well, then maybe we shouldn't even be building it because the effort that we're gonna be putting into it isn't probably worth even marketing to this smaller population. But in more specific terms of how do you balance those things, yeah, sometimes marketable features are your core features. And I think when you have that scenario where your core features are the most appealing to the people that you want to have using your product, that's the optimal scenario because you can spend all of your time building the things that people are going to love about it and the things that you're going to want to talk about. But regular people, consumers, even just users in an enterprise setting don't really care, most of them don't really care about the engine that drives the product that they're using. So your core features, if you have a giant backend that needs to serve all this data and do all this stuff, it's one of those things where you're never gonna be able to really talk about that. So you have to understand what that product does and potentially reframe what it's doing to provide value to the people that you're trying to reach. And you may not have marketable features, but you need to create a marketable message so that people understand the value of what you're trying to bring to them. And that I think comes down to, again, the initial idea, plus the people that are charged with understanding the product and delivering that message. A lot of times, the people who are building something are all very kind of heads down. And you may have a lot of engineers, a lot of developers, and project managers, and people like that. But nobody's really thinking about what the end goal is. They're just trying to deliver a set of code on time. And that's fine, and that's very noble, because that's how business is done. But that still needs to exist after that delivery date. And if that product doesn't thrive, then you have to wonder why it was even undertaken in the first place. So there is a balance to be struck, but I think it really has a lot more to do with understanding the core of, to reuse that term, the core of what you're building, and then not even building features to appeal to people, but building a story to appeal to people, because you can take a really boring product and have it appeal to people if you show them and you demonstrate the value. Absolutely, that's a good point. One of the things that I also found as a difference between a product that is, and I guess this is the problem, I don't want to say successful versus not successful because that's not, that really is quite a simplification and not really the point of what I'm getting at. It's more a product that is efficiently created from, from inception to delivery. And those are the products that are focused. And I know that I think, you know, we may have talked about this previously or I have on the show, but the, and focus is, it's very, very important because what I've come across on products that tend to fracture a bit and they tend to develop too many of these features that are called marketable features that aren't core features and stuff. People just, someone in the group, in the team has a great idea. And they're like, you know, this would be great if we did this. And rather than spending a week working on the core features that they absolutely have to have or on core features that are also marketable features that the product should have and satisfying all of the customer's requirements but they'll go off on a tangent and they'll develop this one section. They'll say, you know what? This is one feature, this is fantastic. It'll become their pet feature. And as a project manager or design lead That's your worst nightmare. Because it's like all of that creative energy and all of that talent is being directed towards something that either was not sanctioned or not fully sanctioned or not required or not part of the plan. And I found that to be endlessly frustrating. And it's like I thought to myself for the longest time, well, you know, Is that a failing of minors in the project management role? Am I simply not, you know, how do you manage that? How do you balance that? Because you don't want to put your foot on the back of their neck and say, you will only develop this. There is no room for any of your personality, any of your desires, wishes, wants, any of that stuff. You know, you're a machine, churn out code and stop complaining. I guess if you're a professional and the longer you do it, maybe that's more the case. But at the same time, I've met a lot of, I guess maybe that's my problem is I've worked with a lot of younger programmers that simply don't respond to that. And they're in it because they enjoy it. And if they don't have some degree of artistic flexibility and say, "Oh, I really wanted to add this or this little thing, and it's a great idea. And I'm sure the customer would like it. And I swear it'll only take a few hours." Yeah, sure. But anyway, is that just me or have you come across that? No, that's, it's not just you. Usually in what we do, we see it coming more from the client, right? So you've got a project that you're working on for, you know, a large corporation and you have your key stakeholders who all have a different idea of what this thing is supposed to be or do, and there's usually one person who has a little bit more pull than the other people, and so that person's desires kind of bubble up a little bit more. And a lot of times, what you've committed to build and the idea that you've presented and what that person wants are not fundamentally opposed but they're on diverging paths. And you need to kind of delicately and professionally bring those two paths together to converge again so that you can still deliver the product that you want to build, but also satisfy that person's need to have their idea validated. And the trick is, what you were saying is more an internal thing, like the young developer who wants his amazing code gymnastics to shine through in the product, there's always going to be that kind of thing that you need to contend with. I think that that's a very different kind of condition where as a manager, you need to understand what that person, I mean, it's all psychological, right? In both cases, it's understanding the psychology of the decisions being made and reacting to them in a way that is favorable for everybody involved. So the business lead at the company wants his idea in there so that he can trumpet it later and everybody pats him on the back and says, "What a great idea." the young developer wants to show off just what a great developer he or she is. And they both need to be handled delicately because you want the client to be happy and you want your developer to be happy and productive, but you need to understand the point from which they're coming and why they're saying the things they're saying, why they're doing the things they're doing. So in the case of the young developer, you need to kind of convince them that they can apply those same methods and that same kind of thought process to a part of the project that actually is important and needs to be built to the detail that they're thinking about it. And for the business person, you need to show them that, hey, we hear your idea and we love it And this is how we envision it being a part of the product. And it's just kind of, you have to kind of just guide them back to where you need them to be. And that's a very tough skill to learn because as a project manager, as somebody who's kind of driving a project, you want everybody to be happy, but your bottom line is that you need to deliver on time and on budget. So there's all these kind of tangents that you need to manage. And it's tough. and you really need to be, you need to be flexible because sometimes things do need to change, but you also need to be as rigid as you can be because everybody needs to understand that we're all working to get to this point in the future. And if we're constantly injecting our personal feelings into this product, as opposed to what the business has required, we're never gonna get there. And there's gonna be gaps, and there's gonna be parts that maybe look great but don't even work at all. - Yeah, and I think you nailed it right there. It's about limiting how much personality gets between the programmer and the job that they've got to do. And I guess one of the great things about having complete control over what you're doing, like if you're developing your own product, is that you short circuit that because you can decide, you can make those decisions yourself as to, "Okay, yeah, well, we really want this, we really want, I really want this, I really want that, so I'm gonna adjust my own priorities." The funny thing is, of course, that's probably not a good reason to do it if you really wanna be really self-critical and honest and fair about it. And I think you should probably, if you're running your own projects, you should run them as though you were trying to convince other developers on your team as to why you should be adding certain features. So I think that that's a worthwhile exercise because you should be justifying to yourself why on earth you want to spend three days working on making a button look just right when that doesn't make a heck of a lot of economic sense, let's say. But anyway, rather than get into that, I guess one of the situations I came across with a younger programmer who was trying to sort of flex their programming skills, and I'm not sure if I've ever mentioned this one before, but the story goes that we were doing a SCADA package for a sewage treatment plant. I've done quite a few of those. In sewage treatment plant, there's a thing called an oxidation ditch. The oxidation ditch has aeration. The aeration essentially forces oxygen into the bottom of the tank through fine bubble diffusers. As those bubbles travel up through the tank, they get dissolved in the water. Not all of them, of course, but just some of them. That raises the dissolved oxygen. The dissolved oxygen feeds the bacteria, the bacteria convert the organic matter, shall we say, into a sludge that then sinks to the bottom. And that's then pumped out and treated further. Anyway, rather than tell you how sewage treatment plants work, the point is that the SCADA system had to indicate that aeration was functioning. So, this rather industrious young engineer thought they would do some beautiful code gymnastics, as she called them, which I think is a nice way of putting it, and make them world's most perfect Skada bubbles you have ever seen. And these things were absolutely beautiful to behold, because what they did is they followed a random track between set limits and you could programmatically set the limits so that in the in the X direction, the bubble would weave its way from the bottom of the tank to the top as it did so, just as it does in real life, because the pressure of the water changes the diameter of the bubble. So as the bubble start at the bottom, they're smaller. By the time they reach the top, when there's less water pressure on top, the bubbles are much larger. So, yes, the bubbles actually increased proportionally in size as it traveled up the screen to mimic exactly the way bubbles would work in a real oxidation ditch. And finally, just as a little touch to show how extra clever he was, when you turned on the actual aeration system, the tank would have no bubbles in it. But as you turned it on, a wave of bubbles would start at the bottom and they would make their way up to the top and fill the tank as a continuous stream. When you turned off the aeration, the bubbles would stop at the bottom, but they would continue to float. The ones that were on the screen would continue to float to the top of the screen, to the top of the tank and then dissipate. It was it was beautiful, I will admit it was beautiful. It took him a week to program that. So 40, call it 40 hours of programming. Now, we didn't have 40 hours of programming to waste making bubbles, you know, right. So as an object lesson, this is not me beating my chest saying, "Oh, geez, I'm so clever." But it's like I spent, I think, 30 minutes, maybe an hour tops, doing my take on it with probably one tenth of the lines of code. No, they weren't really random tracks. They were pseudo random. No, they were not adjustable. And no, they didn't actually dissipate once you turned off the oxidation. But you know what? To the untrained eye that didn't know what they were looking at, they still look pretty well the same. And it took me, you know, a ridiculously small fraction of the amount of time that it took this guy. And the difference was I wasn't focusing on mimicking exactly the way it is in real life. 'Cause I mean, if I really wanted to be really nitpicky about it, I could have said, well, he didn't, he didn't mimic the turbulence that's caused 'cause all those bubbles cause turbulence on the surface. There was no turbulence in the graphic. I mean, I could be really, really nitpicky about that, but the point of the illustration is that was time that was wasted on a feature that no one asked for, no one really needed and yes, it looked beautiful to the trained eye, but to the untrained eye, no one cared. So, and that's what happens when you take a week off, folks. Because when you come back to work and you realize, "What, have you been doing for a week? Oh, really?" Sorry, that's just one of my horror stories. I don't know if you've got any horror stories, but that's one of mine. I'm sure I've got plenty, but we've only got a limited time that we can talk today. Okay, fair enough. Well then, and on that note, let's talk about our second sponsor for this episode, and that is Mandrill. Now, Mandrill is a scalable, reliable, and secure email infrastructure service trusted by more than 300,000 customers worldwide. Now I've been asked what is Mandrill because most people understand email newsletters showing up in their inbox and a lot of them come from MailChimp. So what's Mandrill? Well Mandrill is essentially the foundation of MailChimp is built on and it's been broken out into its own service for discrete emails rather than a big mailing list. So think of them like transactions hence why I call it transactional email. And that's actually how it started though. In the two years leading up to 2012, Mandrill borrowed a bunch of MailChimp's best engineers, they promised to give them back at some point, and working in isolation, their Skunkworks project turned into Mandrill, which is now the largest email as a service platform on the market with more than 300,000 active customers, of which I am one. So let's say you run a site like Tech Distortion, for example, and you need to send feedback form confirmation emails, Mandrill can do that. Distortion uses StaticMeg as its CMS and runs RavenForms as a plugin. You just add the API key for Mandrel and that's it. It just works straight away. There's a bunch of new features on the site with voting and everything and that's all used as Mandrel as the email carrier for that. I had been using standard PHP mailer but since I switched to Mandrel it's been much easier to track and debug and frankly it performs better anyway. You can use Mandrel to send automated one-to-one emails like password resets, welcome messages, confirmations, customized newsletters if you want to. Mandrill is quick and easy to set up and it's very stable. It's been made for developers by developers with extensive documentation, lots of different integration possibilities through their excellent API and the service has very high delivery rates, webhooks, analytics, they've got it all. Now, Mandrill's website has a well-organized interface. It has flexible templates, custom tagging, and advanced tracking and reporting. It's also the only email infrastructure service with a mobile app that lets you monitor delivery and troubleshoot from wherever you might be when you're out and about. So Mandrill is also very fast. It's got servers like distributed all around the world and they can deliver your email in milliseconds. And I tied on tech distortion from form submission, the email shows up within a second of submission. It's that quick. Detailed delivery reports, advanced analytics, a nice friendly interface means that if you're If you're in a larger organization, the entire team from development to marketing can monitor and evaluate the email performance easily without having to hassle you as a developer and that helps. So, visit mandril.com and sign up today and you should because it's free. No credit card, no commitment, just sign up and use the promo code pragmatic to get 50,000 free email transactions per month for the first six months. four times the normal amount you normally get. Integrate, deliver, track and analyze with email infrastructure from Mandrill. Thank you once again to Mandrill for sponsoring Pragmatic. Okay, so I think that the bottom line and just something briefly, you mentioned stakeholders before. Every time someone mentions stakeholders, I just wish someone would do like a Gary Larson (laughs) like a single frame where you've got four business guys in ties, holding plates with stakes on them and say the key stakeholders were in attendance. I can't draw. If I could draw, I would do it. Yeah. It's one of those phrases. And I don't know, being on this show with you seems to bring out like enterprise speak, business mouth. Oh, sorry. No, it's okay. It's just cause we've been in those scenarios so long. They're just, they're in there. They don't come up in casual conversation, but in the context of a discussion like this, they just kind of bubble up. Yeah, that's it. It's hard to avoid. I guess the problem with those sorts of business euphemisms is that once they enter conversational speech in a business environment, when you're talking about business, you can't help but have them creep in as well. And the other thing is that, you know, a lot of these expressions have a good solid basis. They didn't start out being, you know, really annoying cliched phrases, they started actually being a good phrase with a good purpose. It's just that because people overuse them and use them in the wrong context, then that sort of watered down their usefulness. And then suddenly it becomes, the key stakeholder paradigm is shifting through cross-pollination or something. I was like, Oh God, really? I still have never heard parking lot though. You haven't heard parking lot? No. I've never come across that. When Casey said that one, I was laughing because I can picture it being used in a meeting over and over and over again But yeah, I don't think I've ever heard somebody use that Maybe it's a regional thing, but I guess if you've heard it, I guess not No, well, no, I mean, I haven't heard it in Australia, but I've heard it in North America when I was in Calgary, Ottawa I mean, I don't think it was a Nortel thing I always figured it was a... I figured it was a North American thing Maybe it's a different regions in North America say it But yeah, the two were rat hole and parking lot. Rat hole, sure. That's an easy one to come across. Oh, sure. And yeah, but again, that's something that you don't hear in Australia. That's definitely North American meeting expression. So you'll be in the meeting and someone will go off topic and say, no, rat hole. First time I heard that, I'm sitting in the meeting going, is it a what hole? Who's a what? Huh? Had no idea what in hell that meant. And then when someone said parking lot, I go, we'll just throw that in the parking lot. And I kid you not, the first time I heard the expression, I looked out the window. What? Yeah, looking to find a car park. - How about, I don't wanna get too off topic, but how about let's table this? Have you heard that? - Yes, oh God, yes. - Okay, 'cause that I think is what we hear where we are more than parking lot. It's, you know what, this is great, let's table that for later. Which I don't understand, let's table it? We'll build a table out of it? I don't know. I guess it's just push it to the side or something. We'll put an idea on the table, but doesn't that mean you're going to talk about it? So, to me, yeah, I found that expression to be counterintuitive as well, actually, because it sounds like if you're- Because if you're tabling emotion, doesn't that mean you're suggesting emotion to be discussed? I thought I would have thought. I have no idea, but we could probably have a whole show about that. God, do we have to? Please, no. They'll come for our heads if we do that. Okay. So, yes. So, yeah, go stakeholders. Yay. Anyway. Ultimately, though. Okay. So, I just want to circle back and I guess maybe then we should probably wrap up. But honestly, it comes back to identifying the solid core features and not being pulled too far astray by too many marketing, solely marketing based features. and I think that that's the key, identifying those and staying focused and that's the difficult bit because bottom line is time is always against you. No matter how you want to think about it, people will say, "Oh, well, it doesn't really - " some products can drag on especially if it's something that you're developing yourself for your own purposes. But the truth is that if you really are objective about it, time is always going to be against you because it's a competitive market. You're not the only smart cookie out there. You're not the only company out there. If you don't produce something quickly enough, someone else can and will inevitably beat you to it. Especially when you're developing on platforms, platforms become more popular. Back in the early days of iOS and the App Store, for example, there was much less competition whereas now there's so many people developing for the platform, the platform's enormous, it's very, very competitive. You've got to use your time wisely and you can't just throw it away on a feature that It sounds like it would be good for marketing purposes, but it's really not a core function. You just can't afford to be sidetracked for any real significant period of time on stuff that is not going to get you to the end of your contract, to the end deliverable, to where you're trying to get to. I think that too many people lose sight of that and they're like, "It'd be so great if we could do this or that." Yeah, but that takes time and time is money. If time wasn't money, time is still a problem. Time is always against you. - Yeah, that time is the one resource I can't get more of. And that is the thing that basically drives me in all my decision-making is, how long is it going to take me to do these things? Should I do them? Is it worth doing? Not even in terms of projects, just in terms of life. Like that's one of the things that kind of guides my thought process in every aspect of what I'm doing. And you know, you attribute value to certain things, and certainly in business, there are things that have a very, you know, a very perceivable value. But yeah, like you said, even if time wasn't money, time means you're not doing other things. There are other things you could be doing that you're not doing because you're doing this. And so ultimately, you need to weigh out what that time should be allocated toward. - Yeah, it's an interesting way that you express that is that time is the one thing that you can't get more of. And it got me thinking that's true because you can go back to a customer with a variation and say, "Hey, you wanna add this extra functionality, that's a variation, it's gonna be an extra this amount of dollars." And usually if it's something I really want and there's scope for that on their side of the budgetary fence, then you can get that budget far more easily than you can say, "Oh, I need another few more weeks." Yeah. Watch their head explode when you say I need another month. Yeah, yeah. Their customer will come back if you say that. So it's a good point. So I guess if I had to summarize on a set of points and I guess the first thing and maybe this is obvious, but I think you need to be very clear exactly who your customer is because so many people come to you from within the organization, from within the customer's organization, asking for different features, core features, marketable features, doesn't matter. You know, essentially pushing the design and directions, you know, that it perhaps shouldn't go, driving that scope creep. You know, you have to be clear who your customer actually is so that you can identify which ones, frankly, that you can ignore. And I think you need to be very clear in your feature classification. So when something comes in, you classify those. OK, well, that's definitely a core feature. We absolutely must have that. If you are clear up front, you know decisively which ones to focus on, that's huge. I also think you need to be honest about how much effort is going to be required to implement a feature. And I've talked about this on previous episodes. The bottom line is there's the ability to predict how long something is going to take. And there's the emotional aspect of being optimistic versus being realistic. And that is something that is a learned skill. and it's very hard to, you know, it's easy for me to say, but it's hard as a skill to learn. But being honest means trying to take as much of the emotion out of it, a match of the optimism out of it. Look at past history, you know, track your history, track how long it takes you to develop things, to design things and use that as your basis for your prediction and take the emotion out of it and be as honest as you can. And when it comes to those fourth quadrant activities, the ones where I'm, those, my fourth quadrant thing, I talked about earlier whereby it's a complex feature and it's got a lot of interdependencies. Be brutal in saying no to those fourth quadrant activities because if you are not brutal, you will never get there because inevitably you'll just chew up more and more time and you will just never deliver. Do you have any that you would add to that? - No, I think that summarizes it pretty well. It's tough because when you're when you're not building something for yourself, there's an innate desire I think in most people to want to please the the people for whom you're building and That that comes very often in direct conflict with what they're asking you to do So it's yeah, it's really It's a it's a really it's a balance that needs to be struck between Being very aware of what's being required of you, you know You have one one one part of that you have one part of I want to do a good job I want this to be successful You have another part that is I know these people are gonna just keep adding things or keep changing things And I need to put my foot down and say hey if you want it for this price by this date It's got to be this and you can't keep you know you can't keep changing things and have everything in flux. And it takes a lot of time and it takes a lot of learning and a lot of experience. Usually, I don't know many people who are great at doing all these things right out of college. It takes a lot of time to get these skills all in the right balance so that everybody's happy, the product ships, and you feel like you maintained directional control over, not directional control in the sense that it's what you wanted, but directional control in that you steered it to completion successfully. Yeah, I agree. It's difficult. I don't think, it's definitely a skill that no one is born with. It's something that you have to learn and unfortunately sometimes it's the painful, it's a painful lesson learning exercise. I sometimes feel bad when I learn some of these lessons and I learn them at a customer's expense. It's rough because you look back and you think, "Well, if only I've done this differently, I could've saved this amount of time and this amount of effort and we could've put that to support some more features that they would've liked." But I suppose the good news is though, most of the clients that I've worked with have been relatively understanding. So unless you come in and do something really, really and you burn a ridiculous amount of time, and they take exception to it. That really hasn't happened very often. Most clients are pretty understanding and they wanna work with you to get the best possible result. So, but definitely something you have to learn, no doubt about that. - Yeah, I think, if you're approaching it the right way, the relationship with the client, you want it to be long-term in many cases. And if you're coming from a place of real earnest desire that you want them to succeed through your efforts, I think people are generally more flexible than most people would expect. And even if, like you said, you wish you had done things differently or you could have saved money and put it towards other features, I think people will recognize, good clients will recognize the effort that you made. And if you do those things and have the best intentions, I think the end product is usually good enough to suit their needs. Certainly in a lot of cases they know it could have been a lot worse because sometimes they've worked with groups in the past and it has been a lot worse. So your results that you think might not have been that great could be exemplary to them. And if it all goes off pretty well, you can continue working with them hopefully and maybe take those lessons and build something better the next time, which is, that's a great scenario to be in where you have a good relationship with a client And, you know, the future is bright because you both understand each other and what each party wants and are willing to, you know, learn together. Absolutely. Well, we talked a lot about on this episode about working for clients, doing client work, and I mean, obviously, that's the majority of what we've done in our careers, and that's fine. I guess something though that Nickelfish is been doing a little bit more of recently though is some more of your own stuff. Could you talk a little bit about that before we wrap up? Yeah, absolutely. For a very long time, we've wanted to build our own products and it's been the kind of thing where when you do client work, it's tough to find the time to build your own stuff because the client work takes priority, it pays well, it pays your bills, keeps the business going. So we found ourselves in a position at the end of last year and at the beginning of this year where we had a certain balance between client work and availability and we said, "Now's the time to do it." And so we decided to form a separate, smaller company, a separate brand that's affiliated with our company, Nickelfish, called Derby. What we intend for Derby to be is our product team. We have a handful of ideas that we've been working through, but we are super excited to be able to finally do this. The only way we were able to do it was to actually take a couple of us and completely cut off from client work altogether. I haven't dealt with clients myself since February of this year, which is, you know, the majority of the year has been spent building, you know, a new process and getting this thing up and going and focusing on a single new product that we're going to be, you know, releasing pretty soon. And it's been a really interesting couple of months and it's been a huge change from, all the stuff we talked about. But just to kind of touch on something that you said earlier, we had talked about if you're building your own products, it would be in your best interest to be really focused on selling features to yourself to make sure you're spending time in the right way. That is something that we've really, really tried to do. We've done an intense amount of thinking and planning, planning and every decision that we make within the app that we're working on, we talk about it and we make sure that it's for the right reasons. And the right reasons might be because we think it's a saleable feature, because we think this is something that is core to the experience that needs to be there so that people understand it or enjoy it, or this is a change to the code that needs to be there to handle this, this or the other thing. And we've approached it with the same rigor that we approach the client work that we do. And it's been a really great experience because it has not been the kind of thing that meanders all over the place. We've been very targeted and very focused in what we wanted to build and when we wanted to build it and the timeframe in which we had to do it. And so the real test for us is gonna be, when we release it, how does this thing perform? And of course, we're putting it out into a really crowded market, but we haven't spent an inordinate amount of time on it. So we're kind of looking at it as a case study that this is the first time we've done this process. We've gone down this road and had these things kind of all working together. And it is such a different animal from the client work that we've done that even if it's not an amazing success, which of course we all hope it is, 'cause why wouldn't you, you know, there's a lot of learning that we did along the way that I think will influence the next project that we take on. And, you know, it's, as I said, it's so different from the stuff that I've been used to doing for the past 10 years or so. It's exciting, it's terrifying, it's invigorating. It's all those things, but it's still work. It's still the same kind of work, just with a different focus. But since we're the ones making the calls, there's this extra added gravity as to, is this the right thing? Is this the wrong thing? Does this even matter? Will people even notice? And it's been a very strange and wonderful experience. - Yeah, well, it sounds like, I mean, Since February, you just said, didn't you? I mean, that's nearly a whole year now. So, it's been, that's a lot of time and a lot of effort. - Yeah, I mean, the first part of the year was, a lot of my time was spent kind of like tying up loose ends on client projects that I was affiliated with, and also getting the process for this new kind of thing started, because we'd never done an end-to-end product ourselves. So, there was a whole lot of planning that we wanted to do, and we wanted to build, I mean, it sounds super boring, but like we wrote a lot of documentation for ourselves to understand what it was that we were trying to do because we didn't wanna just go, we're gonna do this thing and yeah, sure. So we built decision gates and product funnels and all of this stuff and spent weeks and weeks just figuring out how we wanted to figure things out. And if that sounds like an incredible waste of time, I would strongly disagree because I think the danger that a lot of individuals and a lot of companies find themselves in is that you don't do enough thinking up front and now you get to a point where you are three quarters of the way through a product and you're not even sure what the direction of it is or what your plan is. One of the things that's been great for us is that we've been very clear the entire path as to what we were doing and how we wanted to accomplish it. That in and of itself is extremely freeing because you're not worrying about those things. You're worried about the things that matter. You're worried about your code. You're worried about your experience. You're worried about all the stuff that you should be worried about, not why are we even doing this. And that it took a while to actually start building from prototype to real production code. Once we got there, we felt like, yeah, we've done all the things we needed to do to get here. This isn't just kind of a fly by the seat of our pants thing. We're really planning for this thing to be a long-term viable solution to this thing we want to do. Cool. So, how much further is there to go before you've--? Until it's all out there, I realize that you've done some pre-announcing. - Yeah, yeah, we have, we're getting close, we're getting close. We're probably in the very last stages of fixing some last little bugs and things that we wanna tweak, but we're probably gonna submit to the App Store pretty soon and we don't have a date in mind yet, but we'd like to kinda get it out either the end of this month or the very beginning of December, just because we're not sure with app review time how long it'll be and we probably don't wanna release right around Thanksgiving 'cause there's all kinds of other stuff that happens. So we're getting very close. The website is up, you can see a little bit about the app and I have started to kinda talk about it a little bit more which was fun in and of itself because it was like a super secret for so long. But yeah, we're pretty close. So you should be seeing it within the next few weeks I'd say. Fantastic. All right, cool. Can't wait. Yeah. Very exciting. All right, well, we might wrap it up I think at that point. Unless there's anything else you wanted to add? No, I think I'm good. All right, cool. Well, if you would like to talk more about this, you can reach me on Twitter at johnchidji. If you'd like to send any feedback, please use the feedback form on the website. That's where you'll also find the show notes for this episode under Podcasts Pragmatic. If there are topics that you would like me to cover, you can suggest and vote on them at techdistortion.com/topics once you sign up for a free account at techdistortion.com. You can follow Pragmatic Show on Twitter to see show announcements and other miscellaneous show-related stuff. I'd like to thank my guest host, Seth Clifford, for coming back on the show. What's the best way for people to get in touch with you, Seth? That's probably Twitter. I'm Seth Clifford on Twitter. If you'd like to see the work that we do, you can visit nickelfish.com. If you're interested in the new company and the new product, you can go to heyderby.com. Fantastic. I'd also personally like to thank Harvest for sponsoring Pragmatic. If you want to track your time quickly and easily with the ability to quickly turn those time sheets into invoices for your clients with built-in support for both PayPal and Stripe, then Harvest has what you need. Check out Harvest at getharvest or oneword.com and sign up for a free 30-day trial today. Once your 30-day trial is over, use the coupon code "Pragmatic" at the checkout and you'll also save 50% off your first month, but hurry because this offer expires on January 15, 2015. I'd also like to thank Mandrill for sponsoring this episode. If you're looking to improve your site or app and need transactional email that's reliable, integrates easily, and provides easy tracking and analysis, then Mandrill can help you. Visit mandrill.com and sign up today. You should because it's free, no credit card, no commitment, just sign up and use the promo code pragmatic to get 50,000 free email transactions per month for the first six months. That's four times the normal amount that they would give you. Integrate, deliver, track and analyze email infrastructure from Android. Well, thanks for listening everyone and thank you again, Sam. - Yeah, thanks for having me. (upbeat music) (upbeat music) (upbeat music) [MUSIC] (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) [Music] Question from Vic in the chat room. It's also Vic's birthday. Happy birthday, Vic. And his question is, how do you know when it's time to ditch unreasonable clients? Or perhaps another way of expressing that he then says is, where do you draw the line? Well, first of all, that's a very loaded question, ultimately saying that they're an unreasonable client. Maybe they're just a... how do you define unreasonable? I guess clients that keep changing their minds, I would classify as unreasonable. Beyond that, I don't think it's fair to call any client unreasonable. I don't know. What do you reckon, Seth? We've only done it, I could count on one hand, the number of times we've done it, because in that kind of business, you assume that you need to maintain the client relationship, and that's your goal. So, you know, it's funny, you said something earlier about taking the hard line as a designer and just saying, "This is the way it's gonna be," and that's not, and there's a lot of people that I have seen online either write or talk about or talk about this kind of thing and taking this hard stance and being like, I drive my clients and this is what I know best, what they want, that's why they're coming to me. And I have to wonder if what kind of business they have, what kind of repeat business they have and what the relationships are like, or if that's really just kind of bluster and when it comes down to sitting around a table and hashing out ideas, if they're actually not as, you know, domineering as they'd like you to think that they are, because it's really, like any other relationship, you have to work at it and it's not gonna be ideal. Almost no clients are ideal, so you have to understand where they're coming from and try to address the needs that they have, and if it's really making your life miserable, I think there's plenty of opportunities to have conversations, but in terms of kicking one and just being like, we're not working together. As I said, we've only done it a couple of times in 10 plus years of business. And it's been a scenario where the client has been either abusive in no uncertain terms, or we're looking at the project and saying, this is going to be an abject failure and it is due to this client's involvement. This is not a healthy relationship for us to have. And just the way you would examine the relationship with a significant other and say, "You know what, this is not good for us." That's something you have to do sometimes. And it's not a great conversation to have as it isn't a great conversation to have in a personal scenario, but it occasionally has to happen. But it's usually something that has to happen over a period of time. And you really have to be sure that you wanna do it. - Yeah, absolutely. And I'm actually, when you were describing that, I'm going back in my mind and thinking how many times I've actually done that. And there were 2 customers that I can think of in 20 years where we said, we will not do business with you because you are difficult and usually difficult from the point of view of non-payment. And the non-payment comes in multiple forms. You know, the strictest and simplest way to think of it is I've asked you, I've invoiced you for $2,000 you haven't paid a cent. You know, that's the obvious one. But no, I mean, in terms of we're going to continue to ask for more and more features, but we're not going to pay you anything additional for that. And we're going to withhold funds for stuff that you've already actually provided on the basis that this other stuff you haven't given us. And the contract law in in construction contracting Australia is a little bit gray in that respect, whereby in some circumstances an end customer can get away with demanding that you provide that as a variation for additional works. And if they if the end customer then does not pay you, then you have rights to go and take them to court. But then, of course, they start arguing about how much value it's worth. And, you know, you end up doing the work at cost plus a minimum percentage and it gets very messy contractually. So it's easier for us to simply say, we're not going to work with you. Thanks for playing. See you later. you can have whatever work we've done and we don't expect to get paid. We're just going to walk from the contract. And, you know, there's always after a while doing that, if you do a few times, you end up writing clauses like that into your standard terms and conditions. So answering the question, it doesn't happen often and it's not a decision you take lightly because it's not just it doesn't just affect. I think taking a decision like that does not just affect that one client relationship, that can, if you're not careful and if you do it too often, I think that can drive a market perception of your organisation, that you are customer hostile and that will affect your ability to win work. Without a doubt. Yeah. And that is a dangerous situation. You do not want that. So I think it's a good question, but the reality is it doesn't happen very often. [8-bit music]