Pushing Back

As developers, we often encounter things that we would like to change, or have serious misgivings about during the development process. Sometimes it can be a small thing, at other times it could be something more fundamental.

I’m not just talking about things you spot during a run-of-the-mill QA/bug fixing sprint here. I’m referring to those things that get under your skin. Things that the professional in you identifies as being in the process of being overlooked or neglected.

After we identify these issues, we are faced with a decision: push back and express ourselves in the hope that something can be done about them, or sit on our hands and let them slide.

There will be times when such concerns are immediately acknowledged as common sense changes and will be resolved without resistance. At other times, these concerns will be knocked-back for a variety of reasons, not all of them convincing.

It’s these knock-backs that I’m keen to focus on here. The ones that can trigger an urge to “push back”.

I’m quietly confident in making the assertion that whether you work for an agency, as part of an in-house team or work for yourself you will be faced with these situations on a fairly regular basis.

Here’s a couple of points I want to make on the subject.

We’re not all clueless like Baldrick…

Your voice is important

Regardless of where/how you work, there is a strong chance that from time to time you will meet resistance from others in the organisation who are connected with the project.

Some of them may not be receptive to addressing the concern(s) you raised, and occasionally you may encounter someone with a long-standing history of believing that They Know Best™.

The latter is of course first class bullshit, and needs no further attention other than to recognize that this can often be a tricky situation to deal with. But then again, convincing others to listen to your concerns and ideas isn’t always plain sailing either.

The unfortunate thing here is that sometimes, there can be a Hierarchy of Importance on a given project, where certain project team members feel as though they “outrank” other members on the team in terms of the weight of their opinion.

More often than not it is those who have perhaps been involved from earlier on in the process, or indeed, more of the They Know Best brigade. It is worth saying as well that acting in a management or supervisory capacity does not entitle anyone to use that privilege as an excuse to “pull rank”. Neither of these justifications wash with me, nor should they with anyone else.

The opinion of every member of a team should be treated with equal importance and carry equal weight if the opinion being expressed is both reasonable and constructive. Yes, I understand this is an idealistic view, but it is the right one in my humble opinion.

After all, developers are the ones in the trenches, right? Why shouldn’t our opinion hold weight when we are the ones executing the concept?

We are writing the code and making the technology decisions, we are the ones watching the project evolve before our very eyes. Who is to judge that we are not suitably placed to provide constructive criticism and suggest positive change? Nobody, is the answer.

Of course, there comes the caveat that just because we are the ones getting our hands dirty doesn’t mean that we are always right when it comes to the things we push back on. That is a given.

There is a difference between tactically suggesting changes that can be justified, and putting suggestions forward that are made on a whim without any real thought or justification.

Pushing back during a project when it is both reasonable and constructive to do so should be encouraged, and the person should be treated with respect from all involved for doing so.

Les Grossman has flawed ideas too…

The client is not always right

they just have some flaws in their grand vision.

Fortunately, the web development and retail industries are very different beasts.

The commonly used retail cliché that “the customer is always right” does not, and certainly should not apply to our industry. I flat-out refute any claim that the client/stakeholder should always be “right”.

Not only is this a poor attitude that will make your life harder in the long run, but it means that you miss out on important opportunities to build up their confidence in you through sharing your knowledge & experience. You will also potentially miss out on chances to guide the client into letting you make changes that could save you time or indeed, make the project more profitable.

We should be constantly looking at what we are building and striving to make it better: even if that means pushing back against the specific implementation of something that has been a big part of the client/stakeholder “vision”.

The best web projects are those that continue to evolve from the moment the scope is agreed right the way through the development phase. This is why Agile project management practices are awesome!

Granted, better is very much a subjective term, but when you’re looking at a particular aspect of a website and holding it up against something such as, say, the Web Content Accessibility Guidelines (WCAG) you have a clear baseline from which to determine what is better, and what is worse. This provides you with a solid reference point when it comes to building your case for change.

