This conversation with Beth Tucker Long (@e3bethtl) is the one of a series of interviews Campbell Vertesi (@CampbellVertesi) and I carried out in preparation for Drupal maintenance support plansCon Asia in Mumbai. Now, we’re sharing all the good stuff we captured but didn’t have time to cover in 40 minutes in Mumbai.

Our session, Meet PHP-FIG: Your community just got a whole lot bigger, Drupal maintenance support plans is about Drupal maintenance support plans 8’s membership in the new, interoperable PHP community. We’re covering the basics of what the PHP Framework Interoperability Group (PHP-FIG) is, what the various PSRs are and do, talk about testing and dependency management, and what it means to be a part of the new PHP community — including having better architecture, cleaner code, and more interoperability. All of this adds up to a big move to get projects “off their islands,” saving developers a lot of code, and companies a lot of money, among other benefits.

I apologize for the poor audio quality in this recording and hope the quality of the conversation makes up for it.

Selected quotes from this conversation with Beth Tucker Long:

“All right. Hello, Drupal maintenance support plans. My name is Beth Tucker-Long, and I am so excited that Drupal maintenance support plans 8 is out. Way to go! We’re very proud of you. I am really excited about Drupal maintenance support plans 8 because it represents so much community involvement, working together. I’m so excited that we have so many big projects from the PHP side of things and the Drupal maintenance support plans side of things working together, and I just can’t wait to see, with all this brainpower that we have merged into this project, where we go from here.”

“I really love the fact that now we can say, “Hey, we are all PHP developers, and these are the technologies that we use to help us, and as PHP developers, we are putting forth these standards, so we can all work together and not be so splintered.” That was my main motivation for supporting FIG.”

“As long as we, as a community, are encouraging new developers to be FIG-compliant as they come into it, non-FIG-compliant code is going to start looking like old legacy code.”

“So, writing a quick and dirty thing 10 times is going to take longer than writing it the right way once and being able to reuse it.”

Guest dossier
Name: Beth Tucker Long

Work affiliation: Treeline Design

Twitter: @e3betht

LinkedIn: Elizabeth Tucker Long

GitHub: e3betht

Blog/Website: “A little of both” http://www.alittleofboth.com/about-me/

About: Beth Tucker Long is a PHP developer and co-organizer of Madison PHP. Beth is a firm believer in promoting community and mentoring. She runs Treeline Design, a web development company, and Playlist Event Music, a DJ company, along with her husband, Chris.

Interview video – 27 min.

Full conversation transcript

jam: We are Campbell Vertesi … My name is Jam. I work for Acquia. My title is Evangelist and I’m in Developer Relations. We have a special guest today. Would you like to introduce yourself?

Beth: I am Beth Tucker-Long, and I am an independent consultant working with PHP. I do work with Drupal maintenance support plans on a number of my projects and lots of other things, because as a consultant, I work on whatever you’ll pay me to work on, so … the life of a consultant.

jam: Right. Over the last however many years it’s been, you were actually, in a way, at the center of what I like to call the PHP Renaissance, so you were definitely a keen observer of this coming together of all these different PHP technologies from being very disparate, siloed implementations of the language back to being something like community. I’m thinking particularly of your role at Drupal Update.

Beth: Yes. I worked at Drupal Update for seven years. I was involved in Tek when PHP-FIG was started at php[tek], and it was a very exciting time. Also, I was doing consulting then as well, so it’s an exciting time for me as well because having to work with all these disparate technologies that did not work well with each other at all was frustrating, and now it is becoming a much happier place for people to work together.

Campbell: One of the things that we’ve talked about with some of the other people is exactly what you say, that consultants for a lot of developers out there, we have to be able to jump between different technology stacks, between different frameworks. This “FIG era” makes it a lot easier for that. Was that a founding motivation for you to get involved in this, or were there other things behind it? What do you think is the best benefit that made you wanted to get involved in PHP-FIG?

