Work smarter

Requirements are the first step to programmer productivity

Natali Vlatko
Thinking image via Shutterstock

Programmer Marco Behler believes that productivity starts with requirements, not tools. Developers need to care about the end user and stop living by the “Start first, finish never” routine – where half of what you’re building remains unclear.

Marco Behler is a programmer who believes he has his priorities straight: developers need to focus less on tools and more on proper requirements in order to unlock “real programmer productivity”. In a post from earlier this year, Behler highlights the need for developers to care more about the end user.

Focusing on tools, frameworks or even processes is labelled incorrect in Behler’s book. And what’s more, this misinformed belief can lead to unclear testing. “If the input is unclear, tests are unclear and the output is even more unclear”.

Start first, finish never

The maxim “Start first, finish never” is a situation that Behler identifies as a common occurrence in programming teams. Imagine the following scenario: You’ve been instructed to start building something immediately, and if any questions pop up, they can be dealt with during development. Your boss wants to get a head start on things, but what is it that you’re actually building?

Nothing beats building something, where half of what you are building is actually still unclear.

The idea about requirements being paramount could also tie in with Kent Beck’s treatise on ‘Making Making’, where feedback is tied to the decisions about how things are created. Beck believes developers should invest in making making “when it results in more frequent or more comprehensive feedback for your making decisions”.

SEE ALSO: Making Making – Decisions about creating things

Because your requirements remain unclear, you never really know when you’re done with the work, according to Behler. How do you know that you’ve actually finished the job?

What is a proper requirement?

Behler’s definition of a proper requirement has been summed up as the following:

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“.

Working with proper requirements is part of a programmer’s job, where their position is somewhat hybrid: not only are you responsible for the implementation, but also the requirement specifications that an implementation team might be working with. Behler states that while bigger organisations will have dedicated business analysts to sort out the requirement stuff, smaller businesses aren’t as lucky.

Accustoming yourself with your customer’s problem domain, rather than reading up on the latest updates for the hottest framework, is singled out by Behler as the basis for all development work. And fellow readers seem to agree: Commenter Sasi Pallekonda noted that “developers should not only think of what data structure to use, but also how the requirements fit for the end user, and see how it should be dealt with”.

What do you think? Do you share Behler’s sentiment? Let us know in the comments below.

Natali Vlatko
An Australian who calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for (S&S Media Group).

Inline Feedbacks
View all comments