Both Adam Culp and Cal Evans had some slightly related thoughts about what is “wrong” with conference talks recently and how they intend to fix them.

For Adam, neither novices nor veterans are getting content sufficient to justify their attendance to the Big Mean Boss back home. He attributes this at least in part to “laziness” in preparing talks without sufficient preparation and hard technical code examples. Cal similarly self-diagnoses simply submitting to be accepted rather than submitting to speak to his passions.

If both were simply going to change how they pitched talks and encourage others to do the same, starting a conversation about why veteran speakers speak and what the focus of talks should be, I’d be all for it. Unfortunately both of them threw in their positions as conference organizers into the mix, including specific vows.

From Cal:

I am privileged enough to be asked to help score talks for several of different PHP conferences. in 2015, I will start be a lot more picky in the talks for which I vote. I will look for – and up vote – talks where the presenter makes a note that they have given this talk at a local event already.

Adam’s resolutions include:

• Be tougher when rating talks I attend at conferences. I should walk out of a talk feeling like I truly learned something.
• Be more critical when selecting talks to be presented at conferences. I owe it to the attendees, and to the conference organizers to ensure the best talks are chosen.
• Ask to see slides and code for talks in advance if available, and at a minimum set a deadline of when these should be ready if the talk is selected. To ensure the talk lives up to the abstract.

There are a few problems I see in these proposals that warrant further discussion.

Both proposals suffer from something similar to Keynes’s (alleged) Paradox of Thrift: this is fine if a few speakers tailor their talks to these criteria, but if most or even many speakers do so, it could cause problems.

Take Cal’s proposal that talks should only be accepted if they have been previously given at a local venue. In North America alone, there are now several PHP conferences. There are many more web conferences that can include PHP talks or other talks that might appear at a PHP conference (Jenkins, Ansible, Selenium, etc.). Even if there’s heavy overlap in speakers and talks, that means something like 60-70 talks will need to be previewed at user group meetings. And that’s just assuming that pretty much everybody who submits is accepted. Recent ratios seem to be more like 5 or 6 speakers submitting for every 1 selected. So that means 300 to 420 (heh) talks that have to be given at local venues. That fills up every monthly meeting of 35 user groups.

But Cal goes further: he pledges to speak at 5 local user group meetings this year. Assuming every speaker makes the same pledge, just 40 speakers would fill every monthly meeting for 16 user groups. There are roughly 60 PHP user groups in the US and Canada. Assuming each one meets every month without fail (they don’t, not by a long shot), that means there’s room for 144 speakers who speak at 5 user group meetings each in the US and Canada. Reality is likely a lot lower, and that’s assuming  local groups don’t insist on local talent that’s not going on to speak at conferences, or have panels, lightning talks, or genius bars.

That’s not web scale.

Adam’s proposal increases the PITA quotient for creating new talks considerably. Simple microeconomics tells us that if you raise the cost of something while keeping the price constant (e.g., the number of 2 nights and a flights available for each talk), you’ll get fewer. It also means you’ll get fewer new speakers willing to risk creation of new content just to have the possibility of being selected. Existing speakers will pare theirs down to what Adam says he does: a couple of talks that they submit to every conference.

That means attending one conference a year is all you’ll likely ever need to do, let alone be able to do. You’ll have the same exact experience with the same exact set of speakers you’ll see at every other conference. Furthermore, there will be no need to go back next year. Once every three or four years will be enough to get any new talks created by that same set of speakers or the handful that manage to break in. The hallway track, far from being a secondary benefit as Adam sees it, will become the only thing a repeat attendee values.

This will hurt diversity. Not just identity-politics-laden diversity, but diversity of experience, thought, approach, and, if Adam were to have his way for even more code-centric, hands-on, immediate-takeaway talks, style of presentation. The same PHP people saying the same PHP things. Not to mention that impostor syndrome is hard enough to overcome without creating new barriers to entry just to be considered.

It’s also not accurate that everyone can get two or three talks accepted in many venues. There are dozens of variables that go into talk selection: conferences like people to give two talks because it cuts down on travel and hotel costs and keeps tickets more affordable. Just having two great talks isn’t enough, though. They must be great talks that meet the demand that’s out there. One year Puppet is all the rage, the next year Ansible. What if you have one talk that’s unique but your second talk is the umpteenth proposal on that topic? Another guy with a slightly less unique approach but a second talk that isn’t as common may fit better. I’ve had to watch many of my favorite talk submissions rejected because we just couldn’t work them into the schedule for sometimes arcane reasons.

