The Development Obstruction Layer

Once upon a time some talented developers join a small company. The company is doing well and can afford to take on more people to make more of the right software in order to make more money to keep everyone in business. It's a happy time for everyone. As the company prospers, so the upper management have two problems. The increased responsibility of a larger company is harder work, and they're no longer sure whether they're up to managing, yet they have to remain as management, lest they admit the need to rely on other people to help. So, they grow the company without paying attention to middle management, expecting the more senior members of staff to pitch in and help things along.

After a time, some of the upper management are considered to be nay-sayers and so they are removed, replaced by the sort of yes-men who do not say no, even when no is the correct answer, and so the company's grip on the real world is replaced by a layer of optimism that does not actually relate to the facts. Furthermore, as the different people who used to do specific jobs, alongside the other people who did different jobs, gain further help in the form of more staff, so departments and divisions (with a capital D) form. No longer is it permissible to ask someone to help you, you must go through the system which that particular group has formed in order to make their internal operation much easier for them.

As the company grows beyond breaking point, it suddenly breaks slightly, requiring some downward expansion, and blame management in order to maintain its position just far enough above the flames of the fire it's now thrust itself into. Both of these strategies create an effect known as rear coverage where the behaviour of each department and managerial unit is intended to protect the department more than increase the prosperity of the company. This is where the development obstruction layer first forms.

Developers will soon find themselves at the sharp end of the productivity quandary. This is where the company realises that its income depends on its sales, its sales depend on its product, its products depend on the developers and the developers depend on the strategy. The strategy should also be dependent on potential sales and the results of market research, but owing to the process of rear coverage, the strategy has been laid over until the income has improved, because it's difficult and because "we should already know what we need to make". Thus the developers discover that the entire company is riding on them.

Developers can solve all the problems they're faced with. However, for maximum efficiency, they should only be faced with the problems that only they could solve. Without the development obstruction layer, the developer would only be solving developer problems, and this might reveal the inadequacies in all other departments. With the obstruction layer, the developers become the centre of dependency (which means blame) and are unable to do anything about it. Occasionally, they may receive pseudo-empowering pep-talks suggesting that they can do whatever they need to do and that they are in the driving seat of the company. However, any pep that is engendered by these talks will soon be extinguished as they small into the wall of the obstruction layer.

As a result, the company can slowly implode and nobody will realise that the fault lies on the other side of the obstruction layer, as the only people who can see it are considered, by everyone else, to be solely to blame and thus totally untrustworthy.

Here are some ideas for how to set up and obstruction layer:

• Underinvest in hardware
• Do not provide stationery in good supply
• Lock away things like batteries which might be used for purposes other than replacing spent ones in wireless equipment
• Buy hardware on the cheap so it arrives late, or breaks down often
• Make it hard to buy books
• Requisition developers to work with other teams on things which are only vaguely related to the project
• Repeatedly change the direction of the requirements on the team
• Invest stakeholders with power over the future of the product but no knowledge of the realistic requirements
• Demand everything immediately and with equal priority
• Refuse to replace core systems like source control
• Refuse to invest in bug tracking
• Refuse to adopt a system for managing requirements, insisting instead on having all 400 historic requirements maintained and laid out manually
• Complicate the expenses procedure
• Put more middlemanagement between the customer-facing techie and the customer in order to slow down communication
• Agree to impossible contract work which can only make a loss, because it has not been budgetted with reference to any technical estimation and is of fixed scope, quality, time and resource
• Occasionally buy people lunch while you tell them off
• Turn your senior people into pseudo-managers, taking them away from coding, even if that's their strength, rather than invest in a real leader
• Reward people on the basis of apparent willingness, rather than productivity

If you have any motivated people left after this then it will be a good indication of the high caliber of techie that you're spending good money squandering.