Nope, it's not a blog post about regrettable fate of unemployed. Client-less programmers are someone else and I'm pretty sure you've already met some of them or maybe even you've played that pitiful role in some moment of time or even (horror of horrors!) that's what you do for living these days.

Client-less programmer (C-P) is someone who does not code to fullfil the requirements brought up by client (no mattern internal or external) / product owner / user / etc.

... as opposed to the programmers who do the work for some kinf of client (let's call them C+P for the sake of brevity).

What does C-P do then? Who are C-Ps?

Examples? Here you go:

  1. So-called "evangelists" & short-term deal experts
  2. Architects, who just do "architecting"
  3. People condemned to play 100% maintenance / support role
  4. "Free electrons" / Firefighters
  5. People who write tests for other teams ;P

Etc. I guess you should get the idea by now. What's so wrong with being one of them? Their life seems to be overflown with joy, happiness & carelessness:

  • they don't have to speak with all those ignorant business people, who can't understand what UML is (yes, put the sarcasm detectors on)
  • they don't have to go through all this requirements gathering & the pain of final acceptance either
  • they don't have deadlines, they are rarely forced to do any estimations they have to meet
  • the transparence of their work is limited, so the overall pressure on them is lesser: less stress makes life more enjoyable ...

Well, sort of. But there's always a price.

These people are extremely quickly loosing focus on what's really important: on the actual business value that's supposed to be delivered by programmer's work.

People who don't address the requirements directly tend to fall within one (or some) of the following traps quite quickly:

Ivory Tower syndrome

What they is quite likely to be not useful at all, because they invent their own requirements, but they lack a proper perspective. It won't be a problem if they make products for themselves, but it's worse when they are supposed to deliver for other teams. Situation gets even more bogged if such C-P programmer / team has a strong position within the organization and he / them can force their inventions regardless of how detached from reality they are ...

Toymaker syndrome

Lack of deadlines, lack of accountability & transparency may cause C-Ps slack time to get out of control. It doesn't necessarily mean they are gonna browse the internet & play games whole day: nope. They may spend whole days on toying with pet projects, endlessly re-factoring overgrown solutions that perform 1200% of what's actually needed. Some call it gold-plating, but the point is that the lack of actual requirements causes C-Ps to loose their pragmatism.

Lack of ownership

Lack of ownership is a killer for all the expects / consultants / evangelists. They come & go - do some firefighting, make few ad-hoc decisions to cease the fire, etc. And then they move to another project. And another project. And another project. They never live with the consequences of their decisions, they always skip the dull, maintenance part (because it's for the "ordinary / mundane programmers") - I say that in many cases the experience of this people is over-estimated by far.

Communication gap between C-P & C+P

Everyone who has done some commercial programming knows that "the soft stuff is usually the hard stuff" - communication with business people / analysts / testers may be really painful, because of different backgrounds, different priorities, different way of thinking, different ability to abstract & model things. Unfortunately, a similar communication gap appears between C-P & C+P programmers, mainly because C-Ps don't experience all the everyday problems C+Ps struggle with, for instance:

  • legacy code
  • limited testability
  • technical debt
  • deadlines approaching

C-Ps may not understand the painful compromises C+Ps have to make on the daily basis.

Let me stop here for now ...

... because this already gets longer than I've initially assumed. Hopefully you get my point - the IT products, artifacts made from the code we write - it is intended to add some business value: the further you're from adding this value:

  • the more you loose the proper perspective
  • the harder it gets to set proper priorities ...
  • ... & make sensible decisions
  • and in the end - without accountability & commitment for target, there can't be any personal accomplishment
Share this post