Programmer Productivity Starts With Requirements, Not Tools!

Are you really sure what makes a programmer productive? Is it VIM instead of Emacs, the latest Haskell web framework or your favourite NoSQL database?

Sorry, but if you focus on tools, frameworks or even processes, you got it backwards! Real programmer productivity starts at the very beginning: Proper requirements.

Why you as a developer must care - not only the business staff !

Sure, the founder/product owner/team lead/name of the month must care to build something that a customer ultimately pays the company money for. But what about it from a developer’s view?

Ever been in the situation where someone shouts over the table: „Just start building XYZ right away, if any questions pop up, we will deal with them during development. We got a head start anyway“ ?

We call that: Start first, finish never. Nothing beats building something, where half of what you are building is actually still unclear.

How do you know you are done DONE?

Not surprisingly, not knowing 100% „what“ to do, leaks a lot into „when are you finished?“ „Oh, we just forgot this…and that!..And actually it should also be doing this! That point of the feature…dunno really?“

And how do you go about testing unclear requirements? This has nothing to do with your favourite BDD tool of the month, or your freaking out if someone does not always test first. (Even though we think there are some, let’s call them preferences, that make building software easier.).

If the input is unclear, tests are unclear and the output is even more unclear.

You are always super-motivated, right?

But the worst part is, that frequent unclear requirements are a sign. A sign that your business people are unsure of what your customers really want/need/pay for.

Unfortunately this also means, that a lot of the stuff you build is for the trash can. Nothing keeps programmer motivation and ultimately productivity higher than repeatedly baking bread and throwing it in the trash while it is still hot.

What exactly is a proper requirement ?

Now what exactly is a proper requirement? Is it a sentence that is written on an index card and starts with „as a user I want to be able to use my Asian CCB credit card?“. Nope.

We actually came up with a fancy sounding process for generating and checking proper requirements. We will go into detail on the individual points in our next blog articles, but here’s the abstract spoiler for what a proper requirement is. (Oh, and we'll spice it up with real-life examples from the requirements engineering for the new BMW (car manufacturer) website a while ago.)

A proper requirement has (1) been worked out with business people AND programmers, with two-way street communication. It has (2) been repeatedly deconstructed. deconstructed. deconstructed. And it has (3) been defended, which includes what we call „angling“ and „skinning“.

STOP it already ! I'm a programmer, requirements are not my job!

Yes, in bigger organisations you most often have dedicated business analysts, whose sole job is to iron out detailed requirement specifications before they get passed to „implementation teams“. And in dreamland this all works flawlessly, and you just sit down and start coding, but in reality not so much.

Anyway, the smaller an organisation gets, the more a programmer becomes a hybrid. The founder might shout across the table: And you as a „programmer“ have to not only sort out the implementation, but also what the hell this is all about.

In any case, you should be a professional !

As much fun as it might be to read through he upgrade path of AngularJS 2.0 instead of accustoming yourself with your customers problem domain and requirements :

At the end of the day, as sad as it might seem, your technical skills, voice of frameworks or algorithms are only a part of your day-to-day job. And the basis for all development work is : proper requirements.

Next Step: Share your experiences in the comment section or on our blog, subscribe to our newsletter and stay tuned for the follow-up articles!