Obviously, I’ve taken these issues to task by extending them to an extreme. But had both gentlemen not emphasized that they select or help select talks for multiple conferences and urged others to do the same, I’d applaud. Let a hundred flowers bloom, and all that. Sunshine PHP can become where you go for veteran speakers giving advanced, hands-on talks chock full of code samples. Another conference can have a mix, another lean more toward skills talks, another toward career development, etc.

I’d find Adam’s preferred talks kind of boring if I wasn’t interested in the given technology. I’m a sucker for soft talks. I love talks about the principles of OO design and honing software development as a craft. Thirty slides of 12-point code and watching someone type into the command line to do the same thing as another tool with slightly different (no doubt superior!) syntax put me to sleep. Sure, a good technical talk can have tons of code samples at a readable length and size as well as be entertaining with a smoothly-practiced WOW factor demo, but I’ve seen enough veteran speakers giving talks to know that even for well-honed and -practiced talks, the ideal is rarely met. Plus my ideal is not everybody else’s ideal (see what I said above re: having a diversity of opinions in rating talks at php[architect]). However, there are lots of other people like me.

One of the things I’ve learned as I’ve taken on the training curriculum here is that people don’t learn the same way. You encounter perfectly intelligent people who have to hear things said, others who learn by watching videos, others who need diagrams, others who need to type things out, and others who need to read dead-tree books. Too much homogeny across our conferences will leave a significant portion of people behind.

Furthermore, it’s not a surprise to me that developer advocates and evangelists are the ones behind these proposals. When you literally get paid to network with developers, put on demos, and get speaking engagements, you have lots of time to craft a just-so presentation with lots of hands-on application. But for those of us who move from client to client on old hosting solutions, or are frantically building out the next feature before the upcoming investor meeting, or simply value family time because we learned a long time ago that all work and no play leads to burnout and strife, doing all this on top of our existing commitments is just not realistic, or we’re forced to slowly develop a couple of talks we’ll be giving for the next five years. That violate’s Cal’s stricture to be passionate about what you present.

Finally, I’m not sure why either one says he will be more strict about selecting talks. Unless they are actually planning on reducing the number of speaking slots, they are going to be just as selective as they have been every other year. Their criteria may change slightly, but it’s not actually stricter. They’re just proposing criteria that put a larger burden on speakers. If fewer people submit to their conferences as a result, they’ll actually be less selective, as they’ll be forced to go with the talks they have, rather than the talks they want.

Now, the good

After all that slagging, I want to emphasize that they do identify some key things that speakers should heed as a matter of course: too many speakers do wrap things up five minutes before they start their presentation. Talks do evolve and benefit from feedback, which means in ideal cases giving them 3-4 times. However, the more experienced the speaker, the more a new talk can be exciting and valuable from the first time it’s given. In fact, I’ve noticed recently that veterans giving a brand new talk have been better than when they give that same old talk. Cal addresses this with his insistence that speakers talk on their passions, not just what will get them that next slot.

But if you’re just starting out? I’m pretty confident in my Regex talk, because I’ve given it a few times now. But I’m giving a brand-new talk that was accepted without me writing it first, and yes, I’m going to practice it at my local user group. I’ve also let other speakers trial run their talks.

I’ve also let lots and lots of people who’ve never given a talk before try their hand at it. And I’ve given entry to people who are accomplished speakers, but not in the PHP community.

Now my experience in conference organizing is different, since it’s exclusively for larger conferences (in breadth and length, if not always attendance). While it’s a huge effort to comb through 600+ submissions to fill 40 speaker slots, we’ve had a few people new to the PHP community hit the ball out of the park, as well as first-time talks from old PHP hands that blew people away.

If either Adam or Cal want to road-test new talks at DCPHP, they are more than welcome! There are still lots of people who come to user groups who never get to conferences. Well-rehearsed technical talks with great code samples and actionable content are great. All I want to ensure is that we don’t correct one set of deficiencies with another.

Web developers and web development companies frequently start each project as if they only things that need to be built require merely different types of nails, and luckily they have a hammer. In fact, they often call themselves “Drupal developers” or “Ruby on Rails developers” rather than Web developers (or software engineers). The opposite also happens, where someone will approach each project as a custom, ground-up web development project. Wars inevitably break out over what platform is “best” for web development. Purists slag framework devs as lazy and imprecise, framework devs slag CMS developers the same way and purists as wheel-reinventors, and CMS devs slag the others as wheel-reinventors and one another as using an “inferior” CMS.

The best developers I know may have favorite tools, but they either put them aside when they’re the wrong tool or pass on inappropriate jobs in favor of projects that match their preferred development niche. Others simply choose the best tool for the task at hand…but that choice can be the first point of blank page syndrome. What follows are questions to ask yourself and how the answers can influence your choice.