Beth: Sure. I should clarify. I’m not directly involved in PHP-FIG because I’m not a project owner. I am just a big supporter of what FIG is trying to do and a big encourager of trying to get other people who are project owners involved in FIG and encouraging a few people to follow the standards that FIG is setting forward. As a consultant, I have seen so many different people’s code, and I have tried to work to get so many different people’s code to work together and without any standards … It was a very frustrating time, shall we say. So many people and so many projects had this pride of, “Well, you can obviously tell people are working on my project, because their code looks like this.” While that is a neat thing to be able to say, “My code looks different from everyone else’s because I am an ex-application developer,” it makes it really hard for anyone who has to come in and work with your code who is not familiar with that, or who has to try to get your code to talk to somebody else’s code. So, I really love the fact that now we can say, “Hey, we are all PHP developers, and these are the technologies that we use to help us, and as PHP developers, we are putting forth these standards, so we can all work together and not be so splintered.” That was my main motivation for supporting FIG.

jam: It makes us much more efficient developers. Not only can we reuse a lot more good supported code but once we’ve learned a set of principles as long as whatever else we want to work with is meeting PSR standards, for example, then we can probably jump right in to them and get to work.

Beth: Definitely, even projects that don’t support the FIG standards yet. I think it still makes things easier as a whole because so many projects are becoming more open to working with other projects so even if they haven’t necessarily gotten all of the standards, at least projects are now aware that people want them to work together and so the development that’s happening moving forward, even if it’s not officially FIG-compliant, seems to be supporting the mindset of “We need to work together,” and “I want my code to be reusable in other places and easy to be reused.” Even if projects aren’t necessarily on board with FIG, I feel that just the landscape mentality has changed as a whole to something more positive because of the work that FIG has been doing.

jam: So, set the scene. You were probably even a co-organizer. You were at php[tek] when late one night, I don’t know how many people had this crazy idea. In German, we might call it a “Schnappsidee,” which is the kind of idea you have when you’re having schnapps. Like, “Well we need to … this all needs to … let’s make a standards group, let’s see.” You were there, right? Set the scene. How was that? What was going on?

Beth: Actually, I was working at that time. So I was in the building but not in the room when it happened but the stories that I’ve heard. A dark, hazy room with lots of alcohol and lots of cheering and yes. You know? Like all great ideas are born, right?

jam: Yes. So, Cal Evans told me that the people that were in the room thought it was a great idea and put this thing together and then there was a lot of hate. What happened next?

Beth: Yes, there was a lot of hate afterwards. I feel that with most landscape-changing decisions … as a species, we really dislike change. So, anytime there’s something new, there’s always resistance. This was a really big shift in mentality, and there was a lot of animosity about, “Who do these people think they are telling me I have to conform to the standards they think are best?” There was a lot of, “I’m fine if we all get along as long as we’re doing my standard, not yours.” So, right away, the animosity I felt at least was not necessarily towards the idea of standardizing and working together, which is nice, but there was a lot of animosity about whose standard we were going to use and why certain people had the right to tell other people to standardize on which standard. That took several years of working through and probably still isn’t quite officially worked through but it is getting better.

jam: I think also that the name change that the group underwent fairly rapidly also helped the shift in perceptions. Originally, it was founded as something like a standards, a “PHP Standards Group” or standards something.

Beth Yes, “Standard Compliance Group” or something.

jam: Right and renaming it the Framework Interoperability Group immediately gave it a much more positive spin.

Beth: Yes, it did. Although then, there’s a lot of complaints about, “Well, I’m not a framework but …” you know. So, you can never make everyone happy but it does put it in a much more positive light. Like, “We’re all working together. Let’s embrace the part of the idea that everybody seems to like and then we’ll work on the parts that people don’t like.”

Campbell: With this in mind, what do you think is the most important PSR in terms of actually unifying what people do?

Beth: The actual FIG PSR, you mean?

Campbell: Yes. You’re allowed to choose ones that haven’t been accepted yet. We won’t tell.

Beth: Oh my goodness. The most important FIG PSR…

Campbell: In terms of making it easier to work together.

