Listen
In this episode, we talk about cowboy coding, how we define it, when and why it might occur, and its potential impact on accessibility.
Mentioned in This Episode
- Family Business Beer Co Beers
- Cowboy coding
- Parse Error that took down WP back end HELP!
- Global styles – per-block custom CSS GitHub issue
- Husky on GitHub
Transcript
>> CHRIS HINDS: Welcome to episode 54 of the “Accessibility Craft Podcast,” where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.
In this episode we talk about cowboy coding, how we define it, when and why it might occur, and its potential impact on accessibility.
For show notes and a full transcript, go to “AccessibilityCraft.com/054.”
Now, on to the show.
>> AMBER HINDS: Hey, everybody. It’s Amber, and I’m here today with Chris.
>> CHRIS: Hello everybody.
>> AMBER: And Steve.
>> STEVE JONES: Hello everyone.
>> AMBER: And we are going to be talking about cowboy coding, but first we have to have a cowboy beer. [crosstalk 01:00].
>> CHRIS: All right, y ‘all. We’ve got Family Business Beer Co. And it’s their Cosmic Cowboy American IPA. This is lovingly brewed here in Texas, promises to have a citrusy and bold flavor, and they claim it’s a modern classic. So we’ll see what happens here.
>> STEVE: Yes.
>> CHRIS: I have never had anything from Family Business Beer Co before. Basically, I went into a place here in Georgetown. And I was like, “What’s good and what’s local?” And this was, like, the fifth one they listed, because I was, like, “Had that.” And then they recommend another one, “Had that.” And then they recommend another one, and we just moved through. But it’s Dripping Springs, Texas.
>> AMBER: So, I will say of all the labels that we had recently, this one is probably the least exciting.
>> STEVE: Yes.
>> AMBER: I mean, I don’t know, maybe it’s supposed to be like a [inaudible] or not.
>> CHRIS: I mean, that’s hops. You can see the hops at the bottom.
>> AMBER: Yes, it’s like an oval with a Family Business Beer Co. merge in the middle. A round beer your family. It says, yes, with the hops around it, but it’s kind of [inaudible].
Sometimes we drink stuff that you know it would jump out at you on the shelf. I don’t feel like this would really jump out at anyone, this stuff.
>> STEVE: No. But, it’s like… What do you call the, like, puke green and gold and black.
>> AMBER: It’s just how he feels about beer, everyone.
>> STEVE: No, no, no, no. Sorry. Maybe it has the opposite effect.
>> AMBER: Come on, it’s a lime color isn’t it?
>> STEVE: That’s puke green right?
>> CHRIS: Yes.
>> STEVE: It’s a little muddier than lime. [laughs]
>> AMBER: Well, OK, you don’t have to be a graphic designer or package designer to make good food or beverage products, right? So maybe they just start [inaudible].
>> CHRIS: Although it might help more people buy them.
>> STEVE: Yes, yes.
>> CHRIS: Yes. And we’re also we’re also coming down from Paperback Capiche, which has some of the best labeling game.
>> STEVE: Yes, totally.
>> AMBER: Yes.
>> CHRIS: Shall we crack these open?
>> AMBER: Yes, figure out how it tastes.
>> STEVE: Here we go.
>> CHRIS: Amber we forgot something.
>> AMBER: What?
>> CHRIS: Our pint glasses.
>> AMBER: Oh, so sad. Oh well.
>> CHRIS: We’ll have to do that next time.
>> STEVE: Oh, man. They hit you…
>> AMBER: Yes, I can smell it.
>> STEVE: That’s, like, instantly grapefruit. I can smell grapefruit.
>> AMBER: Let me say, I’m holding this 13 inches away from me and I could really smell it the second I opened it, but not in a bad way. I don’t think it smells bad. It is actually really grapefruit-y smelling.
>> STEVE: Yes, big time. I mean, instantly, when I popped it open.
>> CHRIS: Grapefruit. Pine Needles, little bit. That’s definitely hopped. This is going to be bitter as hell, y’all.
[laughter]
>> CHRIS: Prepare yourselves.
>> AMBER: You’ve written in our show notes pineapple, and I kind of do get a pineapple [inaudible].
>> STEVE: Yes, yes, yes, pineapple. Yes. All right, here we go.
>> AMBER: Chris tried it already. What do you think?
>> STEVE: It’s better.
>> CHRIS: It’ll wake you up.
>> STEVE: It will.
>> CHRIS: It’s like caffeine for the palate.
>> AMBER: It’s a nice [inaudible].
>> STEVE: Yes. This is like textbook IPA to me, you know, like, hit you real hard. We’ve had some IPAs that weren’t so IPA-y. Is that right?
>> CHRIS: Yes.
>> STEVE: But this one’s better.
>> CHRIS: Yes. This one’s really sharp, really better. It’s one punchy note of hops. I’m going to think about this one a little more.
>> STEVE: There’s a disconnect between the smell and the taste for me. I was almost expecting something sweeter based on the smell.
>> CHRIS: Yes, it’s not a particularly fruity IPA, because some IPAs can taste fruity. This one is way more like herbaceous and kind of a stringent versus being really tropical.
>> AMBER: You know what it tastes like? It tastes like the grapefruit [inaudible]. [laughs]
>> CHRIS: Oh. Yes, I can see that.
>> AMBER: Right? The white part of the peel?
>> CHRIS: Yes.
>> AMBER: That’s kind of what I think it might taste like a little bit.
I feel like it makes me a little bit sad because when I smell it, it doesn’t follow through in the flavor with what I expect it to be. I really like the way it smells a lot. But I’m not… Just a little bit small.
>> STEVE: Does it die off? Is it dying off, like, the smell? Maybe it’s that initial build up in the can when you open it?
>> AMBER: Yes, maybe. Or you just got used to it. I don’t know.
>> STEVE: Or maybe the bitterness is…
>> CHRIS: Contact with air will change the character of beer and wine as it oxidizes air. It’s a real thing.
I would be interested to try more of this brewery’s beers, though, like maybe some of the non IPAs. This was the one that was available on the shelf. And I was, like, “Dang it, it’s an IPA, you know. I going to get it anyway,” because I don’t have any time to go to three other stores and find something cool. So I just grabbed the IPA. I know none of us, like, super like them.
>> AMBER: I like trying beers from breweries I’ve never tried before. I think it’s fun and interesting, right?
>> CHRIS: What I will say is, first taste, this tastes like a brewer who knows what they’re doing. I’ll at least say that. It’s solid in terms of…
>> AMBER: Yes, yes. I don’t think it’s bad at all. It’s just I’m not an IPA person. But I actually think that if you like IPAs, you’d really like this beer, and I would say go try it.
I am still a little sad about their can.
[laughter]
Oh, let’s be real. It’s not just the Cowboy beer. It’s Cosmic Cowboy.
>> STEVE: Cosmic cowboy. What does that mean?
>> AMBER: I don’t know, but shouldn’t the can at least be dark blue or purple, with stars splattered on it.
>> STEVE: Oh, yes.
>> CHRIS: I want Paperback Brewing to do their can illustration for Cosmic Cowboy. I want to see that art.
>> STEVE: Yes.
>> AMBER: It would be a Cowboy riding a rocket ship through outer space.
>> CHRIS: Yes. And with a Cosmic helmet on or something.
>> AMBER: No, he has to have a cowboy hat.
>> CHRIS: He has to have a cowboy hat. OK.
>> AMBER: I don’t know why it’s called Cosmic Cowboy. Did cowboys drink IPA? Would that be the kind of beers that you would get out in the West when you were going to a saloon?
>> STEVE: Or in Texas?
>> AMBER: Or in Texas?
>> CHRIS: I don’t know. I feel like cowboy territory is like light beer or really strong whiskey. I feel like those are the two things that I associate with it.
>> AMBER: Yes. I mean, probably in the 1800s when there were actually real cowboys, and not the big ones that we have now. The beer probably was not super strong. I bet it was more watery because drank beer all the time, right?
>> CHRIS: They drank beer, they drank alcoholic beverages way back when to avoid getting dysentery and stuff, because the bacteria couldn’t grow.
>> AMBER: That was probably the problem with the Organ Trail , was that there were no saloons yet, and people had to drink the water. [laughs] So many people didn’t make it. [laughs] Or at least that’s my perception of it from playing Organ Trail in first grade on a green screen computer.
>> STEVE: The alcohol content in older beers like that was a lot less, I think, than newer stuff.
>> CHRIS: Yes, it was, like, 2%, 3%.
>> STEVE: Yes.
>> AMBER: Well, we have advanced technology now, right?
>> STEVE: Yes. That’s why they gave it to their kids for breakfast, you know?
>> CHRIS: Yes.
[laughter]
>> AMBER: It makes them chill out, I guess.
>> CHRIS: Maybe so.
>> AMBER: So this one is a 7%. I think it’s pretty good. I would definitely say if you like IPAs, go try it.
>> STEVE: Yes, yes. It’s a little bit of a chore to keep taking drinks.
[laughter]
I’m like, “Ugh, do I really…”
>> AMBER: Oh, see, it’s growing on me. I like it more the more I drink it.
>> CHRIS: Yes.
>> STEVE: This seems like a beer that you want to get down quick, because if it gets warm, it’s going to be real nasty.
>> AMBER: Oh, yes, it definitely has to be really cold.
>> STEVE: Yes.
>> CHRIS: Yes.
>> AMBER: Yes. We could have been smart and put our Accessibility Craft pint glasses in the freezer first.
>> CHRIS: Yes. Frosty glass. Yes.
>> STEVE: I need to order one of those. How do we order an Accessibility Craft pint glass?
>> AMBER: You can order one if you go to “Shop.EqualizeDigital.com.” And they have our alligator on them, which is super fun. There’s also t-shirts.
I had a t-shirt which I’m not wearing today. It would have been smart if I wore it for recording the podcast. But it came, and I was excited, so I wore it for WordPress Accessibility Meetup yesterday.
>> CHRIS: Did you get any comments?
>> AMBER: Yes, a few. But I also showed it to everyone. Some people were probably, like, “Yes.”
>> STEVE: Yes, yes.
>> CHRIS: Yes, yes.
>> AMBER: I was excited. [inaudible]
>> CHRIS: That’s fun.
>> AMBER: So I have to figure out what are we going to talk about in [inaudible], and I saw that Chris had gotten Cowboy Beer and I was like, let’s talk about cowboy coding.
>> STEVE: Yee-haw. [laughs]
>> AMBER: So for anyone who doesn’t know, Steve, you want to explain what cowboy coding is?
>> STEVE: I mean, I think it has a lot of definitions, but we have the Wikipedia. We can read a couple accurate definitions, right? So the Wikipedia definition is, “Cowboy coding is software development, where programmers have the autonomy over the development process. This includes control over the project schedule, languages, algorithm, tools, framework, and coding style. Typically little to no coordination exists with their other developers or stakeholders.”
It goes on, but that’s a pretty formal description. I pulled it up on ChatGPT and I kind of like ChatGPT’s a little bit better.
>> AMBER: Yes, what does that say?
>> STEVE: It says, “Cowboy coding refers to the practice in software development where programmers write code according to their own rules, without following any predefined plan or architecture, often disregarding standards, development procedures, and best practice.”
>> AMBER: So here’s something that’s interesting. You know neither of those said that it’s “working on a production website.” It sounds like you could be doing it in staging and if you’re not following other best practices, it would still be cowboy coding by those definitions. But I always thought of cowboy coding as how I started out, which was I went into WordPress and I went to the theme file editor, and I would just open it right there in WordPress and copy and paste my stuff in. From some tutorial I found, right?
>> STEVE: That’s the crime, right? What I just read, I think, it’s the law, right? It’s like going on production and doing it there is the crime, right? But I mean there’s other ways to cowboy code not necessarily on production, depending on how your workflow is set up, right? I like the ChatGPT description because it talks about somebody just disregarding procedures and standards and stuff, and that’s kind of what working on production is, right?
>> AMBER: Yes.
>> STEVE: I mean there’s a lot of ways you could set up your WordPress environment to be more conducive to cowboy coding. Why somebody would do that, I don’t know. But you know what I mean? Like, there are probably tools that you can use to check. You know, they have the “Plugin Check” plugin now, where you can actually check your coding styles in there, although it would have to be in a plugin. Never mind. Couldn’t do that on the theme. But you know what I mean?
>> AMBER: I mean, people on cowboy code plugins too. They have a plugin file editor.
>> STEVE: Yes. We’ve seen it. We’ve seen it all.
>> CHRIS: Well, I think cowboy coding, like with that definition, [inaudible] to that definition. Because if you think about it in the context of what cowboys were and are, you’re out there, you’re by yourself with limited resources and no oversight. And you have to come up with a solution quickly that doesn’t necessarily depend on other systems or other people. Because the work you’re doing is often invisible or in a vacuum, at least in the context of having other team members.
In the context of modern business, yes, I get like cowboy coding is frowned upon. But I don’t know. Do you think that there is never an instance where it should be done? Or, like, what is the line? When is it acceptable? When is it not?
>> SPEAKER 1: This episode of “Accessibility Craft” is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. A WordPress native tool, Accessibility Checker provides reports directly on the post edit screen.
Reports are comprehensive enough for an accessibility professional or developer, but easy enough for a content creator to understand.
Accessibility Checker is an ideal tool to audit existing WordPress websites, find accessibility problems during new builds, or monitor accessibility, and remind content creators of accessibility best practices on an ongoing basis.
Scans run on your server, so there are no per-page fees or external PPI connections. GDPR and privacy compliant, real time accessibility scanning.
Scan unlimited posts and pages with Accessibility Checker free. Upgrade to a paid version of Accessibility Checker to scan custom post types and password-protected sites. View site wide, open issue reports, and more.
Download Accessibility Checker free today at “EqualizeDigital.com\accessibility-checker.” Use coupon code “AccessibilityCraft” to save 10% on any paid plan.
>> STEVE: Oh, geez. Like…
[laughter]
You know, I’m a CTO, right? I’m trying to get to the point where it’s never acceptable, right? And that’s because when you have a team, you have to have some standards that everybody’s upholding to, right? Because when steps in that workflow are disobeyed or not followed, we know where to blame, right? Like, we know what went wrong and how to correct, right?
I think when you’re trying to maneuver a development team to all kind of work in the same way, in the same fashion. Not saying that that way is the perfect way and that it can’t be modified, it’s just that we have a process that, if something fails, we can either look at it, was that a failure on the developer, or a failure in the process? And if it was a failure in the process, we can modify the process.
So I think an agency at scale, or a piece of software at scale, you have to have some process, right?
Within our organization, we are moving a lot. We’re just shifting between website projects and plugin projects. And the more things you could put in the way of preventing errors, the better.
Now, that being said, I saw Amber a couple of weeks ago when she came up with this idea. She posted on Twitter about it and we got a few comments back, and forth. And some people were like, “Well, you need to know where the line is.” Like, it was a little bit both ways, right?
>> AMBER: Yes. so Derek Asher, who has a couple of different plugins and he also does work for clients, he says, “I have no problems cowboy coding a client site to make a small template or CSS change. Taking an hour to make the change by doing backup, staging, et cetera is a waste of everyone’s time and money.”
Technically, if you’re getting paid for that hour, it’s not a waste of your time. It’s maybe a waste of your client’s money, maybe. I don’t know.
>> STEVE: Yes, but the potential. I know there’s a case for everything, right? Depending on what the website is, what the website does, right?
We could say, if that client website is a WooCommerce website that generates thousand dollars of revenue per hour, what happens if you cowboy code and take it down for four hours and they lost $4,000 of revenue? Who’s responsible for that?
Also, if you’re going to cowboy code that, are you saying that there’s not a GitHub repository of that code as well? Is there no version controlling? And quite frankly, we’re going to talk about a little bit of our own experience in this regard. But if you’re going to cowboy code it, you’re still going to need to submit it to a repository at some point in time so that it’s version controlled, unless you’re just not version controlling.
>> AMBER: Yes. On small websites, it’s possible there is none.
We talked about our “Shop.EqualizeDigital.com.” I built that. We have a different episode that we can link to if people want to hear more about, you know, how I built that and why, which was mostly to test what the state of accessibility in WooCommerce was. But it doesn’t have anything version controlled.
Now, granted, I didn’t really write any code for that site. I did though use the customizer to put some CSS in to fix like focus outlines and hover states on a few things. So I made some accessibility fixes with CSS and I did it in the customizer. So there’s no version controlling. And it’s almost like something small like that, and it’s maybe, like, 10, you know, I don’t know. Well, that might be, like, 30 lines or whatever, but it’s not a lot, right? It’s very small number of CSS fixes. And it is a good point.
Like what Derek said, like, me having to go set up a child theme, and do all this stuff would have been a much bigger thing. But I think what’s hard about that is that in some instances, it’s like, OK, it makes sense to just do a little bit here. But if you come back a month later and you do a little more, and then you do a little more, all of a sudden you have… And I will totally take blame for this.
Our my.equalize site, I did it, but it uses our main site’s these, but there was a bunch of stuff that needed to be done and we were busy. You were working on the plugin. One of our other developers was building website for a client. So I was, like, “I’ll just do it.” And I didn’t do it the right way. Now I want to say it’s got about 600 lines of CSS in the customizer, which is so hard to troubleshoot then if you’re like, “Well, why is this happening?” And then somebody has to remember, “Oh, it’s cause Amber wrote a bunch of crap in the customizer.” And just overriding the code I’m trying to push in the [inaudible].
>> STEVE: Also, if you bring a developer in to work on your site, and they start modifying the CSS file, and they’re, like, “Why can’t I get these styles to like work?” Or what’s overriding these? And it’s another CSS entry point. The customizer does do a little bit of code checking for you.
>> AMBER: Or if there’s an error.
>> STEVE: Yes. If there’s an error, it does do a little bit. But I will say, too, Amber will do that from time to time, put something in the customizer, and then she goes to GitHub and opens an issue and says, [crosstalk ] migrate this customizer styles into the theme, you know? And that’s like straight CSS, and most of our stuff is all SAS, right? So we have to take that and then…
>> AMBER: I think you can write that in the customizer now?
>> STEVE: Oh, can you? Well, I’m saying, a lot of times what we have to do when that happens is we have to take what you’ve done and what we’ve done and collate it together, right?
>> AMBER: Yes.
>> STEVE: Instead of just opening up our SAS file and throwing in what you have, we actually go through it line by line, or at least I do, line by line and make sure that I’m collating it into existing styles if needed.
There’s something to be said about websites that didn’t require a custom theme development, right? That are built on a page builder, right?
>> AMBER: Yes or even if it’s built with one person. Like, he’s a solo person who works on one website. And I think it gets a little easier, what you were talking about. When you have a lot of people that’s working on something, the version control becomes a lot more important. And yes, adding CSS in the customize, that might make things look wonky, but it’s not going to take down a site.
We can post a link in the show notes to my first ever post on “WordPress.org” support from. And it’s actually two. If you go look at my history, the first two in a row where I was literally editing functions.php, and I got a parse error that took down the back end, and I didn’t even know. So this, it says 13 years one month ago.
>> STEVE: Yes, I like it. It’s like Amber described. She’s, like, “I was editing a theme, the functions.php file, and it went down, and I got this error,” and she puts out the error. And then she says, “The website’s fixed.” And then she responds right away, “Never mind. Fixed in C panel.”
>> AMBER: I also continued to cowboy code. But then I figured out… This is the beginning when I was just trying to figure it out. This was my first client who’s actually one of my really good friends, Laura, her website. But she was paying me money to work on her website, and I think she was on it when I did it. And she called me and she’s, like, “My website is down.” And I was like, “I know. I broke it. I’m sorry.”
>> STEVE: Yes, yes.
>> AMBER: And so I’m frantically trying to figure it out. And then I Googled, and that’s when I figured out that there was a file editor in C panel. So I could edit there and I wouldn’t lose access if I took the [inaudible].
>> CHRIS: Yes.
>> STEVE: What I would add to that is, I’m much more comfortable doing a live change, like a cowboy code per se. Because I know if I break it, I can fix it, right?
Amber’s like, “Well, should I just do it live?” I’m like, “Well, do you want to spend the weekend fixing the site if you take it down?” Or you’d have to hit me up over at night or something to help you get something back up.
I think if you’re really technical, you can take it down and get it back up pretty quick if you know what you’re doing.
>> AMBER: I just want to say for the record here, I have not broken a website at all recently. And that’s Steve’s in the middle of it.
>> CHRIS: Define recently.
[crosstalk ]
I’m joking. I’m joking.
>> AMBER: I think I remembered the last time I literally broke a website and you had to fix it. I don’t know if that’s ever happened actually.
>> STEVE: No, no, no.
>> AMBER: I think I got all the “I break websites” out of my system well before you joined our team.
[laughter]
Now I know where the line is, and there are some things I do and some things I don’t do.
>> STEVE: Right. And there’s some fail safes that you could practice if cowboy coding is something that you’re going to practice, right? Back up the site first. And then that way, you have a restore point if you break something, right?
>> CHRIS: I think, too, that one thing that hasn’t been brought up yet is there are individual freelancers out there and even possibly agencies, not that I’m going to name names, that cut these the kind of things out of their processes to save time and save money, to justify charge, you know maximize their margin on way lower website rates, right?
You have organizations out there that’ll sell you a website for 250 bucks, 500 bucks, right? And you got to ask yourself, what kinds of corners are they cutting? I guarantee you, for those, there’s no repository, and there’s no telling what kind of stitch-together nonsense is in the back-end of those, versus doing it right. And lending itself to that, I can even say, you know… And this is just big caveat. This is probably nine, ten years ago when Amber was still a solo freelancer and I was helping her out, and she was charging a tiny fraction of what we charge now for a website with no team.
I remember I helped her build one website that I will say is still live today. One of our longest running customers, but I built it. I am not giving the URL. Don’t ask me. And Don’t @ me on Twitter, because I don’t even want it to see the light of day for anyone who actually knows who I am because it’s ugly now. It looked OK then. But it was for a company that works with chemicals and oil fields in the Northern US.
I remember I went and found the theme, and then Amber taught me how to look at the front-end of the theme, and go into the inspector, and look at the code, and figure out what variables I need to change, and play around with it. And then go into the customizer and make those same changes to the various files where they were to customize the fonts, the colors, or whatever else.
>> AMBER: Wait, not in the customizer, though.
>> CHRIS: Maybe not. I don’t know.
[crosstalk ]
>> AMBER: That must have a child theme. It totally has a child theme.
>> CHRIS: Maybe it was in a child theme. But anyway, I remember I was editing code, and we were dressed. I distinctly remembered doing that.
>> STEVE: Yes, in the theme editor.
>> CHRIS: Yes, in the theme editor. But it was definitely an adventure, and it’s the, “While I’ve had my hands and plenty of websites, that’s the only site where I’ve touched code.” And it’s still up. And we haven’t had to do much to it.
I know it can be done, to save resources and save money, but it’s definitely not best practice. And that leads me to something I wanted to bring up. What does all this have to do with accessibility? Where does cowboy coding and accessibility intercept? Where is that?
>> AMBER: So part of why I thought it would be good to talk about this, and of course, you both should weigh in, is I think there’s this interesting line with anything, where we’re talking about speed, and if we’re talking about making accessibility remediation, especially of existing sites. Because I think that’s where potentially there could be arguments for using a code snippet plugin, which I consider… I mean, hopefully you do it on staging first, not on your live site. But using a code snippet plugin to add that versus coding your own plugin, if you need to patch a different plugin, or if you don’t have full access to the theme. Or it’s not using your child theme, and for some reason, you don’t want to make one, I don’t know. Maybe that’s [inaudible].
Maybe there is a place with some of these accessibility fixes where you can make things faster and make a website more accessible faster if you bypass some of those best practices. But I also think on the flip side, why it’s important to talk about cowboy coding is because, like Steve was talking in the beginning, it’s about often bypassing processes or best practices. And I think a lot of times when people cowboy code stuff, it doesn’t get full testing.
>> STEVE: Yes.
>> AMBER: And it’s possible that cowboy coding causes more accessibility problems, and things that are cowboy coded are more likely to be inaccessible than things that are not. And I don’t know if you have any thoughts on that, Steve.
>> STEVE: Yes, I mean, I think I would have some of the same feelings about that as I would just any kind of code change when it comes, like, just consistency and technical debt, and no testing of the code, right? And this goes a step further too. And if you’re making an accessibility fix, you should be testing that and validating that accessibility fix.
I have concerns. The technical debt, what happens when you go in and make these changes, and then an actual agency is brought in to audit. And then they’re looking at the code base. And that could be outside of the database, you know what I mean? We could have a client that comes in and they have a code base, they have a custom theme or something. I could be evaluating that just from a coding standpoint. I could be looking line by line and reviewing the code. And if there’s stuff in the database, which is what a lot of cowboy coding would be, something in the database that’s being injected in the page after the fact. And if I’m not aware of that, that could cause a disconnect, because there’s not consistency in the dev process.
However, I get what you’re saying. Like if it’s a page builder, or it’s a plugin that, like you said, you don’t have access, you don’t want to edit the plugin, right?
What we’ve done a lot is in our cousin team, if there’s patches or stuff we have to do with a theme, we actually write those patches inside of our theme. It can be done. I think if you properly test, it can be achieved and you can make accessibility fixes that way.
I would still say that’s not a good way to do it for the long-term, and I still think you have to evaluate, what is your website?
We’ve got personal websites that were, like, “Whatever.” We still want it to be accessible, but it’s like we kind of just throw our personal. We’re like a plumber with…
>> AMBER: I beta test accessibility checker on my live website all the time.
>> STEVE: Yes, so do I. So do I.
>> AMBER: And I’m like, [inaudible] because it’s like a random thing. And I’m like, “Well, whatever. I don’t really care if my blog goes down.”
>> STEVE: Yes. So we’re like plumbers with leaky pipes, right? We have our own websites. We want them to be accessible, but sometimes we’re so busy with work, it’s, like, “OK, do the quick fix.” But that website’s not like mission critical.
>> AMBER: So for everyone listening, our starting price is 30,000 plus for websites, and it’s been a long time since I’ve done under 5,000. But even when we were doing those very small business websites, I do think having a repository and all that, it is worth the time investment as a developer. And I think the ways you can speed it up, you can set up Git integrations with some of the hosts, not all of them, where when you push to a certain branch, it will go to production or it will go to staging. And so you can still test it locally and you can run… I know you just set some of this up, and maybe you could talk a little bit about this for us, like in our starter theme where you’ve changed it, where it’s doing a lot of linting and checking for coding standards and stuff on pull requests.
>> STEVE: Yes. Yes, I mean, part of a growing team, trying to have more consistency, trying to reduce the amount of code review time on my shoulders, right? And utilizing automation where it’s best used. And in the coding process, that’s linting, right? We can do PHP coding standard checks, we can do linting checks, with the PHP and with ESLint on the JavaScript. We run security checks on the PHP. Then like you said, we can run deploy scripts.
So in our Git repository, if it goes in there and it runs those checks, and if they all pass, then it can be merged into production or into staging, and then the deployment script can automatically deploy it then. What that does is that automates the checking process, and that sets a baseline standard for all development going into the plugin.
Now, it can’t validate if the logic of the class or function being created actually works. That’s where unit testing comes in. On the plugin side, we’re doing a lot of that now, writing unit tests for all of our stuff, to ensure that it works properly.
That being said, depending on your workflow setup, how hard you lock down your branches and deployments and stuff, even then, I’ve seen developers overlook those rules.
I put a meme in here that I’ll read. It says the first rule of cowboy code is, if the test fails, remove the test.
[laughter]
So I’ve seen that. So we’ve actually gone a step further. Our linting test can all run locally in your environment. This is going down the more advanced route of development. But all of our linting, we can run them with the NPM run commands. And we actually went further and we installed a package called Husky, which actually, on commit, it runs those checks. And you can’t even commit to the repository if linting and coding standards change checks don’t pass.
>> AMBER: So that’s like a local. You’ll have to link to that. So we can put a link in the show notes for people.
The thing that I think is interesting about this, going back to the whole freelancer is, just because you’re an independent person and you’re not part of a big dev team, I don’t think that means you can’t. You could do this same thing to check, right? Like, check your own work. And if it’s automated like that, it’s not adding a huge amount of time, right? It probably adds time if you have errors.
>> STEVE: Well, actually, the linting on PHP and JavaScript, we have a command that we can run for linting to just check, and it outputs all your errors and warnings. And there’s a fix command as well where it’ll go through and fix everything it can fix, right? Which are tabs and spaces and all that. So you save a lot of time in formatting in that regard.
Now, there is the setup time in this. Like Amber said, you can get GitHub for free, you can run these actions on free public repositories for free. But there is the time investment to get this setup right for your workflow.
From our standpoint, with a growing development team, I think that is a good use of time because it sets a standard. It’s going to make all of our projects so much better. It ensures that the code is secure, that we’re creating for our clients, and I think it’s just a really good thing to do. It’s much more down the advanced route, and its anti-cowboy coding completely. But I think it’s the way to go.
>> AMBER: I think the thing about it, too, thinking about the long term and the quality that you want to deliver. Testing is so important. Even if you’re a solo person or if you’re on a team. If you’re on a team, having someone else look at it too.
We have a dev on our team who I think is fabulous. He does really great work and he was reworking a mobile nav for a client, and I went and tested it. And for whatever reason, I don’t know why, but the skip link was empty. The skip to content text was just removed from the link in what he was doing. I’m sure it wasn’t intentional, but sometimes, stuff like that just happens. So having thorough tests is really important. And that’s something that’s not obvious. The client tested it on staging, and they’re like, “Yes, deploy.” They’re, like, “Go.” And I was, like, “Hold on. Wait, let me test.” And then I tested it, and I was, like, “Uh, no. hold on. This need to be [crosstalk ]” right?
>> STEVE: I think it’s staged. This all slows the process down, right? We have these automated tests, right? These Linting tests, that can run… And you can do a lot of this on your local too. So there’s even another layer on top of that. And then you’ve got the stuff that you can run in GitHub. Then you have code reviews, where somebody reviews the code. But a code review doesn’t necessarily find if things don’t work, right?
A code review is basically like, “Is this code written correctly? Could it be more readable? Does it have all the right block comments and whatnot?” And then there’s this other layer, like Amber just described, which is a functionality test. And she’s like, “OK, well, just because there’s not necessarily a code error, there is an error, because when I functionally check it, something’s conflicting with the skip link. It’s pulling, I don’t know, some JavaScript or something. It’s pulling that title out of there.” Who knows, right? So, there’s a functionality test.
>> AMBER: And I will say Accessibility Checker caught that, because it flagged as an empty link on the top of the page. So that’s another thing. Even if you’re just using a free version of our Accessibility Checker plugin, if you’re pushing something to the header, that’s something that we’ve talked about with our devs. It’s, like, “Go run a scan on the home page and it’ll tell you.” And actually, they also happened to have been in that change inserted and unlabeled field. And both of those got caught by Accessibility Checker. So then I was like, “Well, this is weird.” So then I went and tested it manually, and I saw it and screenshotted it.
So having an accessibility testing tool, and manual accessibility testing as part of your process, just like you would for mobile. I don’t think many of us release code without at least dragging the window more narrow.
>> STEVE: Yes.
>> AMBER: Hopefully, people do that. I still occasionally run into non-mobile responsive websites. I’m, like, [inaudible].
So circling back a little bit. I think maybe it is possible to cowboy code and not introduce accessibility problems if you are really diligent in your testing. But I think you’re probably more likely to introduce accessibility problems. Because typically when I think of cowboy coding, it’s, we’re trying to move fast, and so we’re not being as thorough.
>> CHRIS: Yes. And there’s the old saying, right? Whatever you don’t measure, you’re going to overlook or underestimate. If you’re not measuring your effectiveness, whether it’s code or testing things to make sure they work after you put them on a staging site, if you’re not doing those things, stuff is going to get through that you wouldn’t intend otherwise.
For me, where I draw the line is, if it is such a simple change that it is virtually impossible to throw it up. Like changing one color to another color, or something, as an example. But I don’t know. I’m not a coder. So maybe it’s even possible to screw that up. I mean, you can screw up color contrast, I guess, if you choose the wrong color.
>> AMBER: Or if you forget and you don’t adjust the hover color or something, and you don’t hover your mouse over it, right?
>> STEVE: Yes.
>> AMBER: I’ve seen instances like that. It was fine until it got put on dark background and they fixed the color of the normal state. Is that what it’s called?
>> STEVE: Yes.
>> AMBER: But they forgot to fix the hover. Or they fixed the hover and the normal, but they didn’t tab to it. So they forgot to fix the focus, and the focus doesn’t contrast with the…
>> STEVE: Yes. With CSS, you’re less likely to get caught.
>> AMBER: You’re not going to take a website down, right?
>> STEVE: Yes. But if you’re dealing with server-side languages like PHP, you’re just one semi-colon away from a disaster, right?
[laughter]
>> CHRIS: I want that on a t-shirt.
[laughter]
>> STEVE: Yes. Cowboy code, one semi-colon away from disaster.
CHRIS: Yes. Living on the edge.
[laughter]
>> AMBER: Well, hey, so I found a meme that is a fabulous picture of Chuck Norris. It says, “Chuck Norris doesn’t use web standards; the web conforms to him.”
>> STEVE: So unless you’re Chuck Norris.
>> AMBER: So unless you’re Chuck Norris you probably need to use web standards. And pay attention to your semi-colons and your web content accessibility outlets.
>> CHRIS: Yes. So to close this out here, because I know we’re getting close to time. I think it would be good to wrap up with, you know, if we have people listening who are maybe a little more cowboy-ish in their disposition. They, like, be on the open range, riding their horse. And they’re looking at this other side, right?
We have the idea of all this measurement, all this linting all this stuff. What advice do you two have for them to start to move in the direction of taking more measurements? Being more diligent about testing what they do before it sees the light of day with the end user?
>> AMBER: Can I start with the easy stuff, and then I’ll let you give a more developed answer?
>> STEVE: Go ahead.
>> AMBER: So I think that the easy way is if you don’t normally use staging sites, you should just start using staging site. If you’re someone who wants to edit on the server, you could do that, but maybe don’t do it in a production environment. So that’s probably the number one step, depending on where you are in this.
Steve, you probably have a more concrete answer on how to get out of the not having any automated tests, or if there’s a good place to start, from a dev perspective.
>> STEVE: Yes. I think it’s all about leveling up, right? We all got in the WordPress for a reason, right? If we really wanted to be super nerdy, linting, code checking, we probably would have went and became proper software engineers, right?
>> AMBER: Oh, well, you’re talking about yourself?
[laughter]
Also, on that note, you still have to talk to tell at least one horror story about cowboy coding, because I’m the only person who has taken down a website.
>> STEVE: [chuckles] OK. So I’ll finish that thought, but let’s jump up to that. I don’t know about horror stories. I’ve taken websites down numerous times. I can’t think of how many times I’ve taken a website down. I’ve taken them down a lot, but I can get them back up real quick.
>> CHRIS: Before anybody knows it happens. Yes.
>> STEVE: Yes. And I mean, typically that’s not production, right? I’ve taken a production website down. Let’s be honest, who hasn’t? But it’s typically not production. And when it’s not production, I’m a little less worried about it. But, you know, I think, running a development team, it gets real hard. We still see it today.
We were working on a navigation change, and somebody was checking changes on production. And then we go to production, and the nav’s like totally messed up and doesn’t work, and the developer had no idea. And then so you write that awkward thing, like, “What? Are you working on production?”
>> AMBER: Yes. Like, “What are you doing, and why?” And this, by the way, was a high traffic website.
>> STEVE: I will say probably the worst that I have ever seen is… And this gets a little more advanced, but just being very mindful of your API connections.
We had a contractor working on some feature on a website and was working on a staging server. So we’re trying not to cowboy code, right? We’re working on a staging server, but all the API connections were not set in test mode.
>> AMBER: I know where you’re going with this. It was horrible.
>> STEVE: The developer said, “Well, this is a testing environment. I don’t want all these real users in this test [inaudible].
>> AMBER: “I’m going to delete all the users.”
>> STEVE: “I’m going to delete all the users,” right? And we have a membership, Restrict ContentPro or something installed on the site. And if you delete a user, Restrict ContentPro cancels a membership, which cancels a subscription in Stripe.
>> AMBER: And if you don’t have Stripe in test Mode?
>> STEVE: If you don’t have Stripe in test mode, you cancel hundreds of customers’ subscriptions on a client’s website.
>> AMBER: Or it might have been thousands. It might have been thousands.
>> CHRIS: The trauma is real. And I know exactly what you’re talking about. And I even remember. Even though I didn’t really experience the trauma directly, I just know that I didn’t see Amber for about four days. And Steve, I think it was probably about the same for your wife, Jennifer.
>> STEVE: Yes.
>> CHRIS: She probably didn’t see you for a while. And thankfully, the contractor stepped up and fixed the issue, too, without charging us additional funds to do it. But yes, that was the worst. That was the worst.
>> AMBER: Yes, that was definitely, I think, the worst mistake that anyone from our company has ever made. And it was an accident, and [crosstalk ]. And we’re real careful about putting everything into sandbox mode even for what we think is a tiny change. It does not matter; it’s always in sandbox mode now.
>> STEVE: And the client was not happy in the least, and we had to take that beating. Even though it wasn’t my fault or it wasn’t Amber’s fault, it was somebody we had contracted to who was at fault. But we had to take the beating.
>> AMBER: We had to be on the zoom calls, we had to be on the end of the angry base cam message.
>> STEVE: Yes, we had to take it. The contractor did come through and write a script to where we didn’t have to manually recreate all these subscriptions. So he did his part. And it was an honest mistake, but that’s why having these processes… And we have a document about how to set up a staging environment.
You set up a stagings environment, you disable emails, you put all APIs in test mode, or disabled them altogether, you password-protect the site. So I think having processes helps mitigate that. Because that was a nightmare. It was bad, and it potentially could have ended really bad.
>> AMBER: Yes. If we had lost that, I mean, that client had thousands of members, some of whom paid close to a thousand dollars a year. So think about all that money if we had not been able to get those recurrent subscriptions recreated.
>> STEVE: I mean there could have been litigation if there was a loss, you know, they could prove lost revenue.
>> AMBER: Yes, so circling back, deciding on a process and documenting it, is that the first step for somebody who’s trying to…
>> STEVE: Yes. Yes I think somebody on the team has to own. Somebody has to start owning that process. Your process doesn’t have to be perfect, it just needs to be defined, and it needs to be something that’s iterated on over time.
I will say, if you’re operating with the mentality that you can just go into a customer’s website and fix something in five minutes, then there’s probably a lot of area for you to level up your game as a developer and as an agency to serve more hiring clients, and get the money that is needed to properly version control, and have good processes around what you do. The more work you take on, the more important that becomes.
>> CHRIS: That’s something we didn’t even touch on. Once you have about 50, 60, 70, 100 customers, you can’t even keep it straight anymore. Like, what you did last week, let alone last year.
>> AMBER: Yes. So you want the version control history is, so you know who did it, when they did it. And ideally you’re writing comments on your code, right? So you’re maybe explaining why something is the way it is.
>> STEVE: Yes. I can’t remember what I did six months ago, let alone three years ago. I’ll go through and read my own comments, and that goes back to standards too. And fortunately in WordPress, a lot of the work around standards is done. Now, whether or not you agree with those standards… Everybody has their PHP linting or the WordPress coding standards. Some people have opinions, right? You know, “Can I use a short array tag or do I have to use the long array tag?” Everybody has their opinion, but WordPress has already done a lot of work around the standards. There’s standards that you can implement in your code now for checks.
We didn’t touch on it too much there, but there’s linting for accessibility as well. You got Axe Linter and there’s, like, Sally or Pally? I don’t remember what it’s called. There’s Lightbox, and these are all APIs that you could run on your code too. Now, it doesn’t work super great for the server side stuff, like PHP because it requires a server. But if you’re doing JSX, making React stuff, it can check. Or if you’re just writing straight HTML, you could run Axe Linter. So there’s just a lot that you can do to level up your game. And start defining that process. Start with WordPress’s coding standards. You can modify those to your own needs, but they’re already there.
>> AMBER: I think there’s an argument though. I know some people don’t love them, but I think that we have found as we’ve rolled out WordPress coding standards to more of our point.
I think you were working on a plugin that I wrote, back in your [inaudible] like, years ago. So it’s probably really bad, right? You were rolling it, out coding standards to that.
The argument, I think for doing it, even if you’re, like, “Oh, I don’t like this one rule or whatever,” is that the more consistency there is in a WordPress website, the better performing that website is going to be overall. And then also, if you’re thinking long term on your business, I mean, why do you have your business? Whether you’re an agency that builds websites for clients, or you’re a plugin developer who’s coding plugins that you’re either giving away or selling? What is the end game? And I think meeting WordPress coding standards on everything you do. If you’re thinking that there might be any possibility of wanting to sell, I think is going to make your products or your client portfolio or whatever it is that you’re selling look more appealing to a buyer if they can just go put in the WordPress linter and see, “Oh, it all fits,” and there’s no coding standard problems.
>> STEVE: Also, if you want to operate, and you’re building stuff in a WordPress environment, doing it the WordPress way is probably the way to do it. We can argue whether or not that’s the right way. But you’re going to get that big client, and they’re going to be, like, “We’re hosting on WordPress VIP.” And WordPress VIP is going to be like, “Well, your theme or plugin doesn’t follow our coding standards.” But if you start implementing that now, that won’t be a problem.
If you want to work with automatic in some way, and they review your code, and they’re like, “Oh, they do things the way we do it. I like this. This works.” It’s like, at some point, if you’re making a product or you’re making a theme, you start leveling up, the hygiene of your product becomes very important. What does it look like?
Now, this is going very far down in the opposite direction of cowboy coding, but it’s not like you have to swallow the whole pill. You can just start with baby steps and just start leveling up your development process, having processes.
Like Amber said, it’s so easy nowadays to make a staging site. It used to be a nightmare. You’d have to import the database and update all the tables and all this stuff. But now, most web hosts have one-click staging. And it’s super easy to set up a GitHub repository, and it’s pretty easy to set up deployments and stuff.
>> AMBER: I think if you go to “Learn.wordpress.org,” there’s some tutorials on Git, and that kind of stuff. Or if not there, you might check “Wordpress.tv” if you’re someone who’s never used Git and you’re not sure. I’m sure there’s got to be tutorials on how to use Git and how to put it into your workflow as a developer.
>> STEVE: Yes, totally.
>> AMBER: Yes. So we ended up saying don’t be a cowboy coder. Don’t be a cowboy.
So for a long time, there was a rule at our company that I was the only one who’s allowed to cowboy code, but now I don’t even have a code anymore, and I’m also not allowed to cowboy code. So don’t do it. But you can enjoy your cowboy beer.
[crosstalk ]
>> CHRIS: Following the cowboy metaphor, just slowly leave the range. Put your horse in the stable. Maybe take the horse out on personal projects that don’t matter a whole bunch if you need to get your thrills in. But, yes, cowboy coding probably needs to go away for anything that matters.
>> STEVE: Yes, probably. Sorry to burst the cowboy coding bubble, but there’s a better way.
>> CHRIS: Yee-haw!
>> STEVE: Yee-haw!
>> AMBER: All right.
>> CHRIS: Thank you all for being here.
>> STEVE: All right. See you.
>> AMBER: All right, we’ll talk to you soon.
>> CHRIS: All right, bye.
>> CHRIS: Thanks for listening to “Accessibility Craft.” If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release.
You can find “Accessibility Craft” on Apple Podcasts, Google Podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating “Accessibility Craft” five stars on Apple Podcasts.
“Accessibility Craft” is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones.
Steve Jones composed our theme music.
Learn how we help make thousands of WordPress websites more accessible at “EqualizeDigital.com.”