Brent Toderash Interview

Interviews

Brent Toderash is a freelance thinker (@toderash) who has been using WordPress since before it was born — before it was forked from the b2 project. A community-minded guy committed to open source and sharing information, he’s a regular at the monthly WordPress Winnipeg Meetup, he spoke at the inaugural WordCamp Winnipeg and he volunteers for TedXManitoba in addition to running his own business and being a husband and father.

How did you get started working with WordPress and how has it influenced your career?

I keep telling people I’ve been using WordPress since it was called b2. Back in the pre-WordPress days when I was looking for blog software to use as a back end for some of our clients’ websites, I had settled on b2 as a preferred option. I had been blogging in the news-echo style of the day on Linux, open source, and tech but after four years, took a bit of a hiatus. When I returned to blogging in 2004, I looked at the two forks of b2, b2evolution, and WordPress. I picked what I felt would be the winning horse and set about blogging again. While using WordPress on my own site over the next five-and-a-half years running WP, I poked, prodded, tinkered, and tweaked it until I was right at home not just modifying existing themes, but writing my own from scratch and putting in some basic PHP functions.

Once I was very comfortable with WordPress, I began using it for client sites, thinking it would be a good standby as long as I didn’t run across requirements that were too complex or too specialized. I kept pushing WordPress to do more, while its development cycle kept extending the boundaries. So far, I haven’t found anything I can’t make WordPress do for a client. Not always out-of-the-box of course, but extensibility has always been a primary requirement, and WordPress meets it handily.

I guess you could say that WordPress has influenced my career simply by drawing me into its vortex. In the early days I was concerned not to get too tied to a single tool, but with the growth of the WP market, it appears there won’t be any shortage of client work in a WP environment for the foreseeable future. One thing that’s changed is that I don’t have to spend much time selling clients on WordPress, since clients have increasingly heard of it or are already using it.

You consider yourself a “freelance thinker and strategist” — tell us a little more about the ideas behind your unusual title.

I’ve done (and still do) a lot of web development, but I’ve also been a project manager and an entrepreneur. I’ve worked with marketers, number-crunchers, creatives, and gearheads, and I’ve talked to a lot of other business owners and managers. The more of these things I do, the more convinced I become that the most important value I offer is looking at things from different angles. I tend to be a big picture thinker, so even when I sit down to do a “simple” small business website, I want to know how the website fits into the overall business objectives and operations. I typically look five or six steps down the road, even if the client is only thinking about one or two steps. That’s one of the reasons I like using WordPress, actually… it provides my clients with a good foundation not only for what they need now, but for things they don’t yet know they want to do.

A few years back, some friends and I developed this practice of “testing assumptions for fun and beverages.” We’d gather over a pint or two and take some business assumption or idea and kick it around to prove or disprove its soundness, adjusting it or killing it. We’d sometimes have a guest sit in with their business idea and we’d kick it around while he paid for the beer. That may have been where I really came up with this idea of being a freelance “thinker,” and when I designed my business cards I gave myself a title that reflects one of the things I most enjoy in business.

You’ve recently worked on an interesting project featuring WordPress multisite. Tell us all about it.

Yes, it’s been a while in development but we launched MyCoachLog.com earlier this year after close to two years of planning, prototyping, developing, and testing. It was quite a process, and I certainly learned a thing or two about building applications on top of WordPress. I managed the project throughout, bringing in several different developers at various stages. We built it on multisite, which went better than I had expected — most of my experience with multisite dates back to before the code merge at 3.0, so it was much simpler by comparison.

The application basically provides a means to track coaching/mentoring relationships to provide structure to the process, as much as tripling the coach’s effectiveness. The coach can assign a series of “prep questions” to the coachee (or group). When the client is notified that there are questions to complete, she logs in and responds, triggering a notice to the coach. At that point, they’re ready for their session. During the session, both parties can call up the session page at the same time to view the questions and responses as well as take their own notes during the session. There is then an action plan which functions much like a to-do list with assignable items. After that, the cycle starts over again. We’ve used coaching terminology, but it works with mentoring or staffing relationships as well. Building on multisite supported the business model by allowing it to be sold not just to individual coaches, but also to organizations that want a fully branded version of the site.