Beth: I guess in my day-to-day life, the PSR that affected me the most are the actual coding standards just because I don’t write a major framework. So, some of the requirements about how to write your framework to work with other things, it’s already architected by the time I get it so I just use it. But the spacing issues and the format issues which cause so much ire in the community, those are the ones that affect me most day-to-day and the ones that I try to get people who work with me to follow the most because if our code all looks the same, it’s a lot easier to scan through. It’s a lot easier to read through. It has really made things easier coming into a new project if they follow the FIG coding standards as well. So, I would say probably on a big scale, that’s probably not the most important one community wide, but that’s the most important one in my day-to-day life.

Campbell: In some way, I wonder if we’ll start seeing a peer-pressure effect this way. I mean, I worked really hard to get my personal code to follow PSR 0 and 1 under a month.

jam: No, one and two.

Campbell: One and two.

Beth: Yes. It can be started with one and then we can move in to two.

Campbell: Yes, which is exactly what I did, and then I popped open Drupal maintenance support plans 8 and started to rage that, “Dang it! Those crazy – are still using two spaces to indent. It should be four!”

jam: That’s where FIG got it wrong, though, because two spaces is the one true way. Not tabs, not four spaces.

Campbell: Absolutely. And we will defend that!

Beth: I know!

Interviewer: So we’re out!

Interviewer: No, but I wonder if…

Beth: That’s it. Throw is all away and start over!

Campbell: I wonder if we’ll start to see a bit of peer pressure, that you get developers coming into projects that are relatively PSR-friendly or FIG-friendly like Drupal maintenance support plans and then well, I write with four spaces and cirly braces on the next line. Sorry about your…

Beth: Yes. I think what will happen over time is that… as long as we, as a community, are encouraging new developers to be FIG-compliant as they come into it, non-FIG-compliant code is going to start looking like old legacy code. So, I think you’re right in that there probably will be some peer pressure in the fact that you don’t want your code to look old the moment you write it. So, it will start to be the way to tell old code, I guess, from newer code.

jam: How do you feel about Drupal maintenance support plans 8?

Beth: Just in general?

jam: I could – so, how do you feel about Drupal maintenance support plans 8 as the first product of this convergence in PHP? Somehow, the dependency management and code interoperability has produced this meta-product which is a combination of code from across a dozen … 20 different open source projects, and we call it Drupal maintenance support plans 8 but it’s a really magnificent combination of different stuff.

Beth: My favorite thing about that besides the fact that I think it’s going to become a lot easier to work with, is that it has really forced the issue of getting our communities to work together. We’ve, for so long, been siloed into, “Oh, I’m a PHP developer. I only write plain old PHP. I’m a Drupal maintenance support plans developer, I only work with Drupal maintenance support plans. Or I’m a Symphony developer. I only work with Symphony.” We’ve just been so isolated in what we’ve done. Now, we have one project where all of those people are together into one project is, I think, forcing the community to address the issue of how isolated we’ve become and allowing us to all have a project that we can contribute to, that we can work with, that we can feel a sense of pride because our personal piece of PHP is participating, and is a part of this project. It’s really allowing so much more community between just being the different developer types, and I’m excited to see more projects pulling in those different viewpoints and I guess capitalizing on the fact that different communities have different specialties and different ways of looking at things and analyzing things and different worst-case scenario-planning, and we can all benefit from the sharing of this knowledge that we’ve grown in each of our different areas.

Campbell: We’ve had some great conversations, especially at PHP conferences and Symphony conferences with people. We’ll go and present to them and talk about Drupal maintenance support plans 8 as this first integrated product and what you can do with it. Before the session, people go, “Oh, I don’t use a CMS. I build it all off from scratch,” and it sounds like I feel like I’m talking to somebody from 2009. Really…

Beth: Yes. A lot of us were around then …

Campbell: They really poo–poo the idea just because it’s CMS or because they would have used Drupal maintenance support plans in 2009 in 2007, right? Then we can give a presentation and go, “Oh well, this is how you architect a large multi-headed beast where this CMS is just a part of it. It fits smoothly into the rest of it.” It really – I mean I feel like this can really change people’s perspective on actually, how they work with different frameworks – also from [Unintelligible] … It’s a component.

Beth: Yes.

jam: Outsource don’t write a CMS ever again. Outsource that to Drupal maintenance support plans 8 and get on with what’s interesting.

