Doing Business

Traditionally the choices have been three.

  • The unregulated society: in which business acts after its own interests and meets with competition others who conflict with its interests
  • The regulated society: in which business is dominated so that necessarily choice of action is delimited and freedom to do business and competition are controlled.
  • The middle way of interventions: wherein a regulator (usually a Nation State Government) is intrusive into unregulated business, so as to ameliorate the harsher social consequences which arise out of an untrammelled free market

In practice, concerning Choice 1, (unregulated business): it has merely acted to shunt from pole position regulated controlled activity down the economic and social class ladder.

What I mean is that in societies where business is relatively unregulated employers have built up their large companies as closed-off organisations, within which employees to a greater or lesser extent are exposed to command and control.

Employers’ command and control is seldom much less oppressive inside their organisations than that carried on by Nation State Governments which choose as their model a regulated controlled economy

Freedom and choice and opportunity pertaining to unregulated business models are enjoyed chiefly by the persons who own and run businesses under this model

Necessarily it is argued, according to traditional thinking, these owners/operators are compelled to control and command their employees so that their companies are able to perform in the most effective efficient way against their competitors in the free marketplace.

Normally speaking there is inside any business organisation which is operating within an unregulated economy a hierarchy of control by which those high up enjoy lesser degrees of direct oppression and control whilst those low down bear greater degrees of these.

These degrees of direct oppression in the main correspond inversely to the extent that:

  • a) Any economic business or society is unregulated, and
  • b) Any business employee is presumed by his/her employer to hold a stake of some kind in the business. (This is why a senior manager will receive higher wages and obtain to a higher degree of status, often also having lower graded employees to control and direct. Such a higher grade employee will be presumed to have a greater stake in the organisation (and so also have more to lose from dismissal) than those whom he controls and directs.)

Logically then, inside this traditional model, the low graded employees are those most directly oppressed because they are those most controlled and directed, and are considered to hold least stake in the organisation.

(This critique of mine is not Marxist; it is in fact how business operators perceive the socio-economic reality, and their perception is justified by them, by their approving it as being a ‘natural order’ of things.  Such an conception has a utility to them not unlike the concept of Divine Right for kings in days before industrialisation)

Their argument is classically expressed as being in accord with ‘human nature’, and its leverage is normally brought in to play so as to justify hierarchical organisation based on privilege and dominion.

The simple psychology behind this ‘human nature’ argument proposes that men and women who carry no responsibilities will be those most likely to act irresponsibly. This inductive generalisation is based on premises that include preconceptions that:

  • Lowly graded employees need closer managing so as to function well
  • They will naturally evade their tasks otherwise
  • The general mass of them are not suited to taking on bigger roles
  • They have poor self-regulatory powers
  • They will do no more than they are made to do
  • They have little initiative and few and basic employable skills

These then are the employees seen as having least stake in a business, and they are considered to be those employees who are most liable to act irresponsibly.

The concept of ‘having or not having a stake’ in a venture is essential to the upholders of the ‘human nature’ argument. Having a stake, so the pitch runs, confers responsibility and energises ambition to improve oneself; which all engender that self-regulation and other ‘virtues’ prized by employers.

Having a stake then allows employees greater freedom; but only to opt for ambition, responsibility and self regulation, in favour of the employer.

Conversely, those employees of the least consequence in any business are thus those who will receive most control and direction.

(Normally-speaking and collaterally, lowly graded employees also obtain least wages. This is because their lowly status, without stake, is normally perceived to warrant lower levels of trust and to incur higher levels of risk for employers.  The class of lowly workers is also normally present in an organisation in far greater numbers than the number of higher-status employees who direct them

More later on how this factor of ‘greater numbers’ tends towards being another wage depressing factor)

On the other hand, an employer who is allowing privileged high-grade employees a modicum of stake in his company, intends them to accept his ‘gift’ as a stimulus that encourages them to act responsibly towards him and his company; and so nurture the interests of the business. The actual degree of anticipated loyalty/responsibility accepted and acted upon by an employee will be commensurate proportionately to the rank, status and reward that employer ‘gifts’ to employees.

These arguments so far are nothing more than standard thinking.

A sense of responsibility then, it is expected, can be awakened and reinforced in the minds of some select employees by reason of the bundle of rewards they obtain from the employer in exchange. Thus a deal is cut between higher-grade employees and the employer.

Employees of higher status normally obtain higher wages, but not only as a result of their acceptance of ‘the risks’ involved in, and ‘the burden’ of, their positions and responsibilities; indeed and  moreover, their very rewards (so it is understood) act to ‘tie them into’ their employment and business organisation. The arrangement has similarities with the methods used by early Victorian Industrialists who provided their workers with ‘Tommy Shops[i]’ and ‘tied-cottages[ii]’.

Thus arises a belief that an employee’s loyalty is conditional upon his persuasion to self-interest, and that this can be generated in him by the enlightened self-interest of his employer providing to him adequate inducements.  Although bearing upon the privileged employee also are those pressures arising out of forebodings and concerns at the thought of his losing such gifted indulgences.

