“It can’t be done!” O RLY?

It makes me sad when a PO presents a new story and the first thing out of a developer’s mouth is “It can’t be done!”*. A story is meant to be the basis of a discussion – “It can’t be done!” is harmful to this discussion.

As long as there is no timeframe attached to the story, “It can’t be done!” is rarely true.

Just like “I don’t have time for that!” is code for “It’s not a priority”, “It can’t be done!” is usually code for something along the lines of:

  • We’d have to do a major rewrite. It would take months!
  • That code is chaos. No one knows how it works. I don’t want to touch it. I’m afraid to break something.
  • I can’t think of a way to achieve it. (In this very moment.)
  • I don’t want to do it.
  • I think that feature’s stupid but you won’t listen to me, so it’s easier if I declare it impossible.
  • I could do it, but you’ll just change your mind in a week’s time and I’ll have to throw that code away.
  • We can’t afford the expensive thingamabob, we’d need to achieve that.

There aren’t many things that truly “can’t be done”. I tried to come up with something impossible and my first pick was “touching my nose with my elbow”. But wait, that’s not really impossible! There are at least two solutions: broken or severed arm. Gross and very painful but possible. Would I ever pick such a “solution”? No, because I understand the “investment” I would have to make.

So, if you’re a developer I beseech you to talk about the implications of doing something rather than just a binary “It can’t be done!”

Ask about intent: explore the “so that”-part of user stories. What’s the underlying goal?

Maybe the nose is itching and your product owner thought the elbow would be the right part of the system to do the scratching. Together you pinpoint the finger as a much better suited and painfree scratching device.

Save “It can’t be done!” for those requests that truly are impossible, like “resurrect the dead” or “make X do Y in <impossibly short time>“. An unrealistic timeframe can really make things impossible. But once again, you can inform your product owner about tradeoffs, ask about the goal of the story and the reason for the deadline. Give effect mapping a try to find a faster / cheaper way to reach the goal.

* The original German phrase I’m referring to is “Das geht nicht!”. There is no literal translation. Alternative translations apart from “It can’t be done!”, are “It won’t work!” or “That’s impossible!”.

7 Comments “It can’t be done!” O RLY?

  1. illo

    I understand your point and also get angry if things are marked “impossible”, even though they’re clearly not. Everything’s possible in some way.

    But most of the time the phrase “Das geht nicht!” is used in terms of “It would not be clever/meaningful to do so.” … Maybe better expressed as “Das geht so nicht!”. Then I highly encourage any developer to say so and find a better way.

    1. Corinna

      Hi illo!
      Thanks for pointing that out!
      In the situations I thought about, there sometimes wasn’t even a way / solution / “how to do it” given. And still “Das geht nicht!”, although there’s no timeframe, no (explicit) budget, no … Makes me sad.
      In any case, I think we’re aiming for the same thing (more communication) 🙂

  2. Thinker

    I once said “It can’t be done” to my boss. Essentially he asked me to pre-seed an input field with information not yet entered (and no default value present). Information not yet present in our database.

    1. Corinna

      Oh, Thinker! How nice to find you here!
      Okay, I concede there are cases – such as yours – that are impossible. But way less than are declared such 🙂

      1. Thinker

        Agreed. Fully. 🙂
        Related might be “Cannot be tested”. Mostly this is simply very difficult to test, which leads me to question the design…

        As to why I’m here, some pathway of thought lead straight to you, so I looked you up on codebabes. Have you got some pointers to literature about designing user interfaces?

    2. Corinna

      Sure! Depending on what you’re looking for, one of those will do the trick:
      – User interface design for programmers – Spolsky
      – Don’t make me think – Krug
      – GUI Bloopers – Johnson
      Unless you want more of the psychological background and underlying principles, then it’s
      – The design of everything things – Norman

      Let me know, if it was helpful 🙂

  3. Rafael Zamana

    As a programmer and a ScrumMaster, sometimes I have to ask the team “Why it can’t be done?”, because for my point-of-view, it can. I try to make then realize the options and convince me.
    In 99% of the time, they realize that they were overreacting and was just the first answer that they knew.
    But in the 1%, the story was badly formed, and was missing some of the essential parts.
    I’m trying to remove the “It can’t be done” from my team.

Comments are closed.