In another installment related to the Chasms app, we discuss errors with the prototype, finding the right balance of customer/product fit, and the need to brainstorm without adding requirements to the ideas.
- The initial prototype is working well
- Folks in the field are able to send SMS texts inbound to the chat channel
- There are odd errors, timeouts, happening with a specific officer worker
- Every message in Twilio is getting through and we're having a good experience with the Twilio API
- We have two issues where a 500 status (Server Issues) is returning a 403 (Unauthorized) incorrectly by the express server
- Slack seems like too big of an app for the single channel chat this product needs
- Randy feels the product will be built upon the communication transmission piece with several plugins to outside services
- Don feels that the plugin route may be overburdened with too many external APIs being used
Don VanDemark: Recording whatever whatever we talk about we talk about we'll see where it's usable.
Randy Burgess: But that's a very optimistic statement.
Megan Schemmel: Welcome to This Old App, a podcast about learning, coding, smashing stuff together, breaking things apart, startups, failing, winning, and any other buzzwords we can think of.
Don VanDemark: it is working. Well, um,
Randy Burgess: So we're talkin about our first test run of the prototype essentially, right? And so you say I've kind of observed from afar but.
What you say it's working, well and in what way like, what is it helping with?
Don VanDemark: So the the goal of it all was to eliminate, um, eliminate individuals in the field texting individuals in the office and that information not getting disseminated to everyone. Um, so what it what it's eliminated is eliminate those individuals in the office receiving individual text the text and the field are are sending it to the the system we've set up and except for a couple of odd errors.
We're getting it's working just fine. Um, I have not heard from the technicians in the field at all that they don't think something got through. Um, I think I'd see it into Twilio, uh, because at the very least if they texted the number Twilio would receive it's just a question of twilio got it into the system.
Um, and I look at the twilio log every day and every message in twilio is hitting our system.
Randy Burgess: Yeah, Twilio is pretty stable. As long as you follow the the pattern of send them an SMS, to this number, we'll do something with it. I mean, it's up to us to do something with the webhook that fired every time they get something that that was
Don VanDemark: that was the one thing we had to fix was we had that weird looping error. Um, Which was just an indexing issue, of course. Yeah, and that was causing the to it was causing the system to report a 404, maybe 500, I don't remember. It was a non-200.
Randy Burgess: Well think about it this way the air it was causing an error in my code. I believe was sending back a 403. That should have been a 500 right when I was sending back a 403 for any error, which is essentially is you don't have authorization.
I think so it was like you're not authorized is really more of you can't loop over this, there's only one record. So yeah, it was just a it was poor feedback on the status on the code. I think
Don VanDemark: so what that was causing was it would it would send, so because it was failing on the second iteration of the loop when there was only one thing to loop over the initial thing to loop over was working so and and actually that applies to multiple if it was two or three things that had to loop on it was failing on the N plus 1.
Yeah, so so it didn't really cause anything except for an error in Twilio. What happened when we took away that error in Twilio is now twilio sending back a 200 and now the text are going to um, the technicians in the field were getting an okay back every time they sent a message in because that was the 200.
Translating into an OK text. Uh, so I what I ended up having to do is uh, twilio has uh, a language they called TWML. Yeah that I just had to send an empty response back. I think it's still got the 200 but if it gets the empty response, then it doesn't do anything with it.
Randy Burgess: I'm curious if we can send back a 201 or 202 which is essentially OK, with nothing. I wonder if that would do the same thing. I mean, I'm fine with TWML or whatever. But uh, I think even cleaner would be just a status code of 201 but I don't care at this point. Um, so we know so the other issue was the timeout, um, because one of your folks twice got a timeout on what she was posting and you sent you said the same thing.
So I think our discussion yesterday is probably like this is a requirement of Slack. It requires a three second response. Um anytime they, their side sends out a webhook request, right? And it's up to the server to just say "got it" and then do the work on the side is an they almost want to their almost by design, asynchronous.
They just are pinging the like "hey did this server get our request, cool, take care of it yourself, let us know you got it." If you didn't we're gonna like you did like the server sucks essentially to the user is all I can gather from that. So we have to eliminate what I had like when I first set this up, um on the Slack side, I basically said tell Slack got it and then go to the work on the side and then send back a prescribed response to the channel. And then I learned oh, I can just send this all back in one big swoop not thinking not knowing about the three second rule and now I think that's causing the problem is that we need to go back to what I started with which was just tell Slack you got it, do your work, send back a prescribed response.
Don VanDemark: I'm not mistaken that the error we're getting is not the three second error is the H-12 Heroku right?
Randy Burgess: Well at first we were getting the three seconds and then the second one which I think is a coincidence was the 30-second timeout from Heroku, okay. My guess is that the Heroku side didn't get a response from Firebase is my assumption, but it's like when you look on the the last two days, there's only one 30-second timeout error. So I think it was a hiccup. Um,
Don VanDemark: yeah, and there's there's actually a page on Heroku. Um support about h-12 errors in node.js. Oh really? Yeah. Say there's a uh, they say there's a something you can install for Express. Um, which will drop along running request. I'll drop that. I'll drop that in Slack.
Okay and take a look at it. See how relevant you think it is.
Randy Burgess: So really like at this point. Um like this is so this is the weirdest a different type of project for me in a way because usually I'm the only one coding and I just have business requirements thrown at me and I just keep on coding my way.
And right now I'm like letting go of caring and like all right now I don't like how we do our payloads on Chasms on the um express middleware and stuff. So you converted all to an array and that it doesn't I don't like that but I don't but at the end of the day, it doesn't matter right now. Um, so I'm not going to make an effort to change it at the moment.
It's more about um, I guess the you setting the priority for what works for your business like how what is the next step to make this better? And I guess this I guess my goal is to continually build more requirements because then we're going to re-engineer it any way around those requirements that we don't know about
Don VanDemark: right, so here's here's where we're going to run into issues. And I think we're, I think we're getting close to point, so we have a few more things we could add to it that would be relevant to anyone. Um, uh conversation history is one of them, um,
Randy Burgess: which I actually am working on
Don VanDemark: adding enlisting the directory from the / command is another. Yep, and that might be it to where it's usable, now all that said there are then additional requirements that we specifically can use and I feel that's on me to just Fork it at some point and load those off into there. So I'll give you a couple examples. Um, because this is this is something you asked you asked the other day about I think so.
A technician sends in an update for work order. We use Trello to to maintain the history and the status of our work orders. It's essentially our knowledge base of what's going on. It would be beneficial to us for there to be some way to say when that comes in. Have some way to say send this piece of information to this Trello card and look up this Trello card by its work order number.
Um, but that's all our business specific. It's not necessarily something that the rest of the world needs.
Randy Burgess: Yeah, but well no. No, I think you should phrase it as the way that we do, I would say that the referenced to a work order is not necessarily unique ... The way that you do it is unique, the way that you execute the reference to Trello is probably unique. The fact that someone would need it is not.
Don VanDemark: Yeah, but we're only going to right. We're only going to write it to uh to Trello, you can only extract it so much.
Randy Burgess: No, I agree. I agree
Don VanDemark: because for others they might have homegrown stuff that doesn't have APIs, so there's no way we could get that information anyway, um. Should we write it with that mind? Yeah, we should write it with that in mind, but I just don't think it's it's there. Um, The other thing that is probably more universally useful is when an attachment is sent. So it's working real well that when pictures are sent in there showing in in the chat as well.
Yeah again a place to say a button to say save this picture to this work order. So we save all our pictures to directory named after the work order. Um, so building an interface and we do it on OneDrive, building an interface interface to OneDrive and too GDrive that's probably more useful. Um, so that's that's an ancillary one we can add on as a maybe you'll use this, maybe you won't sort of thing.
Randy Burgess: So, then let's ask a question. Let's... Do you think that this is a, a trinket, a little plug-in that is just like hey, y'all can have this if you want to your business, but you don't have a need to pay for it or do you think this is still a service that we could build more of an interface for the directory management, the message collection, the ability for companies to do just this silo-ing of the text SMS and other communications. Do you still feel that this is a service that people at your company would pay for if we brought it up to a business class type of interface?
Don VanDemark: I do still think those commercial potential. Yes. It's a question of how far do we go with? Um, because on one hand it can stop at the it can stop at the level of this is just a way to consolidate text messages. Um, and that's useful in and of itself. You can go all the way to the other extreme of: this is how to manage all your work and the consolidation of the text messaging is just a small piece of it.
Um, I think over the next 12 to 18 months that's what I will have built out is our own homegrown system and that's probably a lot on me. Um, what's the commercial potential for that? I don't know. There are already a ton of things out there like that. So it's hard to jump into a noisy pond.
Randy Burgess: Well, it's it's really about to me, um, knowing what the majority of companies... Not that what they're using. What are they not being able to get done with these systems like almost all of these homegrown management systems have gaps and if we if we are saying like hey, look at you talk to one cup like you discuss with one company. We don't even allow our people in the field to use SMS because we don't want to deal with this fractured communication platform. So right there, it's like, hey text messaging is really great from the field, pictures can go across it, text can go across it. The devices are relatively cheap or can be cheap. Um, and it's a way to have quick communication when there's no Wi-fi. All of these reasons make SMS still a great tool.
And so of course the development, the developing world still uses SMS like crazy. So the idea that a company's going to say don't use that channel because it causes problems is almost weird except that the fractured communication is a problem for anyone trying to dispatch a bunch of people in the field.
So we're gonna solve that problem with this, essentially, because when I look at it, from an outsider standpoint, I'm watching that channel and I'm like, wow that's better. There's three people in the office able to see what each person is doing and you're not yelling at across to each other necessarily on the back Channel, which is to me terrific. So I definitely can see it. And then I think about okay Slack is too much, like, Slack is for a humongous enterprise organization at that scale. What everyone needs is a very simple channel that everyone at the executive level can jump on, at the middle management level, and in the field and each one each party accesses it as they need or as they typically do and so slack to me is our example of a chat channel, but to me, it's just maybe if your team uses slack cool. If you don't then either we use an open source chat channel or we build our own business really not hard to do at a simple level
Don VanDemark: and and that that's where I've expressed that we're gonna go eventually, right? We started building this this particular project in Slack because that's what we currently use. We currently use Slack, because that's what I set up 18 months ago for us to use in the office to intercommunicate. It still doesn't go great, but it works to some degree that said there's nothing tying us to Slack at the moment.
Um, yeah, we could certainly use something else. We could certainly wear I think this goes eventually as I would like to see it go to uh, and that they're probably bad reasons for this but I'd like to see it go to a webpage based browser-based, um to where part of the page is that chat Channel, um, and then you've got all sorts of fun things you can do is when a work order pops up in that chat channel, it can be its own little link to where if you click on it on another part of the page the information of that work order pops up and then everything's in one place.
Um, but that gets back to what I was talking about about if we get there all of a sudden we built a field service application no longer have we built a a uh, a text consolidation, uh application and there's nothing to say that you can't build both.
Randy Burgess: But here's the thing. I I agree with you to an extent of Slack in and of itself is just a chat room. And all the other stuff that we add to make it work better or plugins that they didn't really build. They've built the API. So when you talk about working with Trello, I look at I think of as okay, a plug in now, that doesn't mean that we're building that we're going to build a Trello for this system.
We're saying if someone were to come and say hey we use Pivotal. I don't know why a company in that field would be using Pivotal but came and said we're using pivotal, or God help them, Jira. We would say, okay, how do you use Jira? And if they told us we use Jira, we link to cards and just like with Trello, then we would say, okay, we've got a plug-in that will take a link that you if you do like #WO for work order and you give us the ID to the card, we will create a link that they can click on and then it'll open it up on their phone or their computer. So to me it's a matter of us knowing more about the other companies and what they're using. Like, I think the wrong play is to say we've got a we've built a brand new work order management system and it comes with communications because that's just like, the last thing that any company wants to do is to use a new tool that forces them to swap out a previous one,
Don VanDemark: right? I agree.
Randy Burgess: So I think it's like I think your idea of attaching Trello is only you think it's as a completely unique thing for you because you don't expect other companies to be using that but what I'm thinking is that is exactly the path this will of plugins related to all the various work order systems and our job is not to replace the work order system. It's to attach to it. Right. So when I was asking you about work orders on the other day, I was really asking, I was really trying to get to this point of how do we connect to Trello with this thing for you?
I wasn't trying to say, "can I build you a work order platform.
Don VanDemark: Yeah, I was really and that was that was the next step is how do we connect to Trello, right? Um, let's finish up the text consolidation tool with the features we think it needs to for for um, you know directory management and things like that, but then we'll take the next step of hooking it into a bit, abstracting it enough so that we can hook it to Trello or any of the other things that are being used but just so you're aware, there are literally thousands of of these things. So that's why I'm I'm pessimistic that it makes sense to try and tie it to a lot of these other things because we're going to be writing integrations for each one. We're going to talk to one company and they're gonna be using ServiceFusion. We're going to be talkin to another they're going to be using service Titan. We're going to talk to another gonna be using Jobber. There's there's and then who knows what the APIs into all those things are if they even exist
Randy Burgess: do we know if a company that maybe has got on the path where they were working with, I don't know, education institutions that had a lot of different Learning Management platforms, and I've heard the same thing from.
Don VanDemark: Yeah, that's why I guess that's what we were only with one two, three. We're only with three Learning Management Systems. And each time we do it, it's a significant effort.
Okay, so it's the possible. Yes, but we're talkin about that in that space. We're talkin about learning management system of which the majority is four, maybe. Yeah, yeah. Yeah, we're about feel Field Management Service or Field Service Management Solutions, of which the answer is there's an infinite amount of them.
Randy Burgess: But I guess my the thing that I would stress here. I know the difference between what I just said on the education learning, but what I guess I'm what I'm saying is the field is so undisciplined and so behind from a technical standpoint that if we provide a few solutions. To like, hey, instead of you're using this web quarter like we can go out and determine what are the more advanced API accessible work order platforms that are out there?
What do we think you may want to use if you were to decide if you love our tool and you're going to switch to a work order platform, which one would you probably use? And we get to in a way say, "by the way work order inc out of Seattle has a really good platform and we will if you decide to switch to that we'll have a plug-in for you" because they're advanced, they're moving forward, they're gaining customers, whatever, and in a way we steer it like the industry because otherwise yeah, it's like yeah, we can't connect to to note Post-it notes on your desk. I'm like that's impossible and, but what were able to do is say like hey, there's some these are the more technically advanced companies in this field that are easy to work with and we will provide those plugins because it makes this our service more accessible as you advance like that I guess that's my thinking.
Don VanDemark: If I can go one step further by taking his back, I don't I don't know which direction I'm going with us. Yeah, so what if so why why did we focus? And you said this you said this 15 minutes ago, why did we focus on consolidating SMS?
Randy Burgess: Because this was the biggest problem that you were facing
Don VanDemark: but why SMS? Why not build an app that they can install on their phones?
Randy Burgess: Because you don't want to deal with people in the field having to install an app on a phone that may be of low cost or the inability to put native apps on it.
Don VanDemark: Right and and it requires data whereas SMS and MMS require data, but usually work a little bit more reliably than than apps as far as yeah, um connectivity. So what if one of the next iterations is also the technician in the field being able to send a command in to that number to request information on a work order if the technician can also say, uh something to the effect of priority work orders and then what it can report back is work order 123 is due tomorrow, or work order 456 is due Tuesday, work order 789 is due Wednesday, and give it to them in order and then they can respond back with, okay, give me details on 123. Yeah, so, yes, they can that that can be a goal is to allow the technicians to be able to do a lot through text messaging. Um, we're selling them short by saying they can't do uh mobile apps. But I know that on conference calls I've sat in with other companies. There are certainly companies that have said my technicians don't have smartphones. So allowing the SMS part of it is certainly a good way to go. Um, I don't. I don't know but what five years from now, it'll all be moot and there won't be a choice, it'll have to be web app, but we're not solving for five years or solving for now.
Randy Burgess: Yeah, but really like my priority right now is totally for you to expand finding out the need. And until you can definitively say that you feel like man, I've talk to so many people they wouldn't use this even if I showed it to him?
Don VanDemark: Okay, I I'm not gonna get there until we've got a demo thing that we've written built a video for. And and I've showed it to 20 people in they're like, yeah, that doesn't solve any of our problems. And that what I would really want out of that discussion is I want to demo video and then I want them to say no and I'll be like, okay. Why no and what one thing would make you say yes,
Randy Burgess: I I just, in my heart, I do not believe that. Is a dog the question is does it supplement income for the people that developed it? That's what I'm that's what I'm most curious about.
Don VanDemark: Yeah. It's got to get to the it's got to at least get to the point of being worth our time. Um, yeah, but how far away are we? I don't know so that but again that's that's startup risks. That's not a big deal. So what what I will do is I will write a small thesis on here's how we work. Here's what the challenges we face.
Randy Burgess: And what I want to hear is you're like, yeah, we use this tool called Connect like, WO Connect, and God it's a piece of shit and that's that's and that's what that's what I want to hear. I want to hear them talk about it because we're talkin about Slack here. Slack was is a 2 year old old company, maybe three, and it replaced AIM? It replaced, uh about for IRC. They replaced the existing products that, and it does under a tremendous amount different, accepted opened up the ability to connect and it probably does better user interface and they allowed it to be used on multiple platforms.
But what. Say but IRC could do a lot of that and so could AIM and Yammer. I use Yammer frequent in years ago to build a fantasy sports store hated you but I loved it. Why hated it too at the end because they kept on adding features in Microsoft got it. But my point is there is no such thing as incumbents that are 100% protected if you get to solving the problem efficiently and that's what Slack is now facing competition because they have added so many enterprise features that they are now becoming the Jira of chat and that is not what the people in your industry need. They need something they don't hate, that is efficient, and actually says we're not adding that feature because it makes us to Enterprisey. That's what I think they want.
Don VanDemark: So. So here's what I here's what I'm gonna do and we can use this for just our own benefit. We can use this on This Old App. If we think it's interesting is I will I will write a little write something up and talk maybe even talk through it as am writing it up something about how we do work.
And then I'm going to do the same thing, right something. I've talked myself through it of if I could have everything I wanted in order to make my work order management easy. What would that look like, then that that that's a couple of pieces data points and then I'll take that and break them into issues within the GitHub and we'll sort it out.
Randy Burgess: Yeah,
Don VanDemark: okay on top of that. I got to build the website,
Don VanDemark: but that's the thing is thinking about the building of it is what slows down the brainstorming and what I don't what I need from you is the brainstorming and I don't want you to put any weight on the scope.
Randy Burgess: If you told me that I have been I have you can you can write down on a card. I want the ability to teleport a contractor into an Arkansas store from the Everglades, and I would be like interesting idea. I don't know the scope of it, but you put it on there, that's fine. That's what I you can't you're going to kill our idea or whatever the heck you call it, if you say well we gotta have a website for that and then you kill it as not plausible or out of scope and I'm like that's what brainstorm. Brainstorming should have none of that.
So I think we should use this recording.
Don VanDemark: Yeah, my problem with it is the length so I may try and get in there and do like I did with the other one. Did you listen to the other one? I did design because we were all right. So what I did with that is I would cut pieces out and I have a little fast forward real real fast forward sound and I just put that in there to say like hey, we skipped ahead in this discussion.
Hello, so if you just want to listen to that and see what you think of that that that's fine. Okay. Um, um, but yeah, I'll continue work on I I will I will take this apart and see what I can do with it, but I don't I do worry about it, but just being boring if it's no here's the thing if you are a new developer and trying to see how projects and startups go.
Hearing how this is the mundane discussions that happen. So yeah, I as long as we preface the on a podcast not us to other guys on a podcast talk about their careers and what they're doing of the week and one guys doing a start-up now one guy took a new gig and why do I listen to them? Because right it reminds me a little bit of what I think about and I also I make predictions based on like one of them quit his job, started to do a start-up, and I'm like, you know what he's going to last two months because he had no direction and every week it was like, I don't know what I'm doing, and I'm it's like it helps me to kind of think about, reflect on what I'm doing.
It's steers me a little bit, because I'm like, oh I sound just like him and then I so I did like people can fast-forward or not listen, if they don't want to this whole episode. Um, we are definitely getting different traction on episodes of CTO and Old App that based on subject like this week. Yeah, we just stormed out the gates on Choosing a Tech Stack the previous week Identity Heft, really low. People people still don't care about security and password as much as I do and so exciting. It's like it's really and I'm like this would podcast I listen to Wes Bos and his buddy talk all the time Scott Tolinsky and there's certain episodes, I'm like, I don't like they is jQuery dead. I just don't give a shit. Like I know what it I know what jQuery is. Yeah, I but when they I'm with you. I I don't listen but when they do Syntax on and when they do an episode on burnout, I don't listen to it because I feel like I've conquered that but when they do an episode on testing, I love the whole thing, so I get to pick and choose and I think people will too, and we just don't care.
Don VanDemark: Have you heard of the the startup podcast by Gimlet?
Randy Burgess: Oh, yeah, I will listen I listened to the first two seasons and then they started going okay different format.
Don VanDemark: So if you listen to the first season, then you know, we're essentially doing the same thing.
Randy Burgess: Yes, they just have better because I'm just now listening to the first season. I'm like, oh this is what we're doing.
Randy Burgess: Yeah, but today and it's interesting to to listen to that first season and I've kind of paid attention to them as they've grown. In some ways I think it's still a unprofitable people are sinking money into it operation and they're doing great work, but I don't know that they've hit hit, but they haven't struck gold on their episodes on there.
Don VanDemark: So just wait I just wait because I have not even started. We haven't gotten far enough within um with at This Old App. For me to really go off my rant on building a start-up with the VC mindset.
Randy Burgess: Oh, yeah. I haven't even started that yet. I know
Don VanDemark: just wait you get me going and I'm just gonna go I'm just gonna go off the rails,
Randy Burgess: but my point is I don't think we need to worry about like, yeah, we don't want two episodes of go too long, but people can skip it if they
Don VanDemark: may be but maybe it splits into a couple episodes, because we talked about a couple different things. Okay, so I will I will take I'll take the intro. I'll take the interim and pop it onto that design discussion. We had yeah, and that can be the first one about that one. And then I will play said I'll cut this one up too. All right.
Randy Burgess: All right.
Megan Schemmel: Thanks for listening to This Old App.
Notes and previous episodes can be found on our website at https://www.thisoldapp.online.
Reviews on Apple and iTunes are always appreciated and help promote the show
For questions, comments, or things you would like to hear on future shows, please email us at firstname.lastname@example.org
Show music is Guns Blazing by Fab Claxton, music licensed by pond5.
Voiceover work by MeganVoices.com.
You'll hear from us soon!
Fab Claxton license by pond5 voiceover work by making voices. You'll hear from us soon.