And so even the favoured higher-grade employee remains straitened; controlled by his employer’s will and power. It is his sense of the risks involved in being dismissed which delineates for him the opportunity cost of him stepping out of line.

[i] A Tommy Shop was owned by the employer. The employer paid his employees wages in tokens which were accepted only at his Tommy Shops in exchange for foods and domestic goods.  An employee was thus tied-into buying at the Tommy Shop, which were not unknown to charge higher prices than free-marketplace shops.

[ii] A tied-cottage was a house owned by the employer; who was able to hire and fire at will. When an employee was fired he and his family lost also their tied-cottage and were thus destitute on the streets.

 

You  can also find this article at our steemit blog: https://steemit.com/business/@matthew.raymer/doing-business#comments

The Importance of Vision

Vision is a conceptual grasp of the whole. More, it has a visual element; or rather, an ‘in the mind’s eye’ visual element.

Aristotle, in his treatise De Anima, puts forward an idea which says that all human thought carries at least some vestigial image – he calls this phenomenon, the imago anime,  ‘the picture conjured in the soul’; and further , he claims that strong images thus visualised show as if the objects of thought were present to the senses.

Now this claim, that ‘strong images thus visualised show as if the object of thought was present to the senses’, is not necessarily hyperbole or exaggeration.  Many recorded instances, especially amongst artists (musicians, poets, painters,) of them, as it were, being able to ‘hallucinate at will’ are reliably documented.

Ben Jonson, a dramatist and a contemporary of Shakespeare’s, writes of how he fell asleep at nights watching and enjoying at his feet noblemen with swords duelling together in animated combat, because his imagination worked on his senses so powerfully.

So it is not uncommon for people to ‘see’ in a way that in some sense is analogous to literal and actual vision; see items of their thought when set before their imaginations.

Furthermore, from my experience working with persons whose employment has required them to put into practice certain complex and detailed procedures accurately and methodically, it has been my observation that there is always a select few amongst them who are able to read and digest amendments and revisions of procedure so as to understand them and act upon them, purely from the written documents.

The remaining majority of employees got by because of these select few, whose duty of care it fell out to be to ‘translate’ these written word instructions into verbal communications able to be digested aurally and applied in their work by the others.

Taking these two qualities together: the strong pictorial imagination and the high competence in comprehension and application of complex written instruction; one might observe from experience that there is always in most walks of life, just a minority of participants whose capabilities allow them to perform at such high levels.

The profession of web designer of course benefits exponentially from having attached to it persons of strong visual imagination – this much is more or less self evident.

That developers perhaps might benefit from owning these characteristic, is perhaps a little less obvious to us?

But indeed, the best developers are most likely to be those whose minds and experience have melded over time so as to enable them to grasp as a whole the conceptual range of a complex and intricate task. And to be able to grasp such a range from the written word only also.  They will also be likely to be able to visualise in some depth of foreknowledge and in the abstract and in the round, written specified requirements expected of them.

Matthew Arnold, a Victorian cultural critic and poet famously wrote:

But be his
My special thanks, whose even-balanced soul,
From first youth tested up to extreme old age,
Business could not make dull, nor passion wild;
Who saw life steadily, and saw it whole

these words about the Athenian tragic dramatist Sophocles.

The seeing of discrete tasks and their corollaries and implications ‘steadily and as a whole’ is also what is best required in a developer one would choose. For a developer to have come so far in the course of her life experience so as to be so proficient will have been the fruit of her having employed and practiced her gift for imaginative vision and visualisation; and having joined it to the nurture and improvement of her reading and writing skills (her vocabulary, sentence structure, syntax, grammar, clarity and precision) in both natural language and in her software scripting.

These qualities when embodied together in her will make her a formidable developer; one who is a rare find and a treasure to be cultivated.

The signs that any developer one has in mind for doing a task has such gifts and accomplishments ought to be looked for right from the time one begins preliminary negotiations and discussion with her (or him).

The $64K question remains: what are these telltale signs?

Well, we have some written up here already – like command of natural language. A person whose head is clear and whose mind considers sequentially, a step at a time (and this is not incompatible with imaginative vision – indeed it enables, enhances it) will express herself eloquently in natural language as well as in script.  She will have a care to syntax and vocabulary, punctuation and grammar, so as to be understood rather than to be strictly observant of artificially imposed rules.

There is also temperament. Matthew Arnold compliments Sophocles on being an ‘even-balanced soul’ (see above). The dramatist Ben Jonson (also mentioned above) held a maxim about people generally. He said:

‘Words make a man: speak let me see thee.’

And it is true that a person’s disposition, whether wild or staid, or rash or impulsive, considered and measured; is all illuminated and can be seen because it is revealed, given away, in the way they use speech and handle language.  And so one should study the way in which a developer you are considering speaks, writes, negotiates; is she polite; is she considerate, does she appear to have some ‘depth’; does she interrupt you a lot; is she overbearing; is she confident yet not pushy; is she sensitive to others; does she broach tricky matters with tact?