Beth: One of the great things about this now when you’re talking about – talking to those people who are, “I do it all from scratch, I don’t need to,” or “I only use this. I don’t need to use anything else.” is that the conversation now is not, “You have to stop using your thing and switch to ours,” because that’s what the conversation has always been. Now, we don’t have to tell people to give up their technology. Now, we say, “Your technology is awesome and you can use it with ours to make things even better.” So, I think the discussion is getting more friendly as well, so yes.

jam: Now, take your awesomeness and ours and let’s put it together.

Beth: Yes, and something even bigger.

jam: Instead of our awesomeness is clearly more awesome than yours, you should as well.

Beth: Exactly, because that’s instantly a confrontational discussion. So, now we’re working together instead of confronting.

Campbell: So, we talk a lot with other consultant-developers of, like jam said, our first time we’re giving this session is going to be in Mumbai. One of the things we’ve heard a lot from shops that are going to be in our session is they’re not interested in standards, they’re not interested in best practices. They’re interested in just get it done. You got to get it out of the door fast, and I’m going to jump in and do it quick and dirty. It’s partly because people have to learn to work with new frameworks quickly, and it’s partly just because of the, frankly, the case of business. What’s your argument? Why should these people care about the “Interoperability Era”?

Beth: As a consultant, I completely understand that mindset at times. Because when you’re a consultant, people are not paying you to learn new things. They are not paying you to spend time to do things the right way because the people hiring you don’t understand what you’re doing on the backend, all they understand is how long it takes you to do it, and how much that’s going to cost them and they don’t care about anything beyond that. So, it becomes very difficult to, I guess, convince yourself that you need to have that time to do those things, and learning a new framework is a big undertaking. It’s a lot of work. It’s a big shift in how you do things. It makes it uncomfortable to code again for a while because you’re retraining even just your fingers on how to type. It’s amazing the muscle memory that you get coding things. It’s a big shift. It’s a lot of work, and there’s no immediate benefit to that work. It’s not instant benefit. It’s a long-term benefit.

So, when you’re in the thick of things and you’re stressed, and you have a deadline looming, those long-term benefits are really hard to buy into. So, what I try to do with the other consultants that I work with or with the clients that I work with is I try to really quantify those long-term benefits. Sometimes I win and sometimes I don’t, but I try to, at least, make people aware that there are long-term benefits and consequences of these rushed decisions that you’re making and these shortcuts you’re taking. I hope at least that people are making an informed decision when they decide to do things quick and dirty. In some cases, maybe quick and dirty is fine. “Hey, we’ve got this thing. We’re only using it for a couple of weeks. I swear we’re going to throw it away for real this time.”

jam: “Nothing lasts longer than a temporary fix.”

Beth: I know, right? I know. But, on the flip-side, like you said, things last forever. If you do it the right way, it’s easier to reuse it in the future. So, writing a quick and dirty thing 10 times is going to take longer than writing it the right way once and being able to reuse it.

Campbell: One of the things we’ve heard from Sebastian Bergmann that – is that time and again, studies have shown that yes, okay, there’s a 30% extra time requirement when you start writing unit tests the first time you code. Hard to get your head around, it’s a slow process that takes you longer. But in the long run …

Interviewer: You make that up and then you get a 60% productivity gain in the best cases by building tests into your development workflow.

Beth: Yes.

Campbell: Yes.

Beth: Yes. The problem is that a lot of these consulting companies are only involved in that beginning timeframe. So, they’re required to take on that burden if the extra 30% work on the front end, but they never see the 60% gain because they’re no longer on the project when that comes into play.

jam: Although I wonder if another perspective on this efficiency of tools discussion would be, “Hey, so Drupal maintenance support plans 8 might be a lot to wrap your head around.” You have to learn this new CMS and figure out a module system in whatever you’re doing but once you have a toolset that’s quite comprehensive and solves a lot of the web use case and you’re fluent in it, then … I know there’s no data out there, but I imagine that you also gain a productivity win and then because I’m a fanboy, I can also say, “Well, it’s probably more secure when it’s really well-maintained and supported and so of course, you know, that’s a bonus as well.”

