Journal tags: quality

If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.

The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).

This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.

Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.

If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.

Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).

They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.

I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.

But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.

We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.

I’d rather spend my time pursuing the opposite: the least work for the most people.

When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.

But every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

There are plenty of non-code prototyping tools out there, and our designers often reach for them to communicate subtleties like motion design. But when it comes to testing a prototype with real users, it’s hard to beat the flexibility of HTML, CSS, and JavaScript. Load it up in a browser and away you go.

We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.

Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Of course it should go without saying that you should never, ever release prototype code into production.

And yet…

More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought. Fragile architectures are employed that rely on first loading and then executing JavaScript in order to render basic content. Developer experience is prioritised over user experience.

Heydon recently highlighted an article that offered this tip for aspiring web developers:

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like span and how they differ from block ones like div.

That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.

Yesterday Ireland held a referendum to amend its constitution in order to provide equal rights to gay couples who want to get married. Today it’s clear that the “yes” vote is going to carry the day.

This is amazing.

I left Ireland in the early ’90s. When I told people abroad about the medieval legal situation in Ireland on contraception, divorce, and homosexuality …well, people just wouldn’t believe me. Combined with the nationalistic political situation, I got used to a sort of permanent miasma of embarrassment towards the country I came from.

But today I feel a swell of pride.

After the Future of Web Apps 2006 conference in San Francisco, a post by Chris Messina lamenting the lack of women in the line-up prompted heated debate and high emotions.

The Future of Web Apps 2007 conference just wrapped up in London and Jason Kottke has reignited the debate. What’s changed since the last time? Not much.

Tempers are still getting frayed and the discourse is generally pretty unhelpful.

Let me say from the start that I do think there is a problem with having so many conferences with such unbalanced line-ups and I firmly believe that a lot of the responsibility lies with the organisers to change things. That said, I also understand just how hard it is to put on any kind of conference at all.

To the people accusing conference organisers of being some kind of cabalistic old boy’s network: you’re really not helping. You’ll catch more flies with honey than vinegar.

To the people organising conferences who throw up their hands and say “it’s not our job, we’re just reflecting the sad reality”: you’re being equally unhelpful.

So, all of you: try walking a mile in the other person’s shoes. That way, if you still don’t agree, you’ll be a mile away from the other person and you’ve made off with their shoes.

Eric came out with a provacative post that’s just aching to be quoted out of context:

So, here it is: as a conference organizer, I don’t care about diversity.

I admire and respect Eric but I think in this instance that he is wrong. We’ll just have to agree to disagree.

Eric makes the very persuasive argument that to put on a successful conference, the line-up needs to be filled with well-known, established speakers. (This prompted the obvious question from a few people in the comments; just how does one become well-known or established? As Jen says, Eric, it is becoming a circle jerk.)

Success doesn’t just mean financial success, though I readily admit that the economics of organising a conference are fiendish. A successful conference is about more than just getting bums on seats.

Yes, if you fill a line-up with “A-listers” then you’ll sell all your tickets and the attendees will learn from the best and everyone will be happy… in the short term. In the long term, it’s unsustainable. It leads to a closed loop, a neverending cycle of the same names talking about the same subjects. Diversity isn’t just a means to an end (that end being a better conference), it is in and of itself, A Good Thing.

Conferences, especially well-established conferences (and I would put An Event Apart into that category) can and should take some chances. Yes, it’s risky. No, you can’t guarantee ticket sales. But it will be a better conference if the line-up has some wild cards.

I firmly believe that conferences shouldn’t simply be mirrors for the Web business, reflecting whatever is current and accepted. A good conference can act as a force on the industry. Conference organisers have a great opportunity here and I think it’s a shame to see it wasted.

Alright… enough talking about conference organisers as if they were some kind of separate caste of people. It’s time to point the finger at myself.

My company, Clearleft, organises the dConstruct conference in Brighton every year. It’s really Andy’s baby but he very kindly asks for my opinions in putting the conference together. I personally feel very strongly that this year’s dConstruct needs to change from last year’s homogenous line-up (I’m pretty sure Andy agrees).

Even if we sell every ticket, even if everybody blogs about having a great time, if the line-up consists of a bunch of white male speakers (“A-list” or otherwise), I will consider the conference a failure.

But what to do? The perceived wisdom is that there are simply far more kick-ass men speakers than women. I don’t believe that’s true. I think there are far more visible men in our industry, but with just a bit effort it’s entirely possible to find a wealth of women speakers who can truthfully be described as well and truly kick-ass.

