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.

Metanomalies publication The Future of Internet Piracy Storage

We’re proud to announce this new article in our Future of Piracy series on our Metanomalies community portal.  We explore new technologies (such as storj) which are capable of being leveraged for piracy as well as normal file storage.

[The point of this series is to emphasize that small creative owners (as well as large corporate ones) need to carefully consider the strength of communities to monetize their works rather than (or in addition) to traditional intellectual property.]

Introduction to Professional Web Design

When I originally set out to write this article, the question as I had it in my mind was “How long should it take to design a web site?”  After some reflection, I decided that while this question is a burning one for clients, it would be more comprehensive for me to ask what issues necessarily must be considered when doing design for the web?  What I’ll be doing in this article here is laying out some general areas for consideration, into which we shall delve further in detail in later articles. Continue reading Introduction to Professional Web Design