Menu

Sh!t Software Developers Say: "I'm Blocked!"

Episode 20 - 27 Jan 2016

I'm a software developer. I've said the words "I'm blocked" many times.

I never lied...

... but I wasn't always correct.

In this video, we'll look at a specific example of THREE development teams - nearly a dozen developers in total - declaring themselves blocked.

But were they truly blocked?

And if they were, could they have been "unblocked"?

Software Development is hard. Unpredictable. There are problems around every corner.

So here's the thing. If a dev tells you that he or she is blocked...

Should you believe them?

"I'm blocked"

I'm a software developer. I've said the words "I'm blocked" many times.

I never lied. But I wasn't always correct.

Sportlobster

Sportlobster is a sports social network.

Like most online businesses these days, it's available on several platforms,

Meaning that there's:

  • a website
  • an iOS / iPhone app
  • and an Android app.

Now, all three platforms do much the same thing, so Sports Lobster was smart enough to centralise this functionality into an API.

One of the new features that was added during my time at Sports Lobster was the ability to let people log in using their Facebook account.

As with every new feature at this particular time, it was super urgent.

For that reason, all four teams were give the task on the same day.

For My team - the API team - the task was clear. We jumped straight in.

Three remaining teams immediately declared themselves blocked.

They took it upon themselves to pass our desks at regular intervals to ask how things were going and when we expected to be finished.

This was not helpful.

As I recall it took three or four days to get the Facebook login feature developed and tested.

Then, and only then, did the web, iPhone and Android teams set to work.

Rewind

Let's rewind this.

"... remaining teams declared themselves blocked."

Not one of us questioned this at the time.

But the truth is that none of these teams were truly blocked.

All of them could have started work.

Let me explain why:

The sign in with Facebook functionality requires the API to do some complex stuff - including all of the necessary interactions with Facebook itself.

But all of the work it does boils down to this:

it needs to RECEIVE a request. And it needs to send back a RESPONSE.

That's about it.

Oh, and the response can can be either YES or NO.

Hardly rocket science, is it?

Missed opportunity

If we web team had something that did just this - something that would receive a request and respond with yes or no - , it would be able to start work immediately.

Same goes of for the iOS and Android teams.

Each of the teams was capable of building such a thing. But it didn't occur to them.

Embarrassingly, it didn't occur to the API team either.

We were the team that best-placed to build it. We could have quickly built something that all three teams could have used.

A couple of hours work, and all FOUR teams would have been hard at work. The new feature could have been released days earlier.

Mocking

This general approach - to create a "fake" version of all or part of an external system - is known as mocking. It can be a powerful antidote to "being blocked"

Talk to you next time.