Has she discretion, integrity, common sense, aptitude, does she talk well about her subject disciplines; does she try to baffle you with science; does she dismiss you because you know little about technical things; is she patient?

This long list of character traits may seem to have little bearing on her developer skills and experience; but you would be much mistaken to believe so. Good qualities in a person carry over into their works and into what they make and produce. Likewise bad qualities act in the exact same way.  Attention to detail for instance: can anyone doubt that attention to detail is an important thing for any developer you’d want to hire?  A general negligent, idle air – would anyone hire a developer who seemed to be wholly uninterested in the project of yours in hand?

Just think about how many mistakes and errors are made in development work by developers whose hearts and minds and selves are not in their works?   The Romans had a saying:

Laborare est orare’ (‘Work is prayer’)

The mediaeval masons working on the great Gothic cathedrals carving beautiful intricate stone-works and statuary wholly in the service of God; with stupendous skill – their names are unknown to us and they were not considered in their time to be celebrities – crafted exquisite traceries and ornament even in the roof arches of their buildings; in those places which never saw the light of day and are hidden absolutely from human view.

The first human eyes since the masons’ own to look upon their hidden works have been the modern day church roof restorers; yet the masons made as much effort, took every bit as much care, in these as they had taken in crafting the parts sculpted for human eyes and approbation.  Thus: ‘work is prayer’

The good developer works likewise. Those parts of her task which will never be inspected by her client; the backend, the coding, the scripts, will be tasks carried out in due honour to his profession and in the service, at the very least, to excellence; and as such they will possess a holiness of sorts about them also, for as long as they remain extant.

You can also find this article at our steemit blog: https://steemit.com/developers/@matthew.raymer/the-importance-of-vision

The Project Takeover Blues 6 – Buying and Selling

‘I gave her my heart but she wanted my soul’ – Bob Dylan

In the field of Classical Economics whenever mechanisms which bear naturally upon an open market are being discussed there is more or less always a presumption foregoing that ‘scarcity’ is a vitally essential concept.

The laws of Supply and Demand are largely governed by scarcity and by scarcity value in this field.  There are two expressions – i. A Buyer’s Market, and; ii. A Seller’s Market; which arise out of discussions about scarcity in such a marketplace.

All goods and services, and all the different kinds of goods and services, which a Political Economy is able to supply to its marketplace, will carry levels of scarcity.

For instance it is more or less self-evident to us that Gold Bullion is far more scarce than Bread or Rice in most parts of the world.  It is self-evident also that because of this relative scarcity Gold is of a greater value than Bread or Rice generally speaking.

Economists say: Gold has greater scarcity value than that of Bread or Rice.

This reasoning leads us on to looking at supply and demand. It makes sense that a scarce commodity like Gold is in short supply when its supply levels are compared to those of Bread or Rice.  And because of this there are generally more buyers looking to buy it than there are there is Gold available for sale. Otherwise the high scarcity value of Gold could not be sustained and its price consequently would fall. This Gold market place then is a Seller’s Market simply because it is the Sellers who are able to call the shots on Gold transactions being made.

(Please bear in mind that this is theory economics I am talking about, and that  in practice there and many, many variables and factors which are able to intervene and make their effect on this ‘pure’ marketplace and so on the scarcity value of Gold or of Bread or Rice)

In those parts of the world where Bread and Rice are plentiful, when compared to Gold, then their scarcity value is much lower than that of Gold and so the prices at which they are offered for sale are also much lower than Gold is being offered for.  Thus a Buyer’s Market is created wherein a surplus Bread and Rice supply means lower prices and the Buyers are thus calling the shots on transaction details. Sellers will settle more readily for what they can make

Now when one applies this reasoning to a typical relationship between a Developer and a Client; perhaps nine times out of every ten Projects, maybe more, the Client assumes (for some reason?) that the marketplace he is in is a Buyer’s Market.  And so likewise he assumes that he is able to call the shots; to set the price; to lay out the technical requirement; to nominate the tools; to direct the operations; to manage the Developer and his team or company.  In short, the most oppressive of Clients believe that they have bought the complete attention and the complete resource, and the complete management at the Developer’s place of business – at the least for the duration of the building and handover of the project to him.

It’s about control. It’s about risk. It’s about fear. It’s about a Client psychologically having to manage these bogies in his mind; and these lead him on in his bid for hegemony over his Developer until he is satisfied that his project is AOK and in place working and making him money.  The pressures are large for him, and often he is not technical enough to be able to be sure of the Developer and place a technologically reasoned confidence in him. If he were; if he could; he would not have needed to engage a Developer but probably could/would have done the development work himself.

These two things: risk, and fear, urge on his desire for control; all three things together are exacerbated by him, as it were, going into the venture ‘blind’; that is; him being without technical knowledge.  It’s a little like being under the knife of a surgeon and unconscious; you have to weigh up the quality of the surgeon beforehand and you will know nothing about surgery.  You are left with hope, trust and a prayer as you lose consciousness counting backwards.

