“I want it all. (I want it now.)”

Freddy Mercury is dead. But the spirit of his works – particularly this one – lives on, most notably in the mind of type all-dominant remitter employing software developers. As sung in another old song: I don’t know what I want but I know how to get it.

Whatever is technically possible, he wants to get it. And he wants it instantly. Regardless if it makes sense or not. The most delicate thing for a developer is to have a strong view on this issue. He, the all-dominant remitter, doesn’t like it.

Truth is, there are – of course – for every remitter legitimate requests or demands based on bare necessities. After all, the developer has to reinforce his customer’s business not to impede it. But as soon as he detects dispensable or just nice-to-have demands for features and dares to contradict he will end up recognized as indignant and ignorant for not worshiping the all-dominant entitlement.

Having said that, the willing and submissive developer quite often has to learn his lesson when the remitter is not happy with delivered results on demand since they may not be as spectacular or efficient as expected.

The reasons of these lacks of consensus are many, but there are 4 which are the most conspicuous and therefore most destructive ones:

• Language Barrier
• Attempted Extortion
• Gap Search
• Mind Change

Language Barrier

All-dominant remitters – usually represented by executives (MBAs), not users – and developers do not speak the same language. The may use identical words or terms, but they do not understand each other anyway. And if it comes to „Who’s right?“, guess who’s queen?

Take a look at what Joel Spolsky said about this, years ago but still as true as ever:

“I promised to tell you a secret about translating between the language of the… nontechnical managers… of your software and the language of programmers. You know how an iceberg is 90% underwater? Well, most software is like that too – there’s a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we’re talking less than 1%. That’s not the secret. The secret is that People Who Aren’t Programmers Do Not Understand This.”
Source: The Iceberg Secret, Revealed by Joel Spolsky

The learning from this issue is, get at least one person at the table who speaks both languages – fluently – with the talent to translate without loss of essential content.

Attempted Extortion

That’s the most miserable part of every business rendering services: There is always someone who does it cheaper. Or more submissive. Surely not better. But you might find yourself confronted blackmailed with these facts. Do not ever take part in this vicious game or the sword of Damocles will always be hanging over you. Never forget, you are selling software and services – not your soul.

Gap Search

Gap detecting seems to be one the most favourite engagements of all-dominant remitter before detecting and crediting the capabilities of a software. And it’s easily done, either by claiming missing functionality or simply by a missing button.

But what is it all about? A missing functionality is usually one singular person’s view on an in other respects highly valued enterprise software. Should the sole demand of a single person be the rating measure for an entire software company and its product? Couldn’t the opposite be true and this person goes for just cosmetic (the button) and needless (the functionality) features? Imagine features with a just-in-case-once-a-year option as a quality criticism of a high quality, continuously improved software!

In Jared Spool’s podcast Hagan Rivers calls it „The Get The Features In Mode“, no matter if they are real pain points (for users, not MBAs) or not. Though elimination of pain points has more impact on users than the delivery of putatively missing features as part of a feelgood management:

“You should have a good list of your user’s current pain points. What’s aggravating them in the software? Every time you do a release, you ought to knock a couple of those off that list. I worked with a client. We did some field studies. We watched the users using the software. I made that list of pain points…One of them, it was seven clicks to do this one thing that people did a lot…We fixed it so it was one click…When we finally showed the new version to the users, they were more excited about that one little fix than they were about the six other new features that they had also wanted.”
Source: Time Traveling with Enterprise Applications by Jared M. Spool

The reclamation of missing functionality should never discountenance any developer (“Gaps? Which gaps?”) but encourage him to touch the more sensitive issue of pain points. And there are many of them.

Mind Change

Given the developer gives in and commences to work on a specific, but in his eyes needless assignment (remember: the 90% of his work), with a – not rarely – fixed fee, and finally finds himself confronted to permanent requests on changes or additional duties. Where will it take him? Into sanitarium, most likely.

At least into an endless loop of programming for unfortunately not endless money. What kind of final quality level would one expect? Executed on a high level of frustration, desperation and internal pressure from his own controller. Don’t even think about it.

The developing company – with every individual involved – has to make sure the remitter makes up his mind once forever to prohibit undesired surprises, on the work side as well as on the reward side. Else you have to employ more lawyers than developers. A binding contract may be a solution to this problem, but not on a humane emotional level which most of the developers consider as important as collecting their wages, believe it or not. Frustration cannot be compensated with money at all.

Conclusion

After all, it seems to be better to avoid additional contracts by avoiding additional specific assignments. Just improve your product regularly according to the real needs and demands of the entire industry. Eliminate pain points, prohibit mind change, and you will most probably identify the language barrier as non-relevant. You’re a developer, not a yes-man. Let your results speak for themselves. That’s a language everyone can understand.