6 Anti-patterns in the engineering department and how to fix them

Over the years I’ve spent a lot of years observing how software engineering departments work. Whenever the department gets trapped in last-minute deadlines good behaviours are dropped and the same anti-patterns appear. Do you recognise any of these?

Shipping “brittle” software that has plenty of problems because there wasn’t enough time to fix them. And what’s worse, there isn’t any time to fix them in the future, so the tech debt keeps accruing. After a short while even the smallest change is a breaking change and most of the sprint is spent fixing rather than building.

Scope of delivery is lower than expected. When there’s no more effort that can be applied to meet a date, the last remaining lever to throw is to reduce scope. This last lever is often thrown at the end of projects when there’s no option left but to accept. The result is the business is forced to accept a reduced scope delivery with consequential impact to the business value delivered. And yet the software is still late.

Heroic effort is needed to complete work to meet the deadline. The company might have a strong culture so that all members of the team are fully invested to make the work successful and are willing to work long hours and weekends. However the need to do this repeatedly rapidly saps morale.

The perception that there’s never enough resources. The most common refrain in retros is that there were not enough people to do the work. The business is tired of hearing this because there’s simply not enough money to hire yet more developers. Whichever way you look at it, there is a mismatch in the velocity to produce output and the expectation in the amount of output.

There are too many projects at the same time. When velocity is too low projects don’t get completed quickly enough, yet the work keeps rolling in. Attempting to do more work in parallel leads to conflicting and shifting priorities, work that starts but does not satisfactorily finish, overload and context switching that further reduces velocity.

Shadow tech teams emerge. Engineering is snowed, so let’s bring in a vendor, a consultancy or outsource to deliver a specific project. There are good reasons for bringing in third parties, but they will work around in-house tech team that isn’t delivering. It might solve velocity issues at an acceptable short-term cost, but the longer-term cost of increased organisational debt is often not considered until the business tries to unwind the third party relationship.

All of these issues arise when engineering isn’t delivering predictably. The opposite happens when delivery is predictable. A predictable engineering department will:

• accrue tech debt mindfully and find the time to refactor it out;

• be able to articulate when a scope will be delivered with sufficient accuracy that the business can plan effectively;

• be a capability that can cut code at the same rate indefinitely;

• not require last-minute heroic effort or boost in headcount because the business was able to plan from the outset;

• complete projects;

• make use of flex temporary resource for specific projects, and roll them off when the project completes.

A successful business is charting a course into the unknown and so is always managing risk. Delivery of technology should not add to the risk.