You might look up on the net beforehand your ailment and run through a lot of time and pages reading about similar conditions and the surgery that is recommended for them. Like a hypochondriac you might delve quite deeply trying to match your apprehensions with an adequate garner of reassurance to be had, one hopes, from one’s reading. Like hypochondriacs, when the operation is serious, maybe life and death, you are likely to get drawn in and begin to grow neuroses and anxieties which do not help you at all to manage and are counterproductive.  You don’t want a surgeon who is anxious and neurotic do you?  Your reading has the opposite effects you want it to have on you.

‘A little learning is a dangerous thing;

Drink deep, or taste not the Pierian spring.

Likewise your Client, by him assuming control over his Developer, he is likely to do more harm than good to himself.  Like when having a risky operation, one having zero knowledge of surgery is a far better resource for peace of mind than going delving and frantically gleaning off the web a host of half-digested partial-truths about it at the last minute.  The Client who is like this is usually the one who ‘cannot let go’; of his worries, of his apprehensions; and his fears; his urge in response is to call the shots and lay down the law; and generally to harass his Developer and ultimately make his and his own life truly miserable.

This type of Client is strictly-speaking assuming control. He is like a chimpanzee let loose in the Space Shuttle coming in to land.  He has no real idea what is required technically; whether it is feasible; or possible, or impossible or impracticable or easily added or doable or not.  His efforts show in a fit visual image:

‘Like a madman shakes a dead geranium’

Clients like these are those most liable to run through Developers one by one like diarrhea.  They appear never to learn the basic lessons of their business and of their business transactions.  We have all gone up to our wives and husbands who have been struggling so irritatingly to us with a screwdriver and a faulty appliance and at last we have let rip with; ‘Give it here! Let me do that!’  And soon thereafter with a humble, perhaps grovelling apology admitting defeat similarly to one’s spouse.

In this then we can all feel sympathy for the nervous edgy guy who just cannot help but want to control his baby, his project, who cannot help himself, who cannot control even his own desperate urges to dominate; there is so much at stake for him – he envisages.

But is it not all ego? Is it not all the blind inherent assurance in the self that everything will be alright if only I can take over and control and manage the tasks and the issues at stake.  Not many, not even among the worst of egoists, will be likely to feel or believe that they can do better than that surgeon they are entrusting, are having to entrust, their body and innards to for a few hours. And that will be that.  No argument. Besides, they will be unconscious and could not do it if they even thought they might be able to!

But the Developer is fair game – thus the presumption of there being a Buyer’s Market is ever the case with many Clients, anxious about their development project, its negotiation and delivery. Such a Client will nearly always do his best to ‘lean on’ and so ‘steer’ his Developers as much as he is able to usurp.

To finish up; consider this: What do you look for when choosing a good surgeon? Short answer: Character. Longer answer: clean tidy shoes and apparel, suitable to a man or woman of eminence and distinction in his/her profession.  He or she exudes a confidence which is not idle, proprietary or overweening; and seems to be fluent on her/his specialist knowledge; observant, patient, engaged personally and considerate; a good bedside manner; polite and with a lively mind: someone who has the look and feel of a person to whom you could just about trust your health.

Bottom line: isn’t it pretty much the same when choosing a Developer? A less desperately critical issue than choosing a surgeon maybe, but even so, doesn’t this very lesser level of concern in fact mean that one should be more at ease and not jack oneself to be over pressured – after all, few Developers have messed up so badly that they have put their Client in a wheelchair or dug them an early grave.

The Project Takeover Blues 4 – Concatenations

When there’s train crash, at speed the railcars which follow the engine bogey crash and crush up into one another as like a concertina.  Sometimes, especially when one has been in one of these accidents, time seems to slow down to a crawl for you; and this is a subjective state which however seems for all the world to be very real when it is taking place. And so you get the impression that you are watching a movie in slowmo, that somehow you are outside of yourself like a person watching in a cinema, and things are crystal clear and going on somewhat surreally all around you.

So the railcars crash and crush up into one another as it were very clearly and slowly, and the sound might not be even noted by you, even though the noise is going to be terrific.

The crashing and crushing up into one another of the railcars is a concatenation; a series of interconnected events, a sequence which, once set in motion, is more or less thereafter inevitable in its continuance and in the case of a train crash, linear in its consequences.

Now imagine a more complex situation; an exponential concatenation; and add several concurrent strands to it, say fifteen or twenty; and further let each strand be capable of interacting and interfering with the outcomes of the other sequences of concatenation, so that the overall consequence of the event is as near as one can imagine envisaging what an atomic fission chain reaction might be like to experience when occurring at a level of magnitude fitted to daily human life.

What needs to be done now is to psychologise this imagined physical event. Because such events do occur like this between humans in relationships; they are of the kind whereby say a couple fall in love and wed, and yet five years down the line they are fighting tooth and nail in public, in an acrimonious courtroom war of attrition with an aim to do as much hurt to the other as either can dream up.

The wedding day is the rail network running fine and everything is on time. Five years later the divorce is the catastrophe that happens when all the signalmen on the network have oddly gone loco (!) and switched points and lights so that our chain reaction of series of concatenations becomes a terrible bizarre reality.