Holding ourselves accountable to common standards and best practices makes it much easier to build and sell these cases for change to our clients/stakeholders.

Even if they really don’t care about the technical justification, web standards or the best practices we will be perceived as people who care about delivering the best possible end product in a professional manner.

And who doesn’t want that?

However, this approach isn’t without its challenges. Here’s just a few of them:

  • Is this considered to be within scope?
  • Does the client have the budget?
  • Is there sufficient time for these changes?
  • Are there knock-on effects to deal with?

All very important questions that need to be addressed I’m sure you’ll agree, but I’m a firm believer that the earlier we communicate our concerns and push back, the less challenging these obstacles become.

Be more “V”…just not as physical ok?

Pushing back adds value

As digital professionals our raison d’être (that is, our reason for being) should be to deliver the best possible projects for our clients/stakeholders within the budget/timescale, which in turn should deliver the best possible experiences for our end users.

When we choose to open up a dialogue and question some aspect of what is being built or proposed, we immediately begin to add value to the project as well as to the relationship itself. The latter being just as if not more important when looking at the longer term picture.

Encouraging an honest, constructive and pragmatic discussion means we are delivering on one of our core responsibilities: to educate and advise. This delivers value just as mocking up a design or fleshing something out in code does.

While we may be JavaScript wizards, PHP gurus or CSS fanatics with truly epic skills, we have a fundamental duty to highlight where something can be done better and share why this is the case, just as much as we are duty bound to write robust, secure and performant code.

After all, the client/stakeholder approached you (yourself or the organisation you represent) because you can deliver their vision or a variation thereof. Even at this very early stage there is an implication of trust being placed in you.

They did not have the resource to complete this task without you or another like you, and came to you with a budget/salary and a timescale asking you to execute this vision because they perceived that You Know What You Are Doing™.

This for me is the killer. You were selected to be part of tackling this project for the client/stakeholder, so you should first listen to what is being said, and then tell rather than ask them how things should be tackled, and let the conversation take shape from there. Indeed, sometimes advising that something should not be undertaken is actually the best course of action!

It is essentially about delivering value through the sharing of knowledge, expertise and best practice. And this value is critical to maintaining and increasing the level of trust between you and the client/stakeholder.

Of course, we are all just as imperfect as one another, so there are naturally going to be times where you make the wrong call. Fortunately for us, we get better with experience (or data!) and can reduce the likelihood of this over time.

We should never ignore the opportunity to push back when our gut instinct says it is right, because it is better to be seen trying to add value instead of bringing nothing to the table at all.

Some Useful Advice

There’s a number of things that can be done to make life easier in these situations. Here are a couple that I feel are important.

Push for early technical discussions

Getting a thorough understanding of the technical requirements early on in a project is a sure-fire way to reduce issues further down the line. Having proper technical input before concepts/designs are signed off (or even finished!) is an opportunity that should be taken whenever possible.

Encourage closer interactions between the design/project management folks and the developers when things kick off and throughout the rest of the project. This way you can increase communication and overcome any barriers or divisions that may exist.

You should make sure that kick-off calls/meetings with the client/stakeholder have sufficient time put aside for the discussion of how and why things need to function/behave.

This will provoke discussion around the technical challenges, provide an opportunity to make recommendations and prevent both parties from agreeing on a scope of work that has little if any genuine scoping. A list of a dozen bullet points does not constitute scope!

Focus on getting the ethos/culture right

For some developers, expressing themselves doesn’t come easily: especially when it means standing up for something in an environment where there may be conflicting opinions, tension etc. In fact, it can and often will be downright difficult, especially if you are a contractor!

For others, it comes as easily as discussing the faults of the latest blockbuster release at the cinema with friends, casually offering up alternative solutions. I count myself lucky that I’m more in this camp.

You can breed confidence by developing an ethos/culture where your development talent (whether that be in-house or sub-contracted) believes that they have the respect of everyone involved in the process, and that their input is invaluable to both the project and the business as a whole.

