Dark IT Patterns: The Rainy Day Server Pool

Scenario
A team finds themselves constantly being delayed due to lengthy internal requisition processes and bureaucracy.

Problem
Projects are delayed due to internal bureaucracy. Important pieces of hardware and software are waiting on another part of the organisation to requisition them and set them up.

How it works
Instead of requesting the resources at the point they are needed, the team requests them at the start of their project, or at the end of their previous project. In effect, the team maintains a pool of resources, ready to be used by their next project.

A cost is shifted forward to well before it is actually needed, but the advantage is in the agility of project delivery. There could also be some costs to being on standby (e.g. monthly license fees or server electricity costs).

Real life

Due to team size scale up and release date pressure, this practice is common in game development studios. Its also common in government departments and larger organisations. It can apply for any sort of hardware or software - desktop machines, tablets, mobile phones, licenses for design software, server hardware or database instances.

The migration to the cloud has meant that servers are now a lot quicker to spin up virtually. So due to cloud IaaS, there is less need for this, especially for server hardware and database instances.

Corporate ethics
Its not really a problem in terms of ethics - its more like an indication that some processes in the organisation are too slow and should be improved.


Follow @dodgy_coder on X

Dark IT Patterns: The Fall Guy

Scenario
A valuable customer is hit by a major intractable bug or a serious system limitation with your software.

Problem
Your company needs 6-8 weeks to resolve it, but the customer is demanding immediate action or else they'll walk away.

The plan
Get your company an initial 2-4 weeks of time with rounds of meetings and follow up meetings. At the same time, hire a business analyst (or project manager) who may potentially be out of their depth technically, but who can present well at a meeting. 

The new hire is given responsibility for representing the company's position to the customer, and asking for additional development time. At a final crunch meeting, put the new hire in the firing line to answer to the customer's main concern, e.g. exactly what is the technical plan going forward and exactly when and how will the issue be resolved?

Why it works
If they succeed, then you've got the required time you need to work on the solution, along with a truly useful new hire. If they fail, they are fired the next day, and now the customer knows you are serious about doing something. Due to the seriousness of someone being sacked, and the time needed to hire a replacement, the customer is willing to give you another month to complete the work.

Root cause

The root of the problem is just the reluctance of the company to end their relationship with a difficult customer - who they can't properly support. It can also be traced back to some out of control technical debt, resulting in an intractable bug.

Corporate ethics
No company should ever do this - it reflects badly on a company that they are willing to fire an employee for the sake of keeping one customer. This kind of behaviour is called corporate scapegoating, it needs to be called out for what it is and rejected by management.


Follow @dodgy_coder on X