Of course trains can’t all pile up in this way in fact; it’s just not in the nature of track layouts, so you have to excuse the illustration as being unfitted in this respect. Nonetheless relationships do deteriorate and once they reach a momentum to break free of convention and restraint, and these fissile explosions boil up and over, they behave as if they could be governed by the laws of physics

You might be able now to get a bead on what we mean when we say that some Project Takeovers are dangerous because analogous to you being handed a ticking bomb to fix back into being a fluffy toy.  The chances of you being able to do this are really not good.  Because when gaps open between developers and their clients which allow tensions to brew and fester, and respect to wither and fail; and expectation to switch to a negative value; and communications to begin to hide from parties as much as they reveal to them; when this and other strands of dysfunction kick in and begin messing with a developer/client relationship, then the Project is on course to be a train wreck.

One cannot hear a symphony during an earthquake. One cannot grow crops during an eruption. In the same way one cannot  complete a Project well when relations between you and your client are seriously falling apart. Inevitably the friction, frustrations and simmering resentments will poison not just the well from which you and he drink in common, but will mar the understanding of what technically is required  in the project and how by design this requirement might be implemented.  You may have heard the joke that a rhinoceros (sometimes it is a giraffe) is an animal designed by a committee; well take this joke a step further and one might say that nothing of any pleasing or functional shape and purpose was successfully made by mutual enemies.

The story is well picked out by William Blake:

I was angry with my friend;

I told my wrath, my wrath did end.

I was angry with my foe:

I told it not, my wrath did grow.

Some things cannot be said between business associates. They are likely to be discussed by the several friends of each of the parties about the other party, and there is no satisfaction in that to either party.  Thus wrath grows insidiously.  It is these situations which lead, in a good many cases to, so as to become parcelled up as, explosive charges, resulting in Projects that are to be handed over to subsequent developers as Project Takeovers.

Now certain heavy elements are by the course of their nature highly unstable at NTP.  In the natural  order they will deplete into stable but more or less inert substances.  And on the way to stability they emit, sometimes for aeons and aeons, emmanences fatal to life of nearly every known kind.  In the same way there are persons who like these heavy elements are volatile and unreliable, dangerous; and, unfortunately too often, they also destroy themselves because of their adverse natures. They too often also end up ostracised from normal and amiable society, living lives on the streets or in closed wards.  Whether or not they might be held responsible for any consequences of their nature is not in question here.  The observation to be made from this figure is that many, maybe most of these unfortunates are so fragmented as personalities because they are so deeply and intractably conflicted within themselves.

‘If a house is divided against itself, that house cannot stand’

This then is another figure for that relationship which ought to be one of communing and mutually assisting parties with prima facie goodwill and generous good faith; but which in the course of events over time deteriorates so that neither party knows where they are and trust has utterly failed.

With Project Takeovers very often this is the damage that has been done already – to the client and to his Project – to his former developer and to this developer’s own trust and good faith – and one is taking it on, if one decides to take it on, as a balled tangle of threads constituted of knots of thwarted emotions and frustrated wills, which, as you being the new developer, very likely will be yours to try to unravel in addition to having to complete the Project. This is often the case even concerning the actual development work previously done by any former developer; one too often will have to reverse engineer and re-engineer virtually from scratch any development work already accomplished.

‘He has walled up my way, so that I cannot pass, and he has set darkness upon my paths.’

[This article was originally published at “The Project Takeover Blues 4 – Concatenations“]

Project Takeover Blues Part 3: Psychological Attrition

Much of this article is applicable in a wider, more general sense than just to the mind-messing which can go on when a part-completed Project is taken over by a new developer. Although in these instances they manifest most acutely and are the frequent, maybe invariable, accompaniment to these occasions.

They manifest most acutely for the most part because of the back-story, the history of the development so far carried out by the former (now sacked) developer, and the aftermaths of his/her now failed relationship with a dissatisfied client commissioner of the works.

Many times, especially when the client is not technically-minded and holds in his head an idea of the finished product he wants, but with no understanding of the means and works required to obtain it; this kind of client is a type who most likely to come to grief with his developers.  It is the difference between knowing how to use the controls of a TV or PC, but yet having zero knowledge of how they work or how they are manufactured, which generally opens up a gap in these relationships which is very hard to bridge or practicably proves unmanageable to work with.

(A further exacerbation frequently arises which can be exampled by reference to a commonplace experience of parents in this new and technological age. Their children frequently have grown up accustomed to and acclimatised to an unrestricted availability of plenty in a consumption-driven economy, wherein many consumables are of easy access, but of whose scientific history, development, composition and operation these children know and care nothing. It is felt back story is not to be needed – and because of a spoon-fed dispensation provided by specialized technocrats who stand a universe away in apprehension from the worlds of these children – these children place very little if any value on or feel gratefulness for being able to possess immensely complex and refined technological (and other) products which have issued so freely and abundantly in availability to them.  They have come too easily.)

And so likewise, too often the lay guy who is commissioning works from a developer shows he has a belief that he holds an inalienable right to ask for the moon if he desires it, and feels that to have it is his unconsidered entitlement and the developer’s summary duty is to provide it.