Confidence is exactly the shot to the system that is needed to encourage folks to speak up and passionately fight for change when they are working on projects. Speaking purely from my own experience, increased confidence has a direct link to improved code quality and better problem solving!

If you are a freelancer/contractor, respect yourself and your skills, knowledge and expertise. Arm yourself with solid research/rationale and most of all have no fear! Fortune favours the brave!

Pick the right battles at the right times

There are some battles that you will lose, no matter how hard you try to put forward a compelling case, complete with solid justifications and mountains of examples of it being done “your way” in the wild.

There will also be battles that you will have to step back from at critical points during the process, as they will potentially make it a more painful/costly/lengthily one for you, or cause damage to your relationships.  In these cases aggressively pushing back without first assessing the potential risk to your relationship with your client, stakeholder or colleague is a bad idea.

So fight the battles that look like you at least have a reasonable chance of winning, and occasionally roll the dice to try to change hearts and minds for some of the less likely wins if you are truly that passionate about the issue.

As for the battles that you know you have no hope in hell of winning? Document your concerns, ensure that the client/stakeholder is exposed to these notes (email, Trello etc) and then walk away. Put the kettle on or pour a glass of something stronger. It just isn’t worth the time and effort.

Finally, it goes without saying that if you decide to heed my advice and push back more, this doesn’t mean that you should suddenly become Mr/Mrs Obnoxious overnight…that won’t go down well at all!

Make the most of grey areas in scope

As developers, the scope of work and designs for a given project are pretty invaluable; confirming exactly what we need to build and how it needs to look.

However, many grey areas exist both in the scope of work and designs that can often provide opportunities to use our creativity and common sense to exercise a level of control.

The most common examples of this are when designs depict a particular element in its default state, but provide no guidance as to how this is meant to work when open, active etc. Recently I’ve worked on several projects where the mobile navigation design and layout has been left entirely up to us.

It would be irresponsible of me to suggest that you shouldn’t be consulting with the client/stakeholder in these situations for some kind of clarification: of course we have to reach out.

However, I do feel that where detailed specifications or visual guides are missing, we should be taking these opportunities and tackling them creatively; doing things the way we feel they should be.

We shouldn’t be afraid to ask a question about something that exists in a grey area at the same time we show something we’ve already built to address it.

Although this point is a little tangential, I’ve included it because these grey areas can often be a welcome and creative/fun distraction on projects where there is little or no chance to push back successfully!

Why Push Back?

Agent Smith: Why, Mr. Anderson? Why? Why do you persist?

Neo: Because I choose to.

At the end of the day, nobody can force you into the habit of pushing back. Despite the couple of thousand words you’ve read spelling out my opinion and offering my advice on this subject, I nor anyone else can force you to make these choices in your day-to-day development life. You have to want to push back.

We as developers should be taking advantage of every reasonable opportunity we have to push for positive, constructive change in our projects. Collectively we have a responsibility to our clients/stakeholders and, perhaps more importantly, to our end users that should not be taken lightly.

So, let us fight for the things that we passionately want to change in our projects. Let us find ways around the obstacles, get past the well-worn excuses and believe in our ability to make a difference.

Because when we refuse to let things slide and fight for positive change in our projects, we actually end up fighting for a better web, one small piece at a time.

And that, ladies and gentlemen, is a pretty just cause if you ask me.

Internet Explorer and the legacy that won’t go away just yet

This week marked the end of support for legacy versions of Microsoft’s Internet Explorer, after it was announced that support for all but the most recent version (IE11) would be withdrawn from January 12th onwards. A patch was released on this date that will regularly nag users of these older browsers, asking them to upgrade.

Every single day since the beginning of January I’ve seen dozens of developers folk praising (and rightly so) this move by Microsoft. It’s a positive step in the right direction, no question.

