A programmer’s road to productivity - Step 2 : Battling assumptions

April 21, 2015 - Marco Behler

Now we have reached the most dangerous phase when working with requirements. Remember, we started deconstructing our should be really simple login-box requirement.

After a chat with our boss we made some progress, but really only reached the tip of the iceberg.

The problem: You seemingly have a common understanding with the business side on what to do, but in reality you are still way out of synch.

That is why we will keep on deconstructing, to get rid of all assumptions until there is no more room for interpretation.

Lost in translation

Unfortunately talking about requirement is not as easy as „you say to-may-toes and I like to-mah-toes“.

On the contrary: the only assumption you should make, is that when two people, say you and Mr. Biz boss use the same words, they probably mean two completely different things - unless you have a history of common understanding.

What your boss said

So your boss came in and said that every existing customers from (n+1) CRM systems should be able to login. He might even have given you a point of contact to inquire further information/documentation regarding the CRM systems. All good, right?</p>

I say „assumptions“ and you say „winter is coming“.

What you might hear

Being a techie, it might well be that you immediately jump to these thoughts:</p>

„Well, CRMs, they are probably separate systems somewhere and offer some REST interface, where we can pull down data. Easy.“

„If there’s multiple CRMs, let’s start mapping out a tiny wrapper, can’t be that difficult to abstract away customer data across a few places.“

„Ohh..and even better. Brett Wooldridge is writing his new HikariJSON library, and marshalling/unmarshalling those first and last names has never been faster!!Yes!!!“

I say trigger words and you immediately think more assumptions + implementation details.

What reality says - Questions, Questions, Questions !

Let’s get together with our boss or our friendly contact again and continue playing infant.

What is a CRM system really? Are we talking about a product running somewhere? Something self-made? Or, because of politics, security and what-not, are we merely talking about a daily Excel export of customer data, so no CRM system at all? (Or, oh boy, is everything simply in some…“cloud“ :P)

How do you recognise an existing customer? Is an email enough? Do the CRM systems support live look ups? Are there any infrastructure/load restrictions on those CRM systems? Is there documentation? Is the documentation up-to-date?

Are all needed calls there? Are they properly described? Is there a (test) library? A staging environment? Does the other side still need to develop something?

Worst of all

Are we really talking about a „login“?? Sure, existing customers should be able to automatically login. But what does that mean ?

Suppose they don’t have a password or some unique key they magically got when they bought their car. So let’s just email every (?) existing customer a random password..yeah right ;)

But maybe we simply notice an existing customers email/last name combo when he tries to register on the website and then give him a special registration workflow + password at the end.

And then he can automatically login…so we are not talking about a login after all, but about a special type of registration!

You hold that thought, go to your boss and tell him about the login-vs-registration idea, which he simply answers with: „Well, that’s what I meant all along“ ….

Ok, ok, but what does this look like in practice?

Next Step: Let’s take a break. We have all these questions popping up. We need a practical way of ordering all these questions and assumptions (hint: at the beginning, the notepad of your choice is enough), their corresponding answers, group them and then continue with our deconstruction. So next time, it is going to be practical time!

Spoiler Alert: As these articles got really nice feedback so far, chances are that in the near future all of this will be compiled into an e-book on requirements. Real-World examples and applicable, practical info only….

As always, if you want to be the first to get notified, join our newsletter!

(Update May 2015: Check out our related, upcoming book: Customer Requirements - Everything programmers need to know before writing code)