In today's episode, we talk about a specific type of collaboration, and a pitfall most development and design teams end up falling into. Today's episode is sponsored by Codeship! Get started today with Codeship and get 100 free builds. P.S. - Codeship is 100% free for open source projects! Head to https://spec.fm/codeship to get started today!
In today's episode, we talk about a specific type of collaboration, and a pitfall most development and design teams end up falling into.
Today's episode is sponsored by Codeship! Get started today with Codeship and get 100 free builds. P.S. - Codeship is 100% free for open source projects! Head to spec.fm/codeship to get started today!
Do you have a question you'd like answered on the show?
Email me: developertea@gmail.com
What was the last project that you worked on that felt fragile? It felt like it was falling apart or that it could fall apart at any point. And part of that fragility is that the information about that project, it's kind of difficult to find, right? And so you're not really sure what you can change or why you should change anything. We're talking about this on today's episode because I want to discuss potentially an antidote or at least a story, a picture, a metaphor that can help you think about how to avoid this kind of scenario. My name is Jonathan Cutrell, you're listening to Developer Tea. And my goal in this show is to help you become a better developer. Sometimes that means that if you're a developer in a leadership position that you think about the way that your team executes on a project, from a zoomed out perspective, not necessarily what language you're writing or what paradigm you're following in your code, but also from the perspective of what is the flow of a project? How do you handle tasks? How do you handle uncertainty? Where does information live? These are all things that you should be thinking about, especially if you're in some kind of leadership or ownership position. We're going to take a quick break and talk about today's sponsor. And then we're going to come back and talk about the reasons a project may end up being fragile. Today's episode is sponsored by CodeShip. One of the ways you can avoid having a fragile project is by testing that project. But if you're only testing on your local machine, then a couple of things may be happening. One, you may actually have something locally working that doesn't actually work in production. So your tests may not catch some of those issues. The best way to handle this is to use continuous integration. This removes the testing validation from your local machine and it puts it on a testing server. It's called a continuous integration server. And that's exactly what CodeShip does. They have two primary plans. One is CodeShip Basic, which works for most projects. But if you have a more complicated project that relies on something like Docker to deploy, then you may want to go for CodeShip Pro. Both plans actually come with 100 free builds per month. So you can go and try this out to see if you like it, see how you work with it as a team. You also have unlimited projects and unlimited team members you can add. And if you're running an open source projects, open source projects are always free on CodeShip. And what this does is it runs your tests and it acts as a gateway so that you can respond when your tests either fail or pass. In other words, if your tests fail, then you can prevent the code that those tests are failing on from going to your live servers. Or even from going to your staging servers. If the tests pass, then you can automatically deploy to this live or staging servers. This can help you avoid situations where your code is fragile, where your deployment process is fragile, where you accidentally push code into production that doesn't actually pass the tests. Get started today by going to spec.fm slash code ship that spec.fm slash code ship. Thank you again to CodeShip for sponsoring today's episode of Developer Tea. So we're talking today about how projects can become fragile and what we can do about avoiding them becoming fragile. And there's a lot of causes that you can identify for a fragile project. There's tons of these, right? We can talk about not having a centralized location for knowledge. This is important, right? But the one that I want to focus on today is the idea of throwing a project over the wall. I probably heard this term before, but I want to make it more explicitly clear to you with a metaphor. Instead of calling it a project, because who knows what a project looks like, you can't really visualize that. I want you to think about something fragile. The first thing that comes to my mind is an egg, but perhaps it's a piece of China or something that you connect with. A thing that you personally, you know the fragility of that thing, and perhaps something that you value very much. And instead of thinking of your project as an ethereal concept, I want you to replace that concept with that fragile thing. Now, if you have multiple teams and multiple silos, usually the way this works is the designers or the developers work in one silo, and then they throw it over the wall to the next team, like for example, quality assurance, then quality assurance, throws it over the wall to the system administrators to actually deploy it to the servers, and then from there we're throwing it over the wall to customer service or something like that. Multiple teams may be involved in this scenario of throwing it over the wall, they all live in their own silos. If you think about the actual walls, they're throwing it from one silo to the next. And don't let anyone fool you. The reason this exists is because it has worked for some projects, and it has worked in other fields, for example, when handled properly this can work and manufacturing. But here's why it doesn't work very well for most people who are doing this carelessly is because the thing that you're throwing over the wall is fragile. So going back to our metaphor, that piece of China or that egg that you've wrapped up in your throwing it over the wall to the next people, that is a very dangerous process. It's very likely that it's going to break. So in order for this kind of process to work, you're going to have to put a lot of constraints, a lot of protection around that project so that when you do throw it over the wall, it can handle the impact. And as it turns out, the amount of protection that you need, that's really cost for a project. This is where things become very bloated. And because the transfer from one group of people to the next, some of those walls may be taller than others if we're going to continue with this metaphor, that means that the project is traveling further. That fragile object is traveling higher and therefore falling faster. And it's going to be, it's going to need much more structure. It's going to need much more padding around it. So what is that padding in reality? Taking it away from the metaphor, what can we use? What can we take away from that? Really, that's going to be things like knowledge basis. It's going to be things like having a testing strategy, having a lot of documented processes. It's going to be a lot of this external stuff that doesn't really contribute directly to the value of the platform. It only protects it. So how can we fix this? How can we use our energy better? Hopefully you've already seen this coming. We can transfer that project much more softly. Right? And we can hand that project directly. What does this mean? Well, sometimes it means working more closely within those teams. Sometimes it means doing away with the idea of silos altogether and having everybody work in a multi-disciplinary team. This is what I would recommend doing because I've seen it work well and it's been proven over and over to work very well. Ultimately, the things that cause fragility is when you don't have some kind of transfer, some kind of reasonable transfer between teams. Whether that transfer is on a daily basis in person, which is what a multi-disciplinary team looks like. We're transferring ideas back and forth. So one idea at a time is very easy to transfer. I can hold it in your hand and then hand it off to you directly. You're there already seeing it. You're holding it immediately. Or if you have a more segmented team and you do indeed need to have these bigger handoffs creating a process of overlap where those two teams work well together, the context is transferred. This is another way to handle it. I do recommend the former over the latter. I recommend a multi-disciplinary team because sometimes that overlap, number one, is very expensive again. But secondly, that overlap may not be enough. You may not have enough context transfer in that overlap. I highly recommend that you create multi-disciplinary teams. It's going to be very strange at first and sometimes it may feel inefficient, but ultimately you're going to find that your project becomes less fragile. You're going to have more shared information. A lot of the documentation that you create is going to be co-created between all of those teams. You're going to have a better relationship between, for example, design and development or front-end and back-end, client and server, and cis-admin and quality assurance. You're going to be working together rather than working on your own thing against each other. Thank you so much for listening to today's episode of Developer Tea. I hope you will stop throwing your projects over the walls, at least without giving them the proper protection. But I also hope that you will experiment with multi-disciplinary teams and then let me know how it goes. You can always email me at developertea.gmail.com. You can reach out to me on Twitter, at At Developer Tea, and at J-Contrail. That's J-C-U-T-R-E-L-L. Thank you so much for listening. Make sure you subscribe if you don't want to miss out on future episodes like this one of Developer Tea. Thank you again for listening, and until next time, enjoy your tea.