It’s a sign that things are starting to change, and that one day, one day we’ll be able to liberate our front-end workflow and resulting code of all the various poly-fills, workarounds and practices that help make the websites and products we build look respectable in browsers like IE7/8/9 as well as IE10 to a much lesser degree. What it doesn’t mean is that we can down tools and forget about them.

Let the numbers guide you

I did a search for tweets on the topic and this one raised the exact question we should be asking ourselves at this time:

When will our support requirements change? What should be driving this decision?

The problem is, there a lot of developers out there that are heralding the end of support for legacy versions of IE as the end of a lot of their woes: as if a Magical Front-end Unicorn has swooped in and transformed the landscape overnight. ***

In the long term the landscape will be different, but right now we (both site owners and developers alike) need to be looking not only at the wider trends that are widely reported throughout the year, but – as James alludes to in the above tweet – the actual data for the sites we own or are building for our clients to ensure that we’re not delivering a poor experience for these users.

Data published by leading authorities on browser trends (such as W3Counter, Browser Stats, StatCountern etc) and articles such as Sitepoint’s 2016 end of year review all confirm that Internet Explorer versions 6, 7, 8 and 9 still have a collective market share of approximately 3.5 – 5% of the desktop browser market. IE10 has a larger share, however this makes sense given that it’s the most recent of the browsers that are no longer supported.

Granted, 3.5 – 5% is a small percentage, but a small percentage of a whopping great number of users. These older versions of IE are still being used by millions of people, so we need to be making informed decisions based on the available data.

A note on the market share

Back on January 6th I posted something on Twitter about this which I thought summed up one of the big reasons why older IE browsers are still hanging onto this market share. Heather Burns fired back an interesting reply stating that she knew of an NHS website that still has ~25% of its users using a legacy IE browser; a perfect example of why the decision needs to be made based on the available data that shows exactly how users are accessing the site(s):

Even if we, say,  knock 10% off that figure to account for IE10, that’s still 15% of users that are accessing these sites via what many developers would consider to be a true legacy web browser.

The NHS is a great example of an organisation in one of the sectors I referenced in my earlier tweet that won’t be upgrading all users to IE11 overnight. Especially given the economic and bureaucratic issues they face when it comes to IT projects.

That patch I mentioned at the top of the post? It can be disabled by “enterprise” users: meaning any large organisation that has centralised control of software installed across a significant number of machines. There are hundreds of thousands (if not millions) of these organisations across the world accounting for many, many millions of users.

Make sure the pain is paid for

I, like many other web developers have become accustomed to catering for these older versions of Internet Explorer over the years. At both my former employer and at Make Do I’ve spent countless hours baking IE 7/8/9/10 support into boiler-plates that I’ve built to facilitate speedy and (relatively) hassle-free development.

As web developers we all know the pain that work to support these older browsers can cause. I’ve launched into expletive ridden, vitriolic rants about this work on more than one occasion, which is something of an understatement. We’ve all been that guy/girl on the edge, the computer programmer equivalent of Michael Douglas’ character holding the shotgun in Falling Down.

Yep, been there, thought that.

Granted, poly-fills have eased this pain a little, but it’s still painful and time consuming. Oh well, at least the client is paying for this support. Right? Right?!

Regardless of whether you’re working for an agency or as a freelancer, you should really be factoring legacy browser support into your quotes/proposals. If the client needs to support these older browsers then you need to be having a conversation about adding the required number of days at your usual day rate. Period.

Note: Don’t get me wrong, I’m still advocating that we look after these users, we just have to ensure that we as developers aren’t doing this for free.

If you or the agency you work for aren’t doing this, or you’re just throwing legacy browser support in as “part of the package” then you’re missing an opportunity to both increase your revenue and help contribute to the decline of the market share these browsers have.

Mark Wilkinson made an excellent point in response to a tweet of mine:

Quite right too. The web design/development community can help knock a few decimal points off those market share figures by making it clear that we won’t continue to offer support for free.