The customer then believes he is always right, even though he has no qualifications, has shown no aptitude or ability in, or even felt moved to be curious about, how the works he expects provided ‘on a plate’ are in fact done and achieved.

As adjunct to this state of complacent ignorance too often an assumption of unquestioned, unquestionable seniority over a developer accompanies this outlook.  Again because of a lack of a sense of any value and weight to the expertise a developer uses and which goes into the sophisticated products he is able to create; and because the client customer considers himself to call all the shots because his pocket is going to finance the works he wants done; these considerations he feels, in a confidence of blind ignorance, place him in an unassailable position of master directing his servant.

The developer must be solicitous and show obsequiousness to his, the client’s, assumed standing, desires, requirements, and sometimes whimsy.  The client like some minor feudal official feels able to lord it over those whom he feels have no status and so no power to oppose or object to him.  So the story goes.

This scenario might seem unjustly coloured – and it has been presented in high-definition so that the essence of the stereotypical bad client is distilled for to be seen in a concentrated form.  And further, developers are not alone in being slighted and dismissed in their worths by the consumerist tinpot would-be dictators being produced by our blasé over consuming, over-producing instant and easy access to everything head in the sand societies. But they are in the front line of vulnerability.

It is developers who are too often subject to uninformed anger and disdain, to non payment for services supplied, to abuse and incomprehension when the moon the client is informed is not available this side of Paradise.  They suffer from such clients attempts to tell them what to do and how to do it; that claim that the impossible is available and just get it from off the shelf.  They are hard pressed to contain the burgeoning of late additions and alterations flooding in and claimed as being in the original requirement by a client, having to tread a fine line between politeness and refusal, and explanation without apology.

As for the client who has sacked or else lost his initial developer – the upshot is the same – there has been reached an impasse – either the initial relationship has failed or else the developer has been unable to deliver – and the client having to seek out another developer in order to complete entails inherently in its history a decisive breach in relations having occurred previously. Thus the prognosis for a happy ending for the newly-hired subsequent developer is not the best.

Indeed there is nothing so difficult to defend oneself against, let alone to try to break down, as entrenched ignorance coupled with an assured self-confident complacency. These are qualities of character being nurtured and encouraged far too much, far too widely. Their owners can sustain their character because such people are able to survive and by doing so send harmful concatenations of reverberations around in their societies.

They are able to survive and to continue because of the great and ponderous gulf in our societies set between consumers and their consumption, and manufacture and development, whereupon the consumer thinks he is king because he holds the purse strings’; but in fact the technocrat holds the aces because he has the knowledge and therefore the power to withhold or supply the gadgets and gewgaws our lives have become crucially dependent upon.

The consumer has been or has allowed himself to have been removed, separated, from the wellsprings of his existential essences.  (For instance, many city children in developed societies have not experienced seeing the commonplace farm animals in the flesh.  Food is commonly shrink wrapped and packaged up, offered without blemishes, irradiated in inert atmospheres, pre-peeled, maybe with added chemical adulteration, all being presented as pristine, untouched by  human hand, almost as if ‘official, rubberstamped-good’ food, and as far away from a slurry tank or a muckspreader as human imagination is able to conjure)

The result is loss: the loss of an awareness of authenticity, and so of good judgement.

The consequence is belief that the technocrat is able to/will be able to supply the moon and anything more that the consumer stipulates; and that he is obliged to, will be coerced to do so by consumer demand.  The disbelief, anger and fear aroused when this closed bubble of fantasy occasionally bursts, and reliant antibiotics fail to cure, or when systems go down and crash, are usually directed at the technocrats and are accompanied by a widespread and genuine sense of staggering helplessness in which consumers understand themselves to be ‘victims’.

Like the typical client with his project on its second or third developer, they are indeed victims, but for the most part in consequence of their own renunciation of commitment, engagement, curiosity, generosity, and humility, in the face of an easy and comfortable, listless superabundance requiring seemingly no accountability.

Project Takeover Blues 2: Addressing the Balance: Keeping an Equal Footing

[This article continues our series on taking over a project from another team or, looking at it from the client’s perspective, switching teams.  This is part 2.  You can read part 1 here.]

This article looks at the essential bias of most client/developer relationships.

This is a world that celebrates wealth and power that rich men and women wield; one in which every Joe and Joanne aspires to this status as an apotheosis of a successful life. For all the talk about God and religion in America the core tenets of Christianity are not in play there where doing business is concerned.  No-one but no-one in America gives his coat along with his shirt when a guy asks a shirt from him.  As for laying up treasure in heaven – guys are too busy laying cash up in bank vaults and in their hearts down here.

In Europe, the bulk of the rest of the developed world, Jesus is a fiction; something dreamed up by inadequates, and cynicism is the best policy for handling people; no open-heart policy there.

