Welcome to Press This, the WordPress community podcast from WMR. Here host David Vogelpohl sits down with guests from around the community to talk about the biggest issues facing WordPress developers. The following is a transcription of the original recording.
David Vogelpohl: Hello everyone and welcome to Press This the WordPress community podcasts on WMR. This is your host, David Vogelpohl, I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you hear every week on press this as a reminder, you can find me on Twitter @wpdavidv, or you can subscribe to press this on iTunes, iHeartRadio, Spotify, or download the latest episodes at wmr.fm. In this episode we’re gonna be talking about one of my favorite topics, and that is avoiding time killing tech debt on WordPress builds. And joining us for this conversation I’d like to welcome Jon Martin. Jon, welcome to Press This.
Jon Martin: Thanks so much, it’s good to be here.
DV: I you know I practice pronouncing Hallum before the show but of course I messed it up right in the beginning John sorry about that. Awesome so for those listening with John’s gonna share his his thoughts on the impact of tech debt to WordPress development teams like what does it mean to have tech debt and how’s it affect you? How you can think about reducing your tech debt on every project. And then why you have a responsibility to share tech debt considerations with your clients
JM: if you’re working in a freelancer agency capacity. So I love killing tech debt. I love eliminating it is one of my favorite topics.
DV: We’re going to get down to John’s thoughts on the topic but before we kick that off, John, I’m gonna ask you the same question I asked every guest Tell me briefly tell me about your WordPress origin story. When was the first time you used WordPress
JM: so I would have been in the early 2010s weren’t really sure the correct expression for that time period. So I actually started myself and I’ve been CEO of how we started an agency in 2008. And at the time, WordPress was still very much a blogging platform. We were building websites that have lots of rich content on it. So it’s a bit of a dirty word, but we did use Joomla at the time. But then rather than
DV: Joomla is a dirty word. I like all open source CMS personally.
JM: Yeah, we’d like to say it’s a great project. I think the the key thing for us is that over time, where Joomla was really really strong when WordPress put out custom post site support. That was when things really really changed in WordPress for me that elevated it from this from as it was known as a blogging platform to being a proper fully fledged CMS that you can do all kinds of sites on whether it is for you know, really small one one person business or freelancer or whatever, all the way up to massive enterprise grade, complex websites. And I think really, really for me, that was a killer decision on their part because it’s part of the reason why WordPress is so popular now. So yeah, so that was that was when she started to use here. Sasha the story before that really is myself and now CEO of how we were in a band together. And we have this bright idea of thinking, Well, you know what, it’s awesome more sort of equal time on the road and it’s really hard to get time off of my current jobs. So we thought, You know what, let’s start an agency and become web developers because that will really help getting all that time back then that was a great decision. I’m really really pleased with it that but he’s also certainly a naive decision because thinking that working for yourself gives you more time was definitely a mistake that I think we recognize a little bit later on. And before that point, you know, I knew a bit about SQL and I’ve been building computers since well, actually since graphics card very supportive for colors. So for anybody else who knows what CGA is that’ll help you know there how old I am. But yeah, so really, it was when CPTs came out. That fat changed everything for us. And we started to use WordPress pretty much overnight, actually, that became our chosen CMS and we haven’t looked back since and, you know,
DV: out of all the people I’ve asked this question to you very few have actually clued in on how material custom post types were relative to their WordPress origin story. And it’s funny. I have a similar story. I founded an agency in 2010. So a little bit after y’all but when the custom post it kind of already got in. We started building with Joomla and switch to WordPress for similar reasons, but it was this custom post types and custom meta fields that I agree and I actually presented this way various format is that it was this kind of moment when WordPress really became a true CMS. A year after that WooCommerce came into existence WP Engine came into existence, a lot of other brands of WordPress space, it is such a transformative time. It’s interesting to hear you kind of reference that is the root of your origin story. They were telling me though, about how um, and you know, the founding moment there if you will, but could you briefly tell me a little bit about how um, and what you do it?
JM: Yeah, sure. So So actually, that agency we found it wasn’t how it was how we later motor. Okay, okay. Well, the main reason for that actually is because, you know, back in back in those those older days, there was a very quite distinct difference between, you know, we build websites versus we do SEO and all these kind of things. And it wasn’t really that many around the world integrated approach and actually thinking about things like user experience, and how does that work with SEO and development, all that kind of stuff. So, so that was actually why we ended up later Later merging with, with Allen Milan been around for about 20 years and our founder set up pretty much right back in the beginning when SEO started to become a thing. So yeah, so we merged the two agencies. Six, seven years ago, maybe a little longer. My memory for data is not great, I must admit. And then And then really, yeah, that’s that’s become our approach is this this full integrated approach about mixing all these different disciplines all together to help people to see the line? So now we do PPC, SEO, digital PR, obviously, web design and there’s brand stretches, digital strategy, and all this kind of stuff, all of these disciplines that you really need to have a good strong digital presence these days. What’s your role there, the company? So my, my job title was technical director. So I’ll be honest, doesn’t really quite covered everything that I do. I run the development team for a long period of time. So all the all the WordPress will be was was under my directorship. I’m pleased to say we have far far better developers in the team than we then Julio and I ever worked when we first started out, which is the reason why we’re doing much better these days. And we understand things a bit more so. So I run the development team for a long period of time more recently on a cost of data team as well. So that means I get to play with machine learning, Python and Bartek and others are playing though I gotta imagine all this playing.
DV: Doing cool separate clients is gonna result in some tech debt along the way. And so I’m curious like how you think about like, what are the common types of tech debt and and maybe specific to WordPress. Those for a minute, but like, how do you think about that as you think about, you know, how and how y’all manage your tech debt, like you’ve locked it into types with WordPress built?
JM: Yeah, we do. I mean, not. Not necessarily. We’re doing kind of language we don’t necessarily categorize things or go through a district process for categorizing, but really, they do fall into three different buckets. One of them is when you build bad code on top of existing codes, and that might be because you’re maybe you make some mistakes in the past that might be an issue from Heritage websites and somebody else whatever the reason is, so that’s the sort of first bucket. The second one is building code that isn’t necessary, and maybe just isn’t necessary right now. You know, I’m sure we’ve all been on the end of feature requests from clients and brands that we work with where they really keen for a particular thing, but actually might not be the right thing, in terms of getting actual value for the customers. And then the third one, which is the biggest one we see actually is building features that should actually really be on a different platform. So understanding that kind of architectural piece about okay, what are the different bits that we’re plugging in here is a CRM here is the website, which fundamentally really is about marketing the business. Here’s your order fulfillment platform, all those sort of different.
DV: Let me ask you, let me ask you a fundamental question here like you you’ve kind of listed the three types of sounds like these are the three types of tech debt you want to get rid of write bad code on bad code code, that’s not necessary features that can be done on another platform. Like isn’t there a fourth bucket like features you want that are valuable and therefore the tech that is maybe good in that case? Is that fair to say? That’s a fourth bucket.
JM: Yeah. 100% I mean, not all technical debt is bad. There are you have to have to accept that pretty much any feature that you’re going to build will accrue some type of technical debt and you’ve got to make a call about whether that technical debt is good or not. Some is good, some is bad and really dependent on is that keyword I said before is about value. Are you going to get the value that you need for that thing? More importantly, is the customer, the ultimate customer, not your client, but they’re their customers? Are they gonna get the value for it? That’s usually a pretty good Guiding Light as to whether to accept that technical debt.
DV: Yeah, I want to kind of deep dive into you know, how you think about that quote, worth it formula for when it’s okay to accept or not but it’s it’s good to think about a get a good understanding of how you think of the different buckets of types of tech debt, and particularly those you might want to want to optimize to remove. What I’d like to do next though, is get an understanding of like, was it was there a thing that kind of drove you over the edge to focus in this area, but we’re gonna take our first break and we’ll be right back. Time to plug into a commercial break. Stay tuned for more pressing this just a moment. Hello, everyone. Welcome back to press this the WordPress community podcasts on W EMR This is your host, David Vogel. Paul. I’m interviewing John Martin about voiding time killing tech dead. John right before the break you were explaining that the way you think of the three types of tech debt that you might want to eliminate is building bad code on bad code creating code that’s not necessary for the success of the site you’re working on. And then maybe building out code for features that can be better served on another platform. Before we kind of get into like the the quote worth it formula, though. I was wondering, was there like a particular I don’t know time and your your journey are a particular instance of tech debt that that kind of surface this for you is a primary focus area for how?
JM: Yeah, absolutely. There’s one real landmark project that started to get me thinking about this about four or five years back now. I’ve seen plenty of other cases. To businesses accrue time, all the time, not just through WordPress through all kinds of things, actually businesses accrue it through their operational processes as well. If you have to be a technical thing where you create that deck. One, the One story that really stands out my mind more than any is client, we work with a relatively small company we did a lot of paid media work for them. Selling essentially selling stuff online. It was a eCommerce business. And they they had traditional kind of mail order but a lot of their work and they were trying to drive more traffic online so they didn’t have to go through mail order will be managed through the website and they came to us because they’ve had a site built for them is completely bespoke. And they’ve been around for about 10 years at that point. So it was getting pretty old starting to creep a little bit. You know, standards and move on. Technology’s moved on, it’s time to have a bit of a rethink. So the client sat down with us, they started debriefing all the different things they did on the website. And it became really clear very quickly to me that there was all kinds of business logic and business operational stuff that had been built into the website. And that was logic that leads to orders and is quite specific to the way that they work suppliers. So I won’t go into the detail but I have quite a complex arrange between the suppliers and how they fulfill orders and whether it got shipped into their shop before it sends out all this kind of stuff. So it’s all quite complicated. Now the the business owner and the previous about how they work, eventually built a system that pretty much manage that entire thing was a really, really good system at the time and genuinely helped that business grow massively. Now, what they haven’t really thought about is that all websites eventually have a shelf life that they will become into life at some point, just like any software and in the marketing world. That shelf life is really relatively short compared to, you know, for example, if you invest in a CRM as a business will normally have that kicking around for quite some time now it’s about 10 years, if not more websites. Generally speaking between sort of two to five years we find most at least the big brands tend to rebuild every three years or so. So the problem then was that they built all of this complicated logic into the existing website, and they had to rebuild the entire website. And all of a sudden you have to rebuild all this business logic as well. Now, we costed the project up and it basically ended up being about half of the annual turnover at the basis just to rebuild what we already had. And that really started to get me to think about this thing is that well, okay, if they approach the problem in a different way originally, for example, let’s think about the different things that we’re trying to achieve at a website. You know, this is from marketing was this for selling products. This is for order fulfillment, this is best for managing my business process with supplies all those things, and thought in a bit more of a modular way about that, then it would have been a much different situation for this client, that she was there. It was a real problem for them because they had a website that was essentially where they’re making money from. It was creaking quite a lot because it’s quite old. But at the same time, it was going to cost so much to rebuild that entire website and made the project very, very complicated. We managed to find some pretty clever but also not nice work around to the end to try and use what they already had and integrate it but we can’t cite but you know, ultimately ended up being a much more painful much slower and much more expensive than it needed to be. If that architecture been thought about originally.
DV: I have so many projects I want to forget about that. Were just like that, and I can I can picture it now I’m taking me back in time. So like to me that sounds like a pretty clear it’s a very, I think, in a salient lesson to think about the kind of cost to the business relative to the refactor that you’re planning. And to me, it sounded like the clear answer was you needed to architect it differently. And that’s kind of maybe a clearer path if you will to like what you should do. But I think like a lot of teams when they think about tech debt, it’s like they think like, Okay, well, it’d be cool to do this thing, but is it worth it?
JM: Is it worth me maintaining this thing over time? So I’m just curious like how you think about that formula
DV: when, like, When is it okay to introduce tech debt? And how much just how do you think about that formula?
JM: Yeah, you touched on a really important point there is that, you know, you think about the nature of developers, developers get into this because they love doing cool stuff. And that’s, you know, a big part of our motivation is to learn how to do new things, new technology, you know, new JavaScript frameworks, whatever the thing is, and that naturally gives us the motivation that becomes to build cool stuff, but we don’t necessarily think long term about that, you know, we’re still going to maintain it. You know, my wife would love to get a hot tub at my house, but I know that somebody is going to clean that and I’ll be honest, I don’t believe anyone who cleans it, is that type of thinking anyway. So it’s a really, really, really good question to think about, is it actually worth it in the first place and if we break that down a little bit, there’s a few different things you could be thinking about, first of all, thinking long term, what is the total cost of ownership and building that thing of testing it and maintaining it, and then weigh that up against the value that we get? So for example, there may be a really simple way that you could solve that problem. using spreadsheets or using a slightly different architectural things where maybe somebody internally at the company manages that for a short period of time. And it would be cheaper to do that and more effective to do that than it would be to build this really complicated feature. But when you actually look at the total cost of ownership, it’s going to cost more than it would be for somebody spending a couple of hours a week to do a particular thing. Don’t get me wrong. I’m a big believer in automation. technologies should be automating as much as possible to avoid that kind of admin but
DV: you’re signing up and you use like this manual approaches to like try something out before you code it to make sure that value is going to be there. I mean, I get the idea of like simplifying this factor, like, Can we do this manually instead? Just curious if you’ve ever approached it from like a testing perspective to like, see if the ultimate return is worth it?
JM: Yeah. 100%. So the I’m a big believer in Agile methodology. And fundamentally, one of the big key tenets of Agile is that you build the right thing at the right time. And you focus on gaining value as quickly as possible. So you want to be building the minimum viable product. Now, that means that you don’t necessarily have something that’s fully feature rich at that point. But it gives you a platform where you can then start to test it, you know, are you actually getting the things that you want from that? Are your users responding to it? In the way that you expect to anybody who’s worked within UX or web dev will know that quite often will get requests from customers because they think that their customers, but actually do they really want it? So that’s another really good question to ask is, once you’ve kind of thought about that long term view, do the people going to use the website do we know that anyone to use it or do we need to test to see if they want to use it? And then once you’ve done that test, we can work out what we shouldn’t have asked for it and whether we should back off and actually put our investment elsewhere.
DV: So it sounds like to kind of recap this thoughts and I liked your idea of looking at the total cost of ownership long term you know, I think a lot of times teams think even the people you know, quote, ordering services from the teams think how many hours or weeks or spreads or points or whatever is this thing going across to build. But then, you know, you need to take into account that you know, how much how many hours or weeks or spreads or points is it going to take to maintain and then to use that balance against the value you’re getting out of maintaining that activity. You’re obviously that’s a sound piece of advice. But then you’re also thinking like, Well, is there something I can do to test this to see if my assumptions are correct? Does that sound accurate?
JM: Yeah. Absolutely. Absolutely. And the only bit that we didn’t touch on is the that we spoke about a little bit earlier, which is about architecture, is there a better way that we can structure this to to make it better and that time to object programming and stuff that I’ll probably touch on a little bit later.
DV: Yeah, the architectural considerations also, like I kind of wrote down how you were like, is there a way we can change the specs? Is it as in my stakeholder training or talks I often say you know, spec to lodge right? Ask for what you really need to lodge. And so asking those will lie and be really needed and what about this? Questions have been I found to be very critical. So it sounds like that’s a key part of how you’re thinking about this.
JM: Yeah, cuz every minute that that site is in development is a minute that it’s not getting value in front of customers. And that’s the easy way of thinking about it. You want to get launched as fast as you possibly can. And then test, monitor, iterate, learn, you know, see where you go from there, but only because you’re doing that based on actual data rather than what you think is right. Because quite often they’re not the same.
DV: Yeah, I love that point. Every minutes. It’s in dev, isn’t it as a minute you’re not using it figure out and I’ll say ties back to kind of ties back to another mantra I have and project management and stakeholder management, which is the two best words and getting a project on our face to write. How can you talk yeah, I love that when I when I’m dealing with stakeholders, or when I have a stakeholder is a powerful, powerful part. Okay, cool. Um, let’s talk next about how what teams can do to reduce tech debt. But before we do that, we’ll take our last break. Time to plug into a commercial break. Stay tuned for more pressing this in just a moment. Everyone welcome back to press this WordPress community podcast on W EMR. This is your host David mobile Paul, I’m in the middle of talking about avoiding time killing tech debt with John Martin of how John right before the break, we talked a little bit around your worth it formula I really liked your notions around reducing specs. And thinking about TCO and, and kind of taking an iterative testing approach. But let’s dig into now what teams can actually do to reduce their tech debt and WordPress builds. What are some of your favorite techniques for reducing tech debt?
JM: So there’s all kinds of technical techniques you can use and you know some of them you’d be familiar with so that you won’t, but actually the starting point for me is, is a much more kind of soft approach towards talk to your clients. And you got to remember that ultimately, your clients are these brands come to us because we’re the experts. They need our advice and it’s quite easy to fall into the trap that, you know, we’re there to just do what they want, what we’re there to do what they want us to do, but actually, we’re there to challenge what they want to do and to try and improve it. So the first thing you can do is talk to them about it and explain okay, if we do that this is going to be the long term effect of it. You know, it’s gonna take us an extra day worth of testing. Every time we do a release, it’s going to add a couple of hours or two every time we need to maintain the website and update all the plugins or whatever it is. But by raising that awareness, we’re having those conversations with them. You can get the client to be part of that discussion. And then eventually they become part of the problem solving with is well, we have to educate our clients all the time, simply because they don’t know some things that we do. If they did, they wouldn’t become tools in the first place. So actually, that’s the starting point. He thinks remember that as well as simplify things. Again, people aren’t necessarily as technical as we are. So use analogies to talk about it. I always find that houses are a great energy. Everybody lives in the house. Most people have got some experience of doing some kind of house improvement. So it was quite easy to use that energy to fix things. So that’s the kind of the the first point really is to get a client or cycle those conversations. The next thing we we’ve touched on before which was to have that long term view or to total cost of ownership. And ask yourself those questions and questioning every feature request. But being a little bit more sort of technical and how you would do this on the job. Simple things you use WordPress standards you know, there are standards that are there. They do exist for a reason. Now, they will help us the developer and maybe you work on a project that you put it down for a year or two and then you come back to it. You’ve got to refresh your memory and you head back into where you were when you first built it using standards will help. They’ll also help other people. So if you weren’t within the team, it means you’ve got this common language that everybody can can operate from which is really, really useful in terms of efficiency and, and helping with documentation and all these types of things. So that that’s kind of kind of a softer way of reducing your technical debt by having standards that anybody can work. It also helps you know, the time may come where some other WordPress developers are working on that project. And it helps them to think of it as a way of paying back the community and making it easier for your fellow developers. So that’s, that’s a, you know, a good point around kind of standards and make it easy for yourself and others. The next one is more about great. Great code of industry, affectionately known as Uncle Bob, who wrote a wonderful book called The clean coder many many years ago. I would highly recommend any developer read that book because they haven’t read it. In fact, I’ve made it mandatory reading for a development team, for anybody who joined the team, mostly because he’s got such a good approach towards it talks about unit testing, all this kind of stuff, but fundamentally, a lot of it is around how do you write code in a way that makes it flexible that you can very quickly iterate and change and add extra bits into it. One of the big points that he talks about is about refactoring often, and this is the main thing to take from it is that you write a piece of code that doesn’t necessarily mean that piece of code is finished. There are things you can do to optimize it to make it more portable to make it more modular or or make a test better, whatever that particular thing is that you need to do to spend time refactoring code. It can be really, really hard to do when you’re up against it or you know, maybe it’s one timeframe for a budget. But ultimately, that’s the type of thing that will stop you accruing technical debt and actually, usually that’s the way that I see it gets forced in, but as a project deadline in place, you’ve got to hit that deadline. Absolutely. You’ve got to hit it, but it’s better to flex the scope than to write bad code that you’re then going to,
DV: I guess, educate those clients about that too, because like I’ve never met a developer that didn’t want to refactor. Code. It’s always the timeline. It’s against it. Um, okay, so here’s the last little bit I’m just curious if you like us, if you think of things like offloading and using off the shelf plugins is another way to help avoid tech or another ways to avoid tech debt. Is that in your list as well?
JM: Yeah. 100% So that’s a good way, but it’s a good way to do both actually, you can avoid technical debt. But you can also and this is you know, WordPress is one form of BMC. It’s so active, equally, that can also be its worst enemy. There is a plugin that does everything. And there are also lots of plugins that have been built for a very specific purpose, but they don’t necessarily match your own plugins. So I’ve seen this particularly with some of the developers that like building sites using plugins and kind of the more point and click approach towards things rather than coding it from scratch point of view. People tend to throw plugin at things. We’ve worked with websites that have had over 100 plugins and a bunch of them aren’t maintained anymore. There are security issues all over it. You try and do the release rate. You spend literally four days testing it when you could have done that in a couple of hours. So So plugins can be good or can be bad. The right plug in at the right time was a wonderful, wonderful thing. The greatest strengths of WordPress, but the wrong plug in at the wrong time can also be severely damaging. And actually can be one of those biggest sources of capital that
DV: I’ve had a project like that for sure. Well, John, this has been incredibly insightful. Thank you so much for joining us today.
JM: My pleasure.
DV: Awesome. If you’d like to learn more about what Jon you can visit hallam.co.uk. Thanks, everyone for listening to press this WordPress community podcasts on WMR. Again, this has been your host David Vogelpohl. I support the WordPress community as part of my role at WP Engine and I love to bring the best of the community here on Press This.