The increased cost of carrying out this work will (to a degree at least) lead to a decrease in support for these browsers when new websites and online products/services are launched. The result is that users of these older browsers will end up wanting the better, richer and more functional experience that comes with an upgrade and therefore a modern browser.

Furthermore, many frameworks,libraries and other resources that we include in our workflows are going to drop support in the coming weeks and months: some already have such as ReactJS dropping support for IE8 on the day support was withdrawn. This ultimately makes the task of providing support for older browsers using these kind of technologies more difficult as they continue to evolve, which is detrimental to the overall user experience.

Note: Naturally, progressive enhancement ensures we can still provide a usable, functional experience, even if that experience is considerably more “basic” than the “full fat” version.

Increased development costs combined with poorer user experiences should hopefully drive more organisations (directly) and users (indirectly) toward upgrading to the most recent version of Internet Explorer or indeed, other browsers like Firefox, Chrome, Safari or Opera.

Wrapping up

The pace of decline in market share for these older versions of IE is going to speed up as a result of this patch and all the public relations surrounding the withdrawal of support. However, for all we know it could be another 12-18 months before it’s low enough to truly justify downing tools and abandoning practices. That said, I sincerely hope that I’m wrong and it drops off quickly!

*** The Magical Front-end Unicorn (MFU) has this power at its disposal, but chooses not to wield it. It’s the MFU Gotham deserves, but not the one it’s going to get right now.

Thoughts on contributing to WordPress

When I attended WordCamp U.S last month, I tried to spend some time in the lightning talks track to mix things up a little bit.

One of the speakers on the second day was Morgan Estes, who gave a talk about taking the first step to becoming a WordPress contributor. I found his talk inspiring, and it really changed my personal perception of contributing.

I think it’s fair to say that there are plenty of others in the WordPress community who, like me, share the perception that contributing to WordPress as contributing code to core.

Contributing code to WordPress core is an itch I’ve been wanting to scratch properly for about the past twelve months. It’s actually in my list of development goals for 2016. That said, I have not, nor will I ever feel any pressure to make this happen. I’m content with the fact I’m doing great things with WordPress whilst working on client projects.

However, I’d really like to get more involved and share my own ideas (and code!) to help improve WordPress, so I can give back to the community of users that I’ve been a part of for nearly ten years in one way or another.

What Morgan made me realise that day was that I am giving something back, with my other contributions as an active member of the WordPress community.

For example, 2015 was the year I ventured into public speaking, delivering talks at couple of local WP meetups and two WordCamps. When I first decided to venture into speaking I had one goal: to help at least one person. From the discussions I’ve had these past nine months I know that my talks have helped at least a few dozen people, meaning I’ve already contributed something to WordPress and made a difference. Result!

I’ve now got the confidence to write and deliver more talks for the WordPress community, which is an ongoing commitment throughout 2016 and beyond. I may not be the best or the most experienced speaker in the world, but sharing my experiences and things I’ve learned is going to help others and that contribution means a lot to me.

Plugins is another area where I’m trying to give back. My first two plugins are now listed in the WordPress.org plugins directory, and I plan to continue writing plugins moving forward. This means I’m now committed to contributing code to the community. Granted, it’s not core code, but that doesn’t matter: my plugins are still going to help at least one person.

This is the best way to look at contributing. As Morgan said himself during his talk, it’s all about helping someone scratch the itch they have, or doing something that helps you scratch your own itch. The best thing is that quite a lot of the time, doing the latter also means you’re doing the former!

At Make Do (organisers of the WP Sheffield meetup), we’re really focused on increasing our contributions to WordPress in 2016. WordPress helps each of our team put dinner on the table every month as a result of our client work, so it’s important that we give back.

No matter what you’re doing: whether it’s translating WordPress, writing plugins, building themes, speaking at WordPress events, helping on the support forums, writing/updating documentation or even just dealing with WordPress questions/issues on Twitter you’re helping at least one person in the community.

And that is just as helpful and rewarding as each line of code you contribute to core. Plus, you stop people from scratching…