5 reasons why “can we just” should be banned

There’s a disease that plagues every digital agency, the sentences that push the assumption-o-meter into the red. “Can we just”, “it’s simple”, “it won’t take long” just to name a few. These sentences induce panic attacks for us developers, beads of ‘panic’ sweat engulf our heads as the words come tumbling from account managers’ mouths. So why are these phrases so damaging?

1. ‘Just’ implies simplicity

‘Just’ is my most hated word in work, and one I hear too often. ‘Just’ implies simplicity, simplicity comes at a cost. What is simple from a usability point for example, usually requires input from a UX team and then development.

‘Just’ implies simplicity, simplicity comes at a cost.

The input from UX means research, testing, user profiling, etc. The development cost is increased when the ‘simple’ functionality touches multiple technologies to implement.

WordPress example, reordering of posts in the admin post list

I was asked some time ago by an account manager “Ste can you estimate a task to make it so the client can drag and drop posts into the right order in the admin screen? It won’t take you long, it’s just straight forward”.

In this example, the AM is making assumptions. He is assuming the task is ‘simple’, ‘straightforward’ and without the technical background, ‘how hard can it be’? Let’s take a look at what we need to do to achieve this:

  • Create an ajax endpoint that stores the new post order, and of course, we need to secure this with a nonce field.
  • Write the javascript which allows dragging and dropping of elements in the dom to set the order, this will post back to the ajax endpoint to set the order.
  • Wait! The endpoint has returned an error. We need the javascript to handle this
  • Oh no, the post list is paginated, how do I handle this? “UX guys, I need your help”

The estimate is scrutinised, “why is it so expensive? It’s simple!”. After more expensive time wasting the estimate is approved, the reordering capability is written.

The AM then says “why can’t I reorder pages?”. Another assumption not communicated to the developers. See how this quickly becomes an issue?

2. Assumptions are expensive gremlins

Continuing our WordPress example, the assumption that the reordering will work on both posts and pages means we now need to make further code changes. We have a clear instruction, we specifically want to add the reordering capability to posts and pages. “What exactly was the client requirement?” I find myself asking. “They just want to reorder posts and maybe pages”. This leads me onto the last point.

Can we just

3. Assumptions and unqualified solutions are sold into the client

The account manager has sold the solution to the client as being ‘quick’ and ‘simple’ to the client, they’ve bought into the idea, yet again I reiterate “it’s just reordering posts”, “how hard can it be?”. After all, we can “just install a reordering plugin”.

At this point, our solution has already gone over budget due to assumptions, the client is upset. We can’t use a plugin because one that exactly fits the requirement doesn’t exist or is poorly written. Who’s fault is it? Somehow invariably it’s the developer’s fault as they didn’t get clarification.

If you are a project manager or account manager, designer, stakeholder, whoever. Developers cannot be expected to ask about every single eventuality and edge case.

4. ‘Just’ and ‘simple’ devalue the skills required

Finally, all this assuming and solution engineering is damaging. It devalues the work and skills required to fulfil the client requirement. The endless battle and frustration are felt, and neither parties want to accept responsibility. This leads nicely onto the final point.

5. The cost of assumptions creates an unhealthy blame culture

The AM believes the fault lies with the developer for not asking about all the possible scenarios and edge cases. The developer blames the AM for failing to ask the client the right questions, for solution engineering and for making assumptions. How do we fix this?

Change the culture

I am going to use the word ‘simple’ here. It really is simple. Everyone in a team should know the limitations of their ability and experience. Solutions should not be sold to the client without the experts in their respective fields being consulted. Finally, understanding what exactly the client is trying to achieve by involving UX and developers in the requirement stage will help inform the task breakdown.

Do you have these same frustrations? How do you overcome them? Hit the comments below.

Ste

Web Developer living in Manchester, working for Studio Skylab (http://www.studioskylab.com). Views and thoughts are my own.

You may also like...

5 Responses

  1. LD0GG says:

    Disagree, it’s all about building client relationships to ensure the revenue stream keeps flowing. Sure we might not make as much money on a per project basis but the number of projects can increase if we can exceed client expectations.

    • Ste says:

      Do you want me to help you pick those ‘low hanging fruit’ while engaging in some ‘blue sky thinking’? 😂 Make me a brew, Leo!

    • Dirk says:

      @LDOGG Your statement is the root cause, for the downfall of companies that provide software solutions. Wither it’s as a product or a service.

      Meditate on the phrase: “Intellectual property is nothing without the intellectuals.”

  2. AnonymousDev says:

    Yeah, I work for one of the world’s largest companies and this is a common frustration. Unfortunately, to avoid the blame culture, we just add at least 50% to our estimates of the time it will take, because we ALWAYS hit one or more gotchas in all parts of the system like the one you illustrate above. We nearly always come in on time and the beautiful irony is that IF the non-developers involved in the project leave fewer than usual holes in the specs then we come in early and WE get the credit.

  3. Dirk says:

    @Ste After 20 years as a Software Engineer of one kind or another, I can give you this advice:

    Every morning you walk into work, go the the AM’s desk, smile politely and say: “If it was simple, easy or quick, you would not need someone like me to do it!”

    Then, in the afternoon when you leave work, go to the AM’s desk again, smile politely and say: “Your lack of planning, is NOT my emergency!”

    When they push you to do a release on a Friday afternoon, repeat this: “I take no responsibility for this, it’s your decision, you will support this over the weekend!” Then make them sign a release form to that effect.

    It took me 10 years to discover these gems. Ever since I’ve started using this, especially the Friday afternoon release one, my life has improved dramatically.

Leave a Reply