A guy I worked with, an OK guy, Steve was his name, a Welshman, who of course played rugby football, as everyone does there.  He told me a story about his team coach. The coach had warned him about lineouts. (In the lineout two opposing teams file in a long line each beside one another as the ball is thrown over above them. The teams jump up together to obtain possession.)  Lineouts are set pieces of the game which are notoriously tough; the bruiser types usually play the man by throwing a punch to the kidneys at their opposite number when the referee is on their blindsides.  The coach had advised Steve for when this happens: ‘Next time you go up; dig him twice as hard back’.

The rationale of this was that the bruiser guy would never leave Steve alone unless Steve at the first opportunity hit him back twice as hard.  At first Steve tried to do without retaliating. After a few fixtures however he had adopted the instant retaliation as policy – as dogma.

Well, in a less physically violent but as jolting a way, verbally and in the business transaction, such a policy or dogma soon evolves among developers towards their clients.  Elsewise the slippery slope towards nervous collapse begins, because many, even most, clients will take up and make use of the bruiser option as their default setting. So they must be curbed at the earliest opportunity by a fierce but measured retaliation from the developer.

Such a retaliation puts an estrangement in place between the two; and such an estrangement is the birthing space within which respect – first towards the developer – thereafter and mutually between each other – is able to enter the world alive and nurture the relationship to thrive.

Of course, just as some guys can give punishment but refuse to take any; you can lose clients this way. Some will walk, offended, even outraged; and go look for some pliable sucker elsewhere to drive into the ground from doing their penurious bidding.   But most clients generally shape up and innately understand the natural justice in the situation. This puts the relationship on a proper footing.

Once a common respect has been established, then the relationship can grow and develop and thereafter even niceties like offering one’s coat along with one’s shirt might be contemplated as possible.

The scenario is unChristian maybe; but so is most of the world, and even more of the business world.  Jesus died for us; but he himself says he came to give life and life in abundance. We are not called to die for him; although perhaps there are instances of men and women who have been called by him to give their lives in his service? But where it avails nothing to be crushed and bled and thrashed by a client who is a natural bruiser, no-one, Christian or not, is making any hay for the Kingdom by lying down and allowing himself to be trampled to death.

An important strategy for use with clients who shape up and share esteem but go quickly into into relapse – the backsliders – is to play the zero-sum game and set them to rights.  The rules are straightforward and you must ALWAYS abide by them and NEVER relent nor ever get spiteful.

When a guy cooperates give him a reward; like when he allows a just but unwelcome correction, give him a compliment and praise him for allowing it.

When a guy is deliberately hostile or reluctant give him a punishment – that is – go back to the original line-out scenario.

These two simple rules when always applied may not be an absolute guarantee for rescue of a situation and relationship; but they are your very best strategy for getting reinstatement of good order and due respect.

In our societies a tendency, which many people understand to be natural, but which if allowed to be natural gives humanity no hope for a better world, is for those with a power to hire and fire, to pay or not pay, to demand but not be demanded of, to take up the higher ground from which to lay it on the guy who is to be hired or fired, paid or not paid, demanded of but not demanding.  This kind of relationship is widely accepted as the general norm between employer and employee, boss and bossed, master and servant.  Jesus says there is another way.

And Jesus is no numbskull; nor is he a soft touch nor wimpish loser type.  ‘He did not rely on the approbation of men because he knew men and knew what was in men.’  And ‘he was no respecter of persons’ i.e of position status sway. In his unique way he was tough. He gave it out where it was right to give it out; and he took it where it was appropriate to his appointed task to take it.

We are called to follow him; not just in an abstract spiritual affiliation but in his toughness; to dish it out where it does well to do so; and to take it on the chest when things get tough.  Sometimes not easy, but always productive.

So a guy like you who is being knocked from pillar to post by his heavy clients and their imperious demands; he can sort the show out and be working to do good in the world as part and parcel of sorting things out.

You are doing no favours to the guy who wants to push you around by allowing him to do so. The first steps to a better place to live in and to do business in are in helping level out the ground and so prepare it for a lasting and beautiful ‘house of many mansions’ to be erected where humanity fitly might dwell.

The Project Takeover Blues: 1 – The Client jumps ship – or was he pushed?

What I’d like to spell out in this series are the ins and outs of taking over a project from another technical team.  Spelling out the issues that tend to arise in this area needs to be viewed not only from a perspective of one development team taking over another’s work, but also from the perspective of commissioner-funders the project. How they might see their replacing an existing team.

There is a whole host of angles and fractal views from which to take up this topic. This then is the first of another series of articles – this series looks at Project Takeovers – and this opening article is a broad-brush attempt to sketch what are to be their chief themes.

Discussing projects part-finished that are handed over to you for completion puts me in mind of George Orwell talking about Hitler’s stormtroopers goose-stepping through Berlin and Nuremberg: “It would be laughable if it wasn’t so terrifying”.

Looking from the outside inwards there are plenty of belly-laughs to be had from this topic; and taking-over Projects might even make a good TV sitcom format; but sometimes even Hell looks inviting from a distance?

Reason number one is the lack of history you get along with the part-complete work.  At best it’s a one-sided story, the commissioning client’s Authorised Version (no Apocrypha).  Given that there has normally to have been a rupture followed by a total breakdown between client and former developer, this one sided story will always be pretty colourful, but in heavy shades of dark and light.

