 Why don't we just use this plug-in? It's a fair question. Nothing wrong with asking it. I've posed this question to my fellow developers. I've posed it to my managers. I've posed it to my clients. They have posed it to me. People I don't even know have posed it to one another in reference to plug-ins I have written and released out into the wild. Why aliens? Well, because this talk is about third-party dependencies, code and services and people that are not part of our organization. They're foreign to us. They're alien to us. They possess superior technology to us. They have the ability to abduct us and hold us hostage to their powers. Why retro? I first became fascinated with this aspect of development five years ago in a meeting in which I embarrassed myself, which I will describe to you shortly. Five years ago, 2013, that's kind of retro for development time. Allow me to define some terms. Third-party, you are third-party if you are a person and I do not compensate you for the bulk of your workload. You are third-party if you're a company or a service and I don't own it or control it. You are third-party if you are code and the people on my team don't understand every line of it. Something has changed since I started writing about this in 2013 is that the third-party landscape has gotten a lot larger. GitHub has grown from 7 million to 28 million users. WordPress Core has gained market share from 17% to 32%. Now it's a fair question to this audience, is WordPress Core third-party? I don't necessarily know the answer to that but in as much as it replaced no CMS websites or home baked CMS websites, that's considered third-party. Another thing that's changed since 2013 is we now have access to the perfect acronym to describe what this talk is about. FOMO, fear of missing out, my clients, my coworkers, my competitors, they're at happy hour. They're done because they downloaded the solution and I'm still in the lab debugging my custom code. The idea of selling original work seems oddly old fashioned. So what's actually the problem with third-party tools? What could go wrong? Well, there's three outcomes. You could download something and it just doesn't work. It's broken or it's not what you thought it was or it's just not the right fit for whatever reason. That's okay. It took you five seconds, five minutes, you move on. You could download something and it seems really good. It seems perfect and it seems to work and your client seems to like it and their customers seem to like it because they're paying the client and the client's paying you and you wake up one day and it still works. That's also fine. The problem scenario is what I call the Wiley-Coyote scenario. A third-party tool is a bit like a platform. It's something you can easily step up on and gain a higher vantage point or like Wiley-Coyote step out on. After you've made that progress, after your client's been paying you, your customers, their customers have been paying them, one day you wake up and the platform goes away. Like Wiley-Coyote, you're falling down. Your client wants to know why the moneyometer is stopped. You don't know because it's not your code, it's not your service, it's not your people. It helped you get here but it's not helping you now and you're not sure when it's going to. Something has changed since 2013 is that to my eye, the WordPress.org plugin repo is serving up more stable solutions than it was five years ago. But our reliance on third-party tools has increased in the last five years. So the net frequency of the Wiley-Coyote scenario is still high enough to make this worth talking about. NPM install, anyone? Thank you, a few chuckles there. This talk is a tale of two plugins. One plugin will decide to do in-house. The other plugin will decide to do third-party. No kidding, there I was in 2013 in a meeting. We're reviewing tickets, reviewing feature requests. We get a request, ticket A, and I announce to the group, we should do this ourselves. We shouldn't pay other people to do our work for us. We're developers. We can do this. There's no reason to bring in a third-party dependency for this and people generally not in an agreement next ticket, whatever. I read the ticket and I quickly announced to the group, why should we do things ourselves? Why should we reinvent the wheel when there's perfectly good third-party services to do this for us? And the woman in charge of our support team was fairly astonished at my lack of self-awareness. The speed with which I managed to completely contradict myself with no apparent thought behind doing so. I was embarrassed. She called me out and it's one thing to be embarrassed like with your friends or with your wife or something, but being embarrassed at work sucks. And I did what I do whenever I get embarrassed by something at work. I wrote it down in a blog and I've been thinking about it more and I wrote an article about it and I've arrived at what you might call a decision-making framework. In my defense in that meeting, I think I was right. I think the gut reaction to do plug in A ourselves and do plug in B through a third-party was right. The problem is that I lacked a formal way of expressing it to the group and that's what I'm gonna share with you today. The real heart of this talk, the real issue is that as professionals, we're very serious about the technical details of the problems we solve but sometimes we forget to consider the most important question of all. Do we solve the problem ourselves or do we acknowledge that somebody else already has? All right, this is the slide where I announced to you that I am done talking about what I'm going to talk about and I'm ready to start actually talking about it. There's five points we'll go through here. In point one, I'm gonna tell you a hack around the simple practice of fielding a request. In point two, we're gonna address the crux of the matter to dev or to download. In point three, we'll assume that we are downloading our solution. Which one do we download? In point four, we'll assume that we picked one, what now? In point five, we'll take a couple steps back and assume that we're doing it ourselves, what then? All right, I called this point one in the last slide but really you might call it point zero because it's so foundational. I wanna propose to you that you play a little language game when you field a request and ask yourself, is this a request or is this a goal? Those words are kind of synonyms but if you take a minute, you can discover some important nuances to the ticket that you're reviewing. A request is I want my search widget to give me type ahead suggestions like Google. A goal is well, actually I don't care about a lot of the things that Google does. I don't care about the cloud based indexing or the full text searching or the language predicting. I actually just really like the interface of being able to type in and have it seem like it knows what I'm doing. My request is I want the recent posts from some arbitrary number of RSS feeds. Well, the goal there is it's not simply that I want you to loop through each RSS feed and give me the recent posts from each feed. It's a much harder problem. I want you to be aware of all the posts in the history of those feeds and in aggregate give me the five most recent ones regardless of which URL they came from. This exercise leads me in that meeting is what led me to the gut feeling that we should do the auto suggest search ourselves and we should do the RSS feed smusher feed aggregator as a third party solution. So before delving into how to pick which third party provider or what to do once you've picked one, I wanna start with deciding whether or not we're gonna use a third party at all. I believe the fulcrum to this decision lies not within the ticket body, certainly not within the marketing page for the third party solutions you're considering. I think the decision is actually self reflection in your own organization. After all, you don't know much about these third party providers, but you can learn a lot about what you do know well yourself. I'm gonna suggest that you stop and examine yourself, your team, your organization in three ways. Strengths versus weaknesses, self improvement and mission. Strengths versus weaknesses. So in the example of the auto suggest search, I knew that we had good front end developers. We were accustomed to using jQuery UI. This was 2013, mind you. We were accustomed to generally harassing WordPress into doing what we wanted it to do, extending it, filtering it, adding actions. We'd never done a type ahead search before, but we could think through it. Not so with the feed smusher. This was a time when, for our team, dev ops was a weakness. It actually felt like for whatever reason, we just were not equipped to hire and retain talented dev ops professionals. In particular, anything having to do with cron felt like it would be tempting a weak underbelly. Had the feeling that, as I was thinking about how to do the feed smusher, I felt like that's what we'd have to do. We'd have to set up a cron job and periodically poll all those different URLs of the feeds to see if new posts had come out. It just seemed nebulous. It seemed like it was not our strength. Score one for doing the type ahead search in-house. Score one for doing the feed smusher as a third party plugin. Self-improvement. Have you ever quit your job or wanted to because you were not learning anything new there? The tasks that present the best opportunities for self-improvement are the ones that are in the sweet spot of being challenging but attainable. Some researchers refer to this as being in the zone and they cite it as a factor in gaming addiction. I felt this myself on work projects and it's some of my favorite memories of work ever. Teams appreciate this. There is an organizational cost and missing a chance to pay them to learn. I could tell right away where the auto suggest search would fit. It would be a thrilling journey into the world of ideas, piecing it together using jQuery UI to devour post titles as JSON. On the other hand, the feeds smusher felt like not an opportunity to improve our team but an opportunity to frustrate our team. Felt like the success or failure of in particular cron tasks were mostly out of our control. Score another for an in-house type of head search and a third party feeds smusher. Organizational mission. If a new feature request aligns well with what our company is supposed to be for, then we're probably gonna resell it many times. We're gonna want our in-house dev team to iterate on it, improve it, and we'll have the budget to do so because the majority of our clients want it. For the type of head search, we'd fielded similar requests many times and we felt like it would be time well spent. On the other hand, no one had asked us for a RSS smusher before. Well, that's score a third for an in-house auto suggest search and a third party feeds smusher. Evaluating the unknown. We'll return later to the auto suggest search. For now, we're gonna talk about the feeds smusher. That's the one that we've decided to do third party. The question is, to which third party? The frustrating thing about working with third parties is that by definition, you make the most important decision, which is whether or not to engage with them when you know the least about them because you've not yet engaged with them. There are some things we can determine from afar. Familiarity, vitality, extensibility, branding, and SLA's. Familiarity, I wonder if we can increase the number of third party dependencies without increasing the number of third party relationships. In other words, is there a vendor that we already use for something who also has a solution for this request? That should weigh heavily. We may get volume pricing. Markup and style are likely to be consistent between solutions. We wanna avoid having a website that looks like it's made from spare parts. Oh, I'm sorry. I have a microphone on my neck. Okay. Do I have a microphone? Okay. Please join us in the front, would you like to? No? Okay. I will speak louder. We wanna avoid having a website that looks like it's made of spare parts. So we would trend toward engaging a third party that we already use for something else. In the example of the feed smusher, Google Reader was a good option because like probably everyone here, we use Google for a dozen other things. Vitality. Will this service stick around? Git is really good for version control. But you know what it's even better for? Figuring out if a project is still active. You can see update frequency, responsiveness to issues and also get a sense of what kind of community is there. This is true more so in Git repositories, I feel, than in the wordpress.org plugin repo for whatever reason. Something I think has changed since 2013 is Git is more ubiquitous. It's pretty hard to find a reputable service without a Git presence. This factor weighed against Google Reader in our RSS example because obviously Google is generally not an open source provider, certainly not in 2013. Extensibility. Can this service adapt as our needs change? Not only do we evaluate the core service, but we wanna dig into its API. If a service is extensible, it's more likely to fit as our needs change, allowing us to avoid the widely coyote scenario. You know what else an API gives us? It gives us a chance for our in-house developers to have a challenging but attainable task. API integrations also give us the perfect comeback to the accusation of just being a middleman between the client and some other vendor. We're providing a unique value add through our API integration. So an example is MailChimp. Okay, we have our clients send out their wordpress posts on MailChimp, but guess what? We'll give them a dashboard widget to show them their most popular email campaigns. And the example of the feed smush or a good API feature we wanted was the ability to programmatically dump the feed cache. Branding. Do you care about white labeling? White labeling is the practice of reselling a service with your branding or with no branding, instead of branding from the original provider. A good example of this was the early days of Typekit when you often ended up with a position fixed ribbon on the bottom right corner of your site, letting everyone know you're using Typekit fonts. Being that we're using far more dependencies now than we were five years ago, there's the potential for your website to look like a NASCAR. In the case of the RSS smusher, this meant trending towards solutions that just gave us a feed, just gave us a URL that we could pull posts from instead of, for example, an iFrame that built the whole entire widget for us. SLAs, what are you getting besides uptime? Well, for client side products, there's browser support. If you have 10 different widgets from 10 different providers, what are the odds that they all support the same browsers that you do? The same logic applies to accessibility. What are the odds that they're abiding by the same accessibility standards as you? Perhaps most important of all is support. If you pay your staff hardly anything by the hour, it's very likely that priority support is one of the most economical investments you can purchase throughout your third-party relationship. I think support has generally gotten worse since 2013. We're now routinely haranguing third-party providers on Twitter because we're frustrated with the support that they provide. In the case of Google Reader, it goes without saying there is no support. Relationship maintenance. So in the example of our RSS smusher, we've decided what third-party we're going to use. In 2013, we happened to choose Dig Reader. Perhaps a weird, right? It was the only enterprise-level service that wasn't actively advertising a shutdown notice. Yeah, but you know, if somebody else is gonna do the heavy lifting, I owe it to myself and my clients to find as much of the remaining slack to pick up as I can. Piloting, security, documentation, and in-house support are all valuable opportunities to nurture this new third-party relationship. Piloting, as exciting as this new relationship is, I probably don't wanna go installing it on a hundred domains on day one. You can ask staff members who work on these sites every day, give me a mixture of really common sites and real-edge cases. Do we have foreign language sites? Do we have sites that scroll sideways? Do we have sites that are dark on light, light on dark? And what's just a common normal site for us? Piloting might also be around the relationships you have with specific clients. Some clients are gonna be more tolerant or maybe even excited about being an experimental subject than others. Security, have you ever found yourself emailing teammates to get the login credentials for a third-party service? Some third-party services, such as MailChimp, make it pretty easy for different team members to be delegate members of a larger team account. Other services like New Relic seem to assume that people are gonna share a team login. If that's the case, you have almost no choice but to use a password manager as a matter of policy, like LastPass. Documentation, have you ever sent out a group email trying to figure out what a third-party was even for? It might get to a point where the only thing you know about it is that it's on your credit card statement every month. Have a directory of third-party relationships. It can be a binder, it can be a trapper keeper, it can be a WordPress blog. The important thing is that everyone knows where it is. It's not just about why do we use this service, it's also about why do we use this membership tier. Subject matter expert. We don't need every team member to be an expert on every third-party service we use, but we can tag individual team members to be the subject matter expert for a particular third-party service until they're all covered. This can be retained in personnel records. This can be passed along when staff turns over or you can just pass it around periodically to prevent sigh-lowing. We had decided that we were going to outsource the RSS feed smusher. We talked about that, how we decided to do it, how we decided which service, and some good practices to follow after having chosen to do so. Change of subject. We're going back to the autocomplete search now. We decided to build that one in-house. And what's the problem with that? Mary Shelley taught us the problem with that. In her classic book, Frankenstein, I've created a monster. Stop me if you've heard this before. Prideful developer assures the team they can do something themselves. It's a complex project. They make something nice, and the company comes to rely on it. Time goes by, it's doing fine. There's an ongoing maintenance burden, but it's worth it. Now for the Wiley Coyote moment. That developer leaves. Their old product needs maintenance, but no one knows what to do, and since it's proprietary, there's no community for it. Once you decide to build something in-house, how can you prevent that work from devolving into a resented alien dependency? Consider pair programming. As in two people, one keyboard, one typist, one decision maker. I don't think anybody works like this all the time, but it's an interesting exercise to try for an hour a week at the beginning of a large in-house project. Job switch Tuesdays. If you use a ticketing system like JIRA, let's say on Tuesday, two people literally switch identity. Today, Scott is gonna work on Angelo's tickets, and Angelo is gonna work on Scott's tickets, because they tend to get different tickets, and in this fashion, they'll be fairly productive, and they can ask each other for help throughout the day. Hold code reviews. If it's not readable, it's not deployable. This can feel intrusive at first, but that fades. Empower managers to ask question about code too if they have any technical bent. It's not just for developers. Sunlight is the best disinfectant. You can bring moldy code into light with automated tools like PHP doc or JS doc, that loop through your code and output it as a readable document. Blog about it, or speak about it in public. One of the best things and the worst things about the WordPress community is that if you're doing something wrong and you talk about it, you will probably get a lot of feedback about that. Beware the big. What's big for your development team? Probably not the same thing that's big for Microsoft, but you can get a better idea if you create estimates using the Fibonacci sequence. One, two, three, five, eight, 13, 21, 34, 55. On my team, we don't go above 55. This is also known as Agile poker. And it's the opposite of price is right. When you estimate the time required for a project, you're supposed to go to the next highest step. And because the gap between steps gets progressively larger, you're accounting for the fact that as projects get bigger, they inherently become harder to estimate accurately. This also gives us an objective way to record the estimated size for projects. So you have a sense, is this bigger than usual? If it is, that's possibly a sign that it's better to explore this feature by examining prior art, try a third party and see how other people have solved this problem. Look before you leap and before you don't. I don't know if your sense in this talk is that I'm biased toward doing things in-house or biased towards downloading them. That hasn't been my intention. My intention has just been to highlight the pros and cons to that decision in a vacuum. But being that the landscape is trending toward more third party tools, greater reliance on them, I do wanna advocate for doing things yourselves. I used to be in the military. I was in Iraq for 15 months from 2006 to 2007. I had guys I was with for whom it was their fourth time on such a tour and I would ask them, why are you still doing this? Why are you still on these patrols? Why are you still lying in ambush, raiding houses, disarming roadside bombs on a good day? I found that decent soldiers did it for the money. I found that bad soldiers did it because they couldn't do anything else. But I found that the best soldiers did it because they loved doing that stuff for its own sake. You probably don't have a lot of developers on your development team who wake up every day and say to themselves that they love downloading stuff. They love going to war in the world of ideas. If you wanna have a beautiful team that wants to stay on board for tour after tour, year after year, ticket after ticket, you kinda have to do things yourself sometimes. My name is Scott Fennel. I am from lexblog.com. We help good lawyers find good work by helping them have good blogs. My designer, Brian Biddle, made these slides. You can find me off the coast of Portland on Peaks Island for the occasional beach day. You can find me at scottfennel.org for the occasional blog post and you can find me at toptall.com for the occasional side project. Thank you. We have a few minutes for questions. I wanna share with you the most mind-blowing example of that you could ever imagine. The website csstricks.com, it got hacked really badly once and the reason it got hacked had nothing to do with the fact that it was csstricks.com per se, but because it was the most traffic site or it was the second most traffic site on MediaTemple. The first most traffic site, the attacker recognized and said, "'This is too much.'" It was jquery.com where the source files, the CDN source for jquery is hosted. And the way he accessed csstricks.com, it wasn't a vulnerability, it was social engineering. So, to your question, yeah, that could be bad. Yeah, that's a good question. Yeah, so the question was, yeah, yeah, yeah. It's a really good question. I'm gonna spin your question just a little bit because it's a little bit like asking what's more secure, open source or proprietary? I think we're starting to see that if something is open source and therefore it's more likely to be free, that exposure to sunlight is more secure than proprietary software. I've heard, this is a pretty grandiose claim, but you occasionally hear it said that WordPress Core has never been hacked. And I think that might technically still be true, which is pretty remarkable and I think it's largely because it can be examined, it can be reported on, it can be strengthened. So, I don't know the answer to your question, absolutely, but I do know that just because something is free, just because it's open source, definitely doesn't mean it's insecure. Please, yeah. So, the example, the classic example of a larger monolithic plugin would be probably something like Jetpack. And an example of piecing that, you could just pick and choose whichever feature you want to build up to that sort of functionality. Man, I'm not prepared to give an answer on that, absolutely. I think it's a great question. In terms of security, I think you probably would be better off with the monolithic one, that's just my gut sense. I don't know, I haven't looked at that aspect of things, but I appreciate the question. Thank you.