I’m not sure if I’m supposed to blog about this, but for months now, we at Clearleft have had a BaseCamp project set up with the specific intention of finding new blood for dConstruct. We’ve invited people from outside our circle of expertise and interests and asked them to suggest speakers. The idea is to deliberately introduce diversity, to stir things up a bit and ultimately, to put together the most kick-ass line-up of speakers we can.

Is this tokenism? Absolutely not. I fully concur with Eric when he says:

What’s important is technical expertise, speaking skills, professional stature, brand appropriateness, and marketability.

But I don’t believe that this attitude conflicts in any way with the desire to increase diversity. It’s entirely possible to put together a superb line-up of diverse speakers.

Don’t believe me? Take a look at Web Directions North (or South for that matter), one of the best, most stimulating conferences I’ve ever attended. They didn’t make a big deal about the mixture of topics and presenters, they just put together the best line-up they could.

I’m not saying it’s easy. I know for a fact that it’s a lot of hard work. But it’s achievable; Web Directions is a testament to that.

I’m also going to have to agree to disagree with Tantek, another person I admire and respect greatly. He is of the opinion the kind of thing I’m suggesting would indeed fall under the category of tokenism:

Why is it that gender (and less often race, nay, skin-color, see below) are the only physical characteristics that lots of otherwise smart people appear to chime in support for diversity of?

Where are all the green-eyed folks? Where are all the folks with facial tattoos? Where are all the redheads? Where are the speakers with non-ear facial piercings?

Actually, I would agree with Tantek if I were talking about diversity of sexes, but I’m not. I’m talking about diversity of gender. There’s a difference. Sex means male or female. Gender means masculine or feminine.

I fully agree that a speaker’s sex makes about as much difference as their eye-colour or hairstyle but a speaker’s gender can and does affect their outlook and experience. As someone who has a (primarily) masculine gender, I know that I can learn a lot more from being in a mixed masculine/feminine environment. That’s one of the reasons why I’m glad my band isn’t an all-male affair.

I’m not just arguing semantics here. I’m trying to point out why I think Tantek’s argument is reducto ad absurdum. Gender isn’t like eye-colour. Introducing more gender diversity into a conference is productive in the same way as introducing someone with a background in product design or some other non-Web field that can offer a new perspective on our industry (this isn’t just an off-hand comparison).

I hope I’ve made my point clear. Let me reiterate that I can see both sides of this debate but I do come down firmly on the side of increasing diversity. I just hope that I can work towards this goal in a constructive way.

Frankly, I find Jason Kottke’s reductionist statistical approach to be counter-productive. It’s not just about numbers, Jason. I’m also not so sure that Anil’s abrasive style is particularly constructive but his clever riposte to the Future of Web Apps line-up is illuminating.

I do feel bad for Ryan. He always seems to bear the brunt of the blame even though plenty of other conferences are equally lacking in diversity.

However… I do take issue with Ryan’s attempt to wash his hands by pointing out just how many of the speaker slots were bought by sponsors. I’m sorry, but selling time slots to the highest bidder is no way to put a conference together. I’m well aware of the economic realities of putting on a conference and I know that selling slots to sponsors is established practice in certain circles but it won’t cut it with the geek crowd.

Again, Web Directions North managed to get this just right by allowing companies to sponsor speakers. So the speakers were all chosen for their expertise, knowledge and perhaps even diversity, and then Adobe or Microsoft were given the opportunity to introduce the speakers. It sure beats product pitches.

I want to finish with an observation on this whole issue of gender diversity at Web conferences.

This debate isn’t going to go away. It looks like it’s going to flare up every few months. Clearly, plenty of bloggers—who are also probably the target audience for a lot of these conferences—really care about this issue and want to see some changes. Yet every time the issue is raised, conference organisers fall back on the argument that they need to fill the auditorium and that the best way of doing that is to give people the same “A-list” speakers that have always worked in the past. In other words, give the people what they want.

Well, we want diversity.

It’s kind of like the whole brouhaha with Adobe and their crappy new icons. The majority of Adobe’s potential customers disliked the icons and wrote good, well-reasoned blog posts explaining why. As Aral so excellently noted, Adobe deliberately chose to ignore this wealth of valuable feedback. I see conferences falling into the same trap. The very fact that this debate is taking place (and continues to take place ever more frequently) should be sending a message that this is an important issue that needs to be addressed.

It reminds me of the old joke. A guy walks into a shop and asks for some product or other. The shopkeeper says, “We don’t stock that. There’s no demand for it.” The shopkeeper then adds, “It’s funny: you’re the tenth person to ask for that today.”