What does the client expect?

Every project has a client. Even if that client is yourself or your boss, let alone someone who is paying you for a bespoke web application. Sometimes they have particular ideas, for good or ill. You can try to argue the choice if you think it’s wrong, but ultimately the person paying will have to approve your choice. Obviously if you’re adding on to a Drupal website, you have to make a pretty strong argument that Zend Framework is the right choice. (Though I’ve seen it done.) In the nonprofit sector, for example, there’s a huge preference in favor of Drupal for anything larger than a basic site or blog. A previous company I worked for tried to argue for a different solution, but ultimately had to deliver what clients wanted as many dropped non-Drupal proposals immediately.

What is the legacy technology stack?

It’s been a decade since the average web development project was “helping an organization finally get on the web.” Even new projects in existing organizations are often project-specific websites in addition to the main organizational site. Sometimes organizations have a large infrastructure dedicated to serving other sites. While in general I’m not a fan of people hosting their own sites and often throw out the sunk cost fallacy in arguments, sometimes it’s easier to reuse existing equipment and experience than introduce a new technology stack. So if an organization has a ton of ExpressionEngine sites, asking them to host a Drupal site may not end well if they’re not familiar with keeping Drupal up to date or staff need a lot of handholding to use a new system.

What does the end product mostly do?

Even if the excitement is around a small application on the site, if the bulk of the requested functionality revolves around managing web pages, articles, and comments, then starting with a CMS may be the responsible thing to do. While every CMS entails design tradeoffs and limitations that often drive experienced developers nuts, I’d rather focus my development effort on getting that one web application right and adapting it to the CMS’s module structure and API than rebuilding page, menu, login, admin, and comment functionality again.

What will the application do over time?

Small organization sites may live forever as a basic set of rarely-updated pages. Most restaurant pages only need to update menus and maybe an events calendar. Intranet applications will tend to get added on to and fixed over time but never have a vast number of users. And that social networking site may become Facebook.

While lots of startups jumped on the Ruby on Rails bandwagon after Twitter took off, Twitter ended up rewriting most of their site as they scaled. The tradeoff was a quick minimum viable product versus a platform they could easily grow as time went on, and there was a period in which had another service arisen on a more reliable stack, we’d remember Twitter the way we remember Friendster. At mojoLive, we looked seriously at Zend Framework since it was built to have any individual component thrown out for a custom replacement as was needed for scaling, but ultimately it didn’t help us do enough of the hard things easily and would require a significant learning curve to build something we knew was going to be thrown away. Building a custom app based on some code Eli had lying around with a minimal MVC layer didn’t slow us down appreciably over picking up a new framework.

Startups and large enterprise applications also have developers working on them all the time, unlike small organization sites. In the latter case, a well-known CMS is going to be a lot easier than a custom-built CMS for someone to come along and update when you’ve gone on to bigger and better things.

What do you know?

Unless you’re doing a project specifically to learn a technology (and it’s either personal or the client has approved you taking on something you don’t already know because they’re awesome, desperate, or you gave them a big discount), it’s rarely a good idea to start with something you don’t know. Even if you know PHP inside and out, Zend Framework and Drupal have layers of best practices specific to those environments that take time to learn. And jumping from an object-oriented or imperative language to a functional language is…challenging, to say the least.

When is the project due? What’s the budget?

There’s no point in building a new CMS that’s going to take over the world just to churn out a 3-page site due end of the week. The less time you have, the more you’re going to want built for you. Similarly, you’re going to want to stick closer to what you know.

TL; DR

There is, unfortunately, a lot of overlap in the capabilities of systems. Obviously you can ground-up write any app in existence, if you have enough time and budget. (And skill and experience and…) That being said, you can make Drupal into a 300+ mini site system with overlapping permissions, 12,000+ shared users, and single signon with Salesforce. It wasn’t my first choice, but the mix of familiarity, budget, and client expectations led me there. That being said, it was a huge pain and the gains of the CMS components were probably overwhelmed by trying to shove a very idiosyncratic enterprise-level set of requirements onto a CMS whose sweet spot is rapidly building middling complexity content management sites with community features.

In general, though, sites that primarily content belong to CMSes, sites that are primarily web apps with tighter deadlines or without huge growth requirements are better off with frameworks, and sites that are going to be constantly developed and scale rapidly are likely best ground-up. You can find exceptions to all of these, and there are clever people who’ve built simple ground-up CMS apps and made WordPress run massively complex sites, but that rule of thumb should keep your next project from being a cautionary tale of trying to hammer in screws.