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.

Add a new VVV development site just for WooCommerce

I’ve spent the last couple of weeks carrying out a number of updates to Kapow!, our in-house WordPress development boilerplate that we use at Make Do as a starting point for all new client sites, and as a result of this I’ve had to upgrade my local set-up to use the super-shiny brand new Varying Vagrant Vagrants (VVV) 2.0.

VVV makes the process of provisioning new local development sites a breeze, and I decided to take the opportunity to create a new local environment for WooCommerce plugin/theme development, testing and general tinkering.

Granted, I already have the wordpress-default site available, but I’m keen to keep that for building and testing vanilla themes and plugins: so the goal is to have two separate environments.

Forking the default provision script

VVV 2.0 pulls down a couple of GitHub repositories containing the provisioning scripts necessary to install the default wordpress-default and wordpress-develop sites when you run a complete provision: such as when you install or upgrade VVV.

The beauty of this is that the default site repositories can easily be forked and modified for our own use. I’ve forked the repository that is responsible for setting up the wordpress-default site and have modified it to change the local domain to local.woocommerce.dev, change the database to wordpress_woocommere and install the WooCommerce plugin using WP CLI, amongst other small tweaks. You can find the fork here: VVV WordPress WooCommerce

Adding the new site configuration

In your vvv-custom.yml file you should add the new WooCommerce site directly below your wordpress-default site configuration. Here’s how my file looks:


As you can see from the above Gist, in the new site configuration that I’ve called wordpress-default-woo I’m pointing to my fork of the default site repository, rather than the VVV version. You can call this site configuration anything you like, as long as it remains in the same format e.g. your-site-slug.

Provisioning the new site

One of the things I love the most about VVV 2.0 is the ability to provision a single site at a time, rather than having to endure the full provisioning process.

First of all ensure that you’re in your root VVV folder (mine is ~/Vagrant for example) and then execute the following command to provision the new WooCommerce development site, replacing wordpress-default-woo with the site slug that you’ve chosen:

vagrant provision --provision-with=site-wordpress-default-woo

A couple of minutes later you should see something like this:

Huzzah! As you can see from the output of the provisioning script, you will not only have a default copy of WordPress installed and configured, but you will have the latest stable release of WooCommerce installed and activated.

Now, if you visit local.woocommerce.dev in your browser and you were fortunate enough to experience no issues during the provisioning process you should be treated to this.

Now you have a totally separate WordPress environment complete with WooCommerce!

UPDATE: I’ve now tweaked the provisioning script to automatically install and activate the Storefront theme as well, providing a more appropriate base theme to work with.