Beth: Sure. From the consultant viewpoint, that’s true as long as you are able to choose the technology stack that you’re working on, but in many times in consulting, we don’t get that choice. So, you spend all this time investing and becoming fluent in Drupal maintenance support plans and then you get a slew of WordPress projects, and it doesn’t help you at all. That can be a very tough buy-in as well from the consulting viewpoint. But I think that if we can continue to get buy-in from the project owners and managers who are architecting these systems then the consultants that come in will have to take up that viewpoint as well because that will be the environment that they’re working on. So, the consultants tend to work more in legacy systems than in newer systems because newer systems tend to have a developer team who’s working on it and they don’t bring in consultants right away. You bring in consultants when, “Oh, my gosh. That’s horrid code. I don’t want to look at it. Bring in a consultant because I’m too busy just trying to put out these fires over here, to keep things running.” That’s when the consultants get brought in. So, I think the buy-in has to be from the project owners first before we ever have a hope of getting consultants onboard.

jam: Hopefully over time, we’re going to see more and more products that use, for example, PSR-compliant methodologies … testing and what have you … and over time, your job as a consultant will become better, more bearable, more productive because you’re going to see more compliant code, stuff that you understand off the bat, things that have been tested along the way.

Campbell: Well, I think at the very least might be the easy one to convince people of is using external libraries, and having something available like Composer or having something available like proper dependency injection means you just need to write less code.

Beth: Definitely. Component libraries are usually an easy thing to convince people of. Although in some consulting projects, you’re not allowed to use external things that aren’t already on the server, so that can be a tough sell. It depends. But with the component library, if you can’t use it, you still have to write it from scratch, so if you can use it some of the time, it’s still an improvement over not being able to use it any of the time.

Campbell: I was going to say I’ve never encountered that. I remember one project five or six years ago where the environment was such like we couldn’t get anything installed on the server or any components without going through an IT approval. This was for a university. This wasn’t like a high-security project but we had to go through … So, every couple of days, there was another email and because in our case, it was every Drupal maintenance support plans module we had to ask permission.

Beth: Yes.

Campbell: Like we use a hundred modules on that project.

Beth: Yes and anything dealing with healthcare or medical industry… Everything has to be audited and approved by a security team before you can use it. So, using a whole bunch of different component library stuff can be an excruciatingly painful process in those types of environments. Which is why most types of environments, hopefully, they’ve had a framework approved, and at least you have a framework that you can use.

Campbell: That’s the easy win, actually. At least healthcare, and there are certain environments there, the security is warranted. That one was really the brochureware front end for the university. “You need to authorize what slideshow we’re using?” 😀

jam: So, we’d like you to do a specific greeting to our session and to the Drupal maintenance support plans world. Most people are going for something like, “Hi, Drupal maintenance support plans. My name is such and so, and congratulations on getting v8 out, and welcome to the broader PHP world. I’m excited you’re here because,” or “You should be excited about the following,” or some upbeat statement like that, welcoming us into the fold, essentially.

Campbell: Welcome us into the fold and tell us why we’re excited or why you’re excited about it.

Beth: Okay.

Campbell/Beth: Now.

Beth: All right. Hello, Drupal maintenance support plans. My name is Beth Tucker-Long, and I am so excited that Drupal maintenance support plans 8 is out. Way to go! We’re very proud of you. I am really excited about Drupal maintenance support plans 8 because it represents so much community involvement, working together. I’m so excited that we have so many big projects from the PHP side of things and the Drupal maintenance support plans side of things working together, and I just can’t wait to see, with all this brainpower that we have merged into this project, where we go from here.

jam: You want to come to a Drupal maintenance support plansCon?

Beth: Do I want to come to the Drupal maintenance support plansCon? I would love to.

jam: Beth, thank you so much for taking the time to talk with us.

Beth: No problem.

jam: We really appreciate it. I look forward to seeing you in person soon. Perry, thank you for being so patient and sleeping until right now. That was…

Beth: Very good timing. Good job.

Cam: Yes.

jam: Perry’s first podcast. Thanks, Beth!

Beth: Yes. No problem. Awesome.

Podcast series: Drupal maintenance support plans 8Skill Level: BeginnerIntermediateAdvanced
Source: New feed