Web development is a mystery to most. As a matter of fact, you may not even know what we mean when we say web development. So in this episode, our web dev experts, Matt Grayson and Ben Bailey, will demystify development and help us understand what’s possible.
Roberts: Hello everyone and thank you for joining us. You're listening to A Little Off Topic, one agency's water cooler chat on digital marketing, business, and all the things that get in the way, presented by Speak Creative. Let's get into it.
Ervin: So on today's podcast, we're talking about the mysterious, the magical, the voodoo that goes on underneath the code, underneath the website, that's web development. While it may be a mystery to most, we've got two of our experts on staff here today with us who have demystified the entire thing. I've got Ben Bailey, one of our senior developers and Matt Grayson, who is our Director of Full Stack Development here with us today, which means that because I'm joined by Matt Roberts, we also have a trifecta. Three of the four Matts present.
Ben: It's a matt-trick.
Ervin: It is a matt-trick. Very nice Ben.
Roberts: Holy cow. That's the way you come into a podcast, Ben. Attaboy.
Kindra: We're done here. That was it.
Roberts: Good Ep. Well, like Matt said, thanks for joining us and I guess the place to start is a very basic place to start, but web development can be hard to describe because with the work that you do, the possibilities are endless, but we'll try to ask you anyway, can you define web development for us?
Roberts: Quality content right there.
Grayson: Yeah. I've been working on the answer for a long time. So like really, web development is not any different than software development has ever been. The key differentiator is it's a delivery mechanism. So if you go back to the olden days when you needed someone to build some software for you, or you needed some particular application that did something, you had to go down to the store and buy a boxed application off the shelf, shrink wrapped, and bring home those 37 floppy disks and install them one by one.
Ervin: In the right order.
Grayson: Yes and listen to the whirring and the clicking.
Roberts: Can we talk about the fact that about one times out of 10, disc #35 was missing?
Grayson: Or you knocked over the stack and they're all out of order. Those are great days, obviously fast forward, all along, over a huge period of time. So what development did was shift that model. Instead of having to go through all the steps and plan and package up the application and distribute it through brick and mortar distribution channels, now you can throw it on the web and anybody can get to it from anywhere at any time. So it streamlines that entire shipping process. It means instead of having to make sure you have as many possible bugs fixed at a time, you can ship a minimum viable product. You can ship something that works and then iterate over time and update it indefinitely, as long as you want to keep it going.
Kindra: I was just going to say, I've never really thought about that being the difference between like getting it in a box. There's bugs, you just think of that as the end product. But now I'm sure things are changing so much more frequently that those boxes are probably outdated before they even hit the shelf, right?
Roberts: I don't want to get too far into this visual picture, but when I think about folks who are familiar with something like a marketing website, or think about what am I used to, what do I do on an everyday basis that creates some proxy to what we're talking about? There are essentially pieces of web development that they interact with all the time that are second nature to them and that's like specifically around content management systems. I mean, that is a very easy graspable product, for lack of a better word, to explain some of what we're talking about. So when we're talking about web development, it's like you said, it's a mechanism that helps someone create outcomes that they're looking for. But when we start to try to demystify it or make it less mysterious, putting it in context of some things that we interact with on a regular basis helps. Are there other examples that come to mind like that?
Grayson: So obviously I framed it in terms of the old school style of go ahead and buy Microsoft office and install it. But the same idea applies to publishing a magazine. Whereas before you had to go through a long run process and edit all those articles on a strict publishing deadline and had to ship out a thousand copies. Once you ship it, it is gone. Whatever typos were there, you couldn't fix them. The same model applies to publishing. We're all used to it now. It's just the air we breathe. You can fix anything because it's just out there. So nothing is permanently set in stone once you ship it.
Kindra: Ben, anything to add?
Ervin: The presentation layer.
Ben: Yeah, the presentation layer. Then there's also actually working on the CMS or a custom business application. That's more of the full stack part of web development. So there's those two types of web development. That pretty much covers what people mean when they say web development. I'm trying to say is there are ends to the spectrum.
Grayson: When I jokingly said no, can't answer that, but look to Ben's point. It's really hard to pin down because it's just so broad. It covers so many things. Like if you were to sit down and list out all the different pieces that you need to know in order to, from scratch, pull together content application, presentation, whatever, and put it on the web. If you were starting from scratch and you didn't know anything and you didn't have a content management system already set up that somebody provided for. You didn't know how to register. It's just a huge list of things involved. All those different pieces are a part of web development, so it's just hard to say.
Roberts: So given the incredibly broad scope of anything that could be considered web development, where did you guys start? How did you get into this and begin to get an understanding of what it's like to live in this world where anything's possible, but it can be pretty all encompassing?
Ben: I started playing around with building websites in college. I didn't actually get a degree in computer science. My degree was adjacent to it. I took a few computer science classes and started building some websites for actually design-heavy stuff in college and then got into more of the server side development, what we do to build up our APIs etc. now, that sort of stuff I learned as I started my career and then advanced from there. That's pretty much how I got into it.
Ervin: What is your undergraduate degree in?
Ben: My undergraduate degree is in digital media studies with an art emphasis. So I was an art major. I actually took a lot of graphic design classes and I had to build 10 websites that may have not all been completed by the time I graduated. But they were all websites that looked cool.
Ervin: They're artsy.
Ben: They were intended to be artsy. Some of them worked.
Grayson: I took the more traditional route and got an undergrad degree in English and that has served me well.
Roberts: You have great syntax though. Oh, come on. That's a development joke. That kills.
Kindra: You killed it alright.
Ervin: Your undergrad is in English and then you have a graduate degree too, right?
Grayson: Yeah. I've got a master's in Information Science, which was really just buying time to learn a marketing skill.
Roberts: Awesome. So I guess what I'm trying to get at is the fact that we talk on a pretty regular basis about when we look at folks on our team and the roles that they sit in, there's an expertise that that person has. With web development being such a broad spectrum of things, thinking about getting into your careers and doing what you do today, how are you able to hold the right amount of knowledge to be able to even architect a plan to help somebody get a solution in place with just everything that's out there?
Roberts: That's great. That's exactly what I was wondering. It makes sense. I think when we talk about is web development possible to define, Grayson's very elegant "no." Is web development possible to define in how we as an agency approach it? It is a little bit more tangible because we are able to say "here are the technologies that are the playground that we work in on a pretty regular basi."
Kindra: So I'm interested in that. Maybe that's a question for you, Roberts. So I mean, web development is definitely one of those things where the more you know, the less you feel like you know, because it just peels back layers of the onion. So how does someone who needs some web app solution when they come to us, how does that sales conversation go? So that they're not overwhelmed by what they don't know, how do you manage that?
Roberts: You said it at the beginning because he said the more you know, the less you understand and I think the opposite is true, which is, I know very little, so I feel like I understand it all and can sell it all.
Roberts: But no, at least with folks who we talk to on a regular basis, there are two separate types of conversations that get started around web development. One is somebody comes to us and says, "Hey, I've got an idea for how my business could operate better, but I know that it can't be achieved through my normal marketing content management tools that I have at my fingertips." They know that the need is more complex than they can then they can accomplish on their own. They may not know even necessarily that what that means is it's going to require us to develop a system or some type of companion thing to do some of the legwork of what it is that they're looking for, but they understand that there are limitations that exist that they need help achieving or they've got an outcome that they want to get to. So with folks coming in from that angle, it's really pretty easy to say "Yeah, absolutely. Here's where you are and there's some kind of magical middle that's going to mean that we're going to have to develop some code to get you to the outcome that you're looking for. So let's start trying to try to peel apart what the key outcomes are that we need to look for. Then let me go and talk with our team and we'll put together some ideas of what we feel like is possible from a technology solution, because this is going to require us to build up something new." There can be parts of that conversation where, because web development is so hard to define, there's almost always some amount of, as soon as you start to tell somebody it's possible, there are lots of follow-up questions like, "oh, could we also..." and the answer is always yes, but there's that trying to coach somebody towards like, okay, everything literally, well, not everything. I mean, you can't teleport me as far as I know, but almost everything is possible in the world with web development. So folks eyes light up, they realize, oh my gosh, this thing that I've been imagining that I'm gonna not be able to find somebody to help me achieve this outcome. It's actually possible! Their eyes get really big and you have to coach them towards, "okay, let's focus on the most important things" because we haven't really said it yet, but web development can be very expensive because the systems that are required to create these solutions just take time, we're not generally working from a piece of technology and just adding little bits and pieces. A lot of times you've got to architect something from the ground up. So you want to keep them focused on those outcomes. So that's the first type of conversation. Those are relatively easy. The harder second way that development comes up in conversation is just realizing that somebody's struggling. You talk to a client on a regular basis and you just start to understand their relationship with their clients and their relationship with their business systems and you start to realize "we could solve some of these problems for you, where data flows from this thing to this thing, and just makes your life easier" and for somebody who's not already there, you've got to coach them towards what's possible and explaining the constellation of possibilities of web development is really where folks can get a little lost. So it helps to really have a very tangible example, like saying "Hey, somebody's transaction system isn't talking to their donor management system or their inventory system" and you've gotta be able to give them a really specific example to help them realize, "oh, this, this could be easier. It could be better" and if you can really attach some tangible values and like, "Hey, this is going to save you a few hours a week." Then it becomes really valuable to the client and you can get into the conversation and really start to dissect what they need.
Ervin: I think one of the key things that not everybody really understands when you're talking about web development or a custom web project, is that it's always the details that make or break a project. It's also always the details that are the hardest things, especially with expectations, that are the hardest things to get people to verbalize accurately and a lot of times, just based on our exposure to Amazon and Google and Google docs and all the other things that we use all the time on a daily basis, we just assume, "Hey, it's going to work like this. It's going to do this thing" and if you've not ever said we needed to do this like that, then it's up to the web developer to build it. A good web developer is going to build it the fastest way possible that is the most reliable and not necessarily look to add in all of that nuance. So that's one of the things that we always find challenging dealing with dealing with what development for other businesses.
Grayson: So when people point to Google or Amazon or Microsoft and say, "Hey, Google docs does this, why doesn't our thing do this?" and you just say, "Well, Google has teams of a thousand engineers working on this full-time and we have 3 or 4."
Roberts: Not a thousand. Less than a thousand.
Grayson: So you've got a scale of your expectations accordingly.
Roberts: Yeah. I think that's a really good point too. I think one of the things that makes web development tangible, as we're getting into a conversation and it becomes hopefully really helpful, is actually getting into the discovery and specification process and discovery architecture process, where at least from our approach, we feel like we've got a good way to surface a lot of those assumptions. Whether that's through screen mock-ups and descriptions of functionality or user stories, just to try to get a client comfortable with verbalizing some of the things that might come from some of the assumptions that might be in the back of their head, so that they can see something and key off it and say, "oh, that's not what I thought it was" or we describe how something behaves and it gives them the opportunity to run that through the filter of what have I been expecting all this time. I don't want to steal the thunder there, but I would love for you guys to talk through that, but it's worth pointing out that when we're in that discovery and specification phase or the architecture phase, it's way easier to make changes, than to build something and then have the clients use it for the first time and say something like, "oh, I thought it would work differently" and you've got to potentially undo weeks worth of work at that point. So can you guys walk us through what that process looks like a little bit more specifically?
Grayson: You will always be more successful in a project if you can get something in front of the user as fast as possible that they can click on. So even if it's just a small part of functionality, as soon as you can get something in their hands that they can actually use and get a sense for how it's going to work together, it's easier to surface those expectations, those questions about, "well, will it do this or this or this?" So that's where Ervin mentioned design sprint, which is the idea that you go into a very short phase of work, usually a week or two, that scale is dependent on the size of the project, but it's a really ongoing conversation with the stakeholders. Talking through the pieces of all of the requirements you have for this project, and then as you're talking through those, actually building out clickable mockups, that they can then see and get a feel for how the system works in depth. So by the end of this very short period of time, you don't have a working product, but you have something they can see and identify. Yes, it'll do these 10 things. I know because we've gone through it. We've talked about these pieces I can see and touch and make work. So then you can take that and actually go back and fill in the gaps and do the details.
Ben: It gives you an opportunity after those few weeks to find anything that might take even more time than you expected and go back and be able to revise the estimate and see where you can change things, etc. I was gonna say, it's part of being a good partner, trying to help people identify what they actually need, rather than being the wrong way of an expert and saying, "this is what you need" as opposed to listening and letting them tell you, and then build with expertise in mind. We should be experts in what we're doing. We should, in the right way, direct towards web standards or what's good for SEO or whatever. But at the same time, we should listen and be willing to help the client discover what's best for their products.
Kindra: It occurs to me, I think we've said this with web design, but great design is ignored because it's so flawless. Whereas with bad design, people are really quick to point out the flaws there. So the same could be said with development, right? Like Google or Amazon, it just works and you don't second guess it because it's so fine tuned. So getting all of those details right in the front can help it feel a lot more flawless in the end. Because otherwise, you're bound to point out all of the flaws or the bugs. Features, not bugs.
Ben: UX Design is part of both what the designers do and the developers do. So yeah, that's really important.
Kindra: So without naming names of clients, I don't know that we want to go that deep, but can you guys tell us some of your favorite projects or something that does work like that? Seamless and something that you have developed that you're really proud of?
Ben: My answer might seem like a cop out, but it's not. Overall, I think my favorite thing that I've worked on is our CMS, sitewrench. Or, I should say is one of our CMS, sitewrench.
Kindra: Hey, Matt Roberts loves that answer. He's going to put that on every sales call. That's great.
Ben: Mainly because I've been working on it for a long time and I've been able to contribute, and see improvements and flexibility. I think flexibility is something that we're still working on with sitewrench. We want to make it even more flexible. So it's been fun to speed it up and make it more flexible. So I've really enjoyed working on sitewrench.
Grayson: My favorite projects have been the things you can't see. So there was one in particular where we were given some a hundred thousand mailing addresses that we had to do code on the fly so that could be mapped and without getting too far in details, it's hard to geocode several hundred thousand addresses quickly. So it was an architectural challenge. It was a technical challenge. It was a process challenge with the client to understand how to make all this work. So it's been those kinds of projects, things that you don't see at the end of the day. But when you get all the pieces right, it just works and disappears into the background. You don't even know it's there.
Ervin: Simplicity in experience for the end user is always going to have been a product of something being extremely well thought out and tons and tons of tiny little details touched and paid attention to.
Roberts: We can all point out all the ways that like that experience could go poorly.
Ervin: Right. But you have to anticipate everything a user may do, and then a lot of things that users shouldn't do, that they're going to do anyway, and account for those behaviors.
Ben: That speaks to another part of design that's part of our jobs, which is the part that nobody sees, which is when you're thinking about what code that's running in the background, making sure that that's designed well to run efficiently and do what you need to do at the right speed and the right responsiveness.
Kindra: So when you guys are looking or a client is coming to an agency looking for a web development, what should they be looking out for? What are the things that you guys are asked frequently or that you feel are most important to make known? Maybe Ervin, that's a question for you. How do you vet some developers?
Roberts: How many Matts do you have on staff?
Ervin: Yeah. That's question Number 1. Number 2: Could I describe your project by saying "it's like Facebook, but"
Kindra: We're going to turn that project down.
Ervin: Yeah. How do you vet developers? There's a couple ways to do it I think. Grayson and Ben can talk about this a good bit too. One of the key things is experience. What can you show me that you've done? There's the obvious paths of, "do you speak the languages we speak or write the language of the languages we write or whatever. Are you familiar with those?" But then there's a quality that's a lot harder to determine and it's how do you solve problems? How do you think about a problem? How do you break down a problem? Or do you break down a problem into its components? Or are you just going to take a wild guess at it? That's really what you're looking for when you're looking for a good developer, because if you've got somebody who's smart and who is a problem solver and who is going to work hard, actually you can replace smart with work ethic to a large degree. Whether they're going to be complete and thorough with their solutions, then that's really what you want in a developer because we can teach them syntax. There's plenty of ways to learn that stuff, but it's how good are you at figuring out a problem and then figuring out a solution?
Ben: Steve Jobs is known for his slightly arrogant comment on Microsoft, saying that they "lacked taste" in the nineties and I think what he was really getting at was less to do with an arrogant position and more to do with asking the question "would I want to use this? would I actually use this this way?" and I think a developer needs to be aware of that, and an agency needs to be aware of what they're building and what they're selling to someone. Is it something that's actually usable or is it just checking a box and getting it out the door?
Kindra: Now it is time for our off topic question as we wrap up. So Ben, Grayson, thank you guys for being here. Our off topic question is maybe a little more on topic than most. But that's what happens when you have two people, we've got to find the common ground. So I would like to ask you guys, if you had unlimited time, unlimited resources to develop anything you want, what would that passion project be? There's gotta be something,
Roberts: There is a right answer to this, by the way.
Kindra: I don't know what it is for the record.
Roberts: Matt Grayson does.
Grayson: Coffee app.
Kindra: What would this coffee app do?
Roberts: Well, it's my idea. It's not Grayson's idea. So go back to you guys. If you had unlimited time and resources, what would you build?
Grayson: There's a certain amount of irony in that, as someone whose career has been developing software, I don't really like using software.
Roberts: Let's definitely make that the motto of the podcast.
Kindra: Well, it's because he can probably spot flaws a mile away. It would be too much for me to bear too.
Ben: It has less to do with his love for physical books rather than digital books, but that's a whole other conversation.
Kindra: Can't develop software for paperback.
Grayson: Yeah, a book can't spy on you either.
Kindra: That's a fair answer though. Truly.
Roberts: Ben, did anything come to mind for you?
Ben: This is a hard question. Legitimately hard, because I haven't thought about this. Anytime I think about programming, I'm thinking about what we're doing at work.
Kindra: Maybe something that makes your home renovations go a little bit easier. You've been killing it with home renovations, Ben. Surely there's a solution there you've thought through.
Ben: Sure. If I could build a robot to build my house, that'd be awesome. I don't know. I'm sure if I had enough time, I would come up with something that has to do with music or something along those lines. But there's so in that space right now that it's hard to come up with something new. I do enjoy listening to music a lot. I don't produce any music. I can't sing.
Roberts: Alright, guys.
Kindra: Well, we appreciate you guys joining us. Thank you so much for opening our eyes up to the world of development and again, making us certain that there is more that we don't know except for Roberts, maybe you know it all.
Roberts: Yeah, absolutely. It's just magic, right? That's what you guys do.
Kindra: There's an algorithm.
Roberts: A magical algorithm.
Grayson: Sufficiently advanced technology is indistinguishable from magic.
Roberts: From myself, our panel today, and all of us at Speak, thanks for getting a little off topic with us. If you liked today's episode, you'd love the content. Our team is cranking out on our blog, head over to made by speak.com to check out the latest and greatest. If you enjoyed the show, subscribe and leave a review on your podcast platform of choice and see you next time.
Does the concept of web development still leave you with questions? Do you have custom website ideas that need some technical brains? We’d love to chat with you about what it looks like to partner with us.
Get In Touch