You’re involved in the local community: you’re a regular at the monthly WordPress Winnipeg Meetup and you spoke at the first-ever WordCamp Winnipeg this past June 1st. Why do you invest so much time into the community and what do you personally get out of it?

I’d say I don’t get anything out of it directly, unless you count camaraderie and experience of course. Being involved with WordPress has introduced me to some great people whom I feel I can call friends. The regular meetups give me access to people with considerable WP skills as well as newbies. I glean things through many of the presenters or bring my own questions or issues I’ve run up against. At the same time, I can share my own experience with others who haven’t been at it as long. I think experienced developers and core contributors do well to be involved in a meetup where “regular” people come out feeling overwhelmed with what might be considered fairly basic questions in another context. That interaction is key for keeping in touch with users and ensuring that WP only becomes more accessible to newcomers.

The other thing I’d say here is that I’m a big believer in the principles underlying open source software and the GPL. I was a proponent of Linux and other free and open source software from around 1998-99 when I first started digging into the subject, and I blogged on those topics for four and a half years back when people still talked about The Slashdot Effect.

One of the values in that community is contributing. I dislike the term “giving back” because it’s become so trite, but contributing is part of the motivation. I have zero commits to WordPress Core and I haven’t publicly released any plugins so far. I’ll be the first to tell you that there are other developers who can sling PHP circles around me and who know Core far, far better than I do. But in the spirit of contributing to the greater good of WordPress, there are other ways I can pitch in, and involvement in meetups is a really accessible and rewarding one.

What was it about WordPress that made you choose it on which to build the mycoachlog.com application? In your opinion, why should developers use WordPress as a platform to build applications?

At the outset, I wanted to build the application on a framework that I could understand and work with, and which would be easy to find skilled developers for. For me as the project manager, my own knowledge of WordPress meant reduced project risk because I’d be able to interact with both the client and the developers intelligently. It also meant that I’d be able to better gauge when a developer was out of his element. When I was interviewing a few different developers at the beginning of the project, this was one of the questions I asked each of them. After basically outlining a functional spec, the developers were asked if building on WordPress would gain us anything in functionality or development time, or if they’d recommend a different framework. In all but one case, I was told that for what we want to do, WordPress would give us some of these advantages over other frameworks. There are a few places this really showed up for us.

First, we were able to get a prototype up and running fairly quickly, and it was easy for me to partially mock up some of the user interface by building a “dummy” form with Gravity Forms. Second, we got a great admin area to use for managing the site. Building even a third of what’s in wp-admin would have been a significant time suck. When it came time to go into beta and then launch the site, we found other advantages in that we were able to use readily-available plugins for some of the site features we wanted, like MediaElements (in core as of 3.6), Google Analytics, and Conditional Widgets.

We’re currently building the support section of the site, which is just another site in our multisite install that runs a ticketing system plugin. The nice thing about this is that the users’ existing logins work on the support site as well. Doing that with another framework would have taken a considerable effort, where this setup took no programming at all. We couldn’t make a business case for fully integrating a built-from-scratch ecommerce engine before launching, so I set up WooCommerce with a few extensions to handle billing. There’s a bit of work still to integrate it fully, but what we have allowed us to launch several months earlier. I wrote a few shortcodes that we could use on the public-facing side of the site, and when we wanted some custom CSS for the fully branded sites, guess what? There’s a plugin for that too.

Mycoachlog.com was two years in development. What was the most important thing you learned about using WordPress to build applications?

Budget more time than you think. We weren’t working this project full-time since there was a lot of testing and revising as we went along. Some of the things we encountered are just common to software projects. Fred Brooks famously said in The Mythical Man Month, “Plan to throw one away. You will anyway.” We were a few months in when we threw it away and started a rewrite. One of the lessons learned relating specifically to WordPress as a framework would probably be that you need to take time to architect the system carefully at the outset. It can be very tempting to dig in and sort things out as you go, but because there isn’t one specific way to do something, you need to think through the pros and cons before committing. There were a couple of times where we were painted into a corner and had to change the way a function worked. In some cases that’s unavoidable if the spec is changing, but thinking and talking the solution through carefully can help avoid that as much as possible.

What hard-won advice do you have to share with WordPress devs looking to get into building applications on top of WordPress?