Another George Orwell item comes to mind, the Party Line dogma of ‘Four legs good; two legs bad’. In short- the other developer guy is always the villain of the piece.  Sometimes even the client forgets that you yourself are a developer and he begins drawing generalities from his bad experience and starts unheedingly to tar your trade and all its practitioners with the same brush.  Depending on how desperate you are for work, you might turn a deaf ear or else plead a fully-filled work schedule.

Of course, we are all human and so are all errant sinners, and so he might have a solid case against the former developer (developers are human too, in case you are not sure!). Nonetheless, to receive a doctored version of events is usual whether or not whose fault caused the break-up, and this is at best difficult for the new developer. Very few people can bear too much self-examination. (‘Humankind cannot bear very much reality’ T S Eliot)

The former developer will likely be ill-disposed towards the client, and so a very crucial source and route for obtaining valuable information to help you complete the task is sometimes cut off; although allowing for camaraderie amongst developers there might sometimes be some slack cut for you by him? Especially if he has a story to tell with grievances he might be just too pleased to get off his chest to ‘someone who understands’. So first points to note:

Approach the Former Developer to get:

  1. His side of the dispute; and
  2. Any technical background and advice he is happy to offer you.
  3. To get a bead on the client himself
  4. To assess in as far as you have opportunity the objective situation of the breach
  5. To find out whether the client is a decent payer (on time and without quibble?)

This final point e) is probably the most important item for you to find out.  A person can put up with a lot of frustrations if the pay packet arrives in full and on time.

Regardless of the answers had from a former developer be prepared for a lot of deconstructional work on what has been achieved so far in the Project.  Whether the client or developer has been the one who is inept or inexpert the net result is often the same: the software you inherit will almost certainly need unravelling, beginning again if not at square one then at a point far back before things began to fall apart administratively.

This is because at whatever entry point in a Project, and from whatever angle, comes into it a feed of chaos, in the shape of too many changed minds, overmangaging of minutiae, unscientific expectations, the quart in the pint pot (“feature creep” is the trade term), and so on: like a good leaven it will propagate through the whole batch and raise the loaves of consternation within it.

In all this there is another general rule arises, that:

The software build and the technical side of things will go far more smoothly and be a lot easier than the handling of the human aspects of Projects and of their interested parties.  A psychiatrist friend of mine once quipped to me that ‘a neurosis shared is a neurosis squared’ – one might say much the same for the human relations management involved in taken-over projects. Unless one has a foreknowledge of experience in these things you might not be fully prepared for the upgraded bagatelle game involved.

There is likely to be enjoyed a ‘honeymoon period’ between you and the client but his bad experience that led to you getting the half-formed app or build to finish has made him more wary and skeptical about developers and their ways, and he will be more on guard than he had been previously and sometimes will be looking for ‘unconformities’.  It is hard to say whether a non technical client is better or worse than a technical one.

Alexander Pope once said: ‘A little knowledge is a dangerous thing’ and perhaps half-knowledge is the very worst state for a client to be in.  The client ignorant of technical things is the kind most likely not to accept being told by a techie he is asking for too much or the wrong sort of thing and so on. This is because he cannot appreciate the limitations of IT science.  For a client who knows a lot about techie things one always asks ‘Why isn’t he building it himself?’.  Sometimes this is naively asked at face-value; sometimes it is asked rhetorically with some sarcasm when he is the kind who is looking over your shoulder every moment of the day.

But the client with half-knowledge can be truly awful. He can insist it ‘can be done’ and that he ‘can tell you how’; that he knows the budget is sufficient. He of all kinds of clients is the one most liable to seek for mission-creep and to pile up add-ons and extras, and to suggest inarticulate tinkerings.  You lose either way – do as he demands and the app is crap – do as you believe in and he refuses to sign off.

Considering these conflicts arising between Clients and Developers it is not surprising that so many projects are handed on to the next firm half complete; and it is surprising that so many projects see it through to completion.

To say a word in favour of clients, so that there is some balance to this article, it is true that developers often can be not the most forgiving of people, and can be abrasive, and from the perspective of clients, ‘difficult’ because they too have had a history and experience of tangled relations just as clients have had.  They too feel they are ‘once-bitten’ and so they are now ‘twice shy’, and so they are very defensive right from the off.  If developers were good at human relations they would not be developers; they would be in conflict management where the money is.

The scientific mind is one that is least liable to ‘suffer fools gladly’; because perhaps the precision of methodology into which it has been trained heightens its sensitivity to loose thinking and approximated accuracy. These however are the norm for more or less ‘ordinary’ kinds of people.  Such a heightened sensitivity cannot bear these casual outlooks which it sees as being ‘slapdash’ and it finds them an enormous source of frustration and annoyance.  Yet what is more necessary for handling people well than a certain ‘easygoingness’ and a broad ‘willingness to tolerate human foibles’?

The two outlooks are thus ‘chalk and cheese’; so is it any wonder that after the marital arts, the second place for exercise of mutual self defence goes to techie-client relationships? Like an old married couple.