You need to know the WordPress Core. The better you know it, the more smoothly the project is going to go — it’s pretty much that simple. Relying on the Codex will only get you so far. Sure, some of the lesser known functions like wpautop and wp_remote_get or even wp_list_pluck are in the Codex, but if you don’t know that those functions exist, you won’t know to look for them. Some of those are easy examples, but WP Core is filled with a lot of functions that can make life easier for developers. Without knowing they exist though, a developer is likely to go out and craft a whole new wheel. In fact, a really experienced non-WordPress developer was complaining to me recently about WordPress “mangling” his text, and I was able to reply by telling him to simply remove_filter( ..., 'wpautop' ). More pages like How How WordPress Processes Post Content in an easily navigable structure would help with some of the easy ones, but the more esoteric functions that WordPress already has built-in may be harder to arrange.

For example, we had five different developers touching the code over the course of the project. The latest developer I’ve had working on it was Aaron Campbell of Range. I reported something as a bug one day and he explained that it wasn’t something in the application, but something that WordPress itself didn’t do. He was able to tell me why, historically, it didn’t work that way. At the same time, we could see a clear use case beyond our need, so Aaron went ahead and wrote a patch, submitted it, and it was accepted for the 3.6 release. The report and explanation was a single conversation, and having the patch accepted was the next day, if I recall correctly. For someone who didn’t know WP Core as well, there would definitely have been some wheel-spinning involved.

Is there anything we didn’t discuss that you’d like to share or talk about?

For me, the main thing is about the future of building applications on WordPress. This was something I felt was coming two years ago when architecture decisions were being made as we started the project, and it’s something Matt Mullenweg has started talking about publicly as well. I’m keen to see this trend evolve, but I think it’s important to understand where we are now and what it’s going to take to get some momentum going. There are a lot of fairly basic applications that don’t need much discussion…those can be straightforward enough that a few custom post types and custom functions may be all that’s really needed. But for more complex applications, the gap between where we are and where we want to be really starts to show.

The biggest thing is documentation. In the Codex, you can look up a function and find some basic information… provided you know the function name. I’ve had less luck finding a function reference by searching for the outcome I’m trying to reach. Siobhan McKeown has already taken on a mammoth task with the WP Codex, but what I’d suggest in addition to improving the documentation on each page would be an alternate index that lists functions by outcome, or grouped in other ways, such as listing functions under “Manipulating Text” and “Formatting Text” and “Handling URLs.” After that might be some form of “best practices” manual geared specifically toward application development on WordPress. Something like where to use taxonomies, when to use Custom Post Types, and what limitations might be. As well, some best-practice documentation on things like interacting with the database would help a lot. We had one instance where a few hours’ effort was able to reduce the number of queries on one of the pages by 97%. That’s not an exaggeration, so the performance boost was immense. (Maybe it’s time for an O’Reilly book on application development with WordPress, but I’m not sure what the animal would be.)

The current reality is that building an extensive application is going to require a Rockstar WordPress Developer. Gaining wider adoption will require lowering the bar, and navigating even the existing documentation will help more than anything at this stage. The problem is that the same group of people who contribute regularly to WP Core can’t be limited to the same group of people who are building applications on top of it. This model isn’t sustainable because it won’t scale quickly enough. Until that changes, the relatively small pool of premium developers means that development costs will be higher than they should be, even if they are ultimately lower than they would be if another framework was used. That’s a significant barrier to wider adoption of WP as a framework, so it’s something that will need specific attention. The upside is that the type of developers who will be building complex applications on WordPress are more likely to become Core contributors. There’s a gradual progression from improving documentation to more people building on WordPress to more people contributing to WordPress. And in the end, all of those things will benefit users. The other thing that will be affected positively is the WordPress economy — you’ll see more companies built on WordPress because, like with MyCoachLog, they’ll be able to use it to help drive revenue.

Remember when you asked me what a “Freelance Thinker” was? That’s kind of it, right there… I tend to look at things in the big picture, then follow the thread back to where we can start devising a strategy. In this case, I’ve drawn a line from documentation to the economy. It wasn’t a connection I’d consciously made before we started the interview, but there it is, an assumption primed for testing — for fun and beverages, of course, but hopefully for the benefit of the WordPress community as well.