Q: What’s the fastest way to run a project into the ground?
A: Ask the team how long it’ll take, then give them a shorter amount of time to complete it.

Recursive Failure

Once upon a time, I worked on a project that had the stink of death about it. It was old code, had dozens of hacks scattered throughout, known bugs that were not easily fixable, and dependencies on a buggy internal DLL library for which the source code was missing.

Prime candidate for a rewrite.

Since this was all consultancy based work, everything had to be chargeable to a client. When a new tender was released that the powers that be thought that this software could be applied to, the development team would be asked to put together estimates for the effort required to customise the software for the client and, from this (presumably), a bid would go in.

So, we’d get together and work out what was required.

Generally, our estimates would include the time to refactor some of the code that badly needed it – the goal was to have this software be something that could be easily configured for dozens of (eventually hundreds of) clients with little effort. Due to the various hacks and nonsense in the code, it’d take a couple of months to pull together something that mostly worked. I have to say “mostly” because, of course, the test coverage was 0%. So, it made sense to include refactoring time since it’d improve the workflow going forward.

An estimate would go in, something like:

• 15 days refactoring
• 25 days client specific
• 5 days technical debt
• 5 days testing
• 10 days contingency

About 12 weeks work to do a good job.

So, the bid would go in, and we’d win the work. Then we’d be told the budget was lowered to win the work, and we only had 6 weeks to deliver.

Refactoring and technical debt would be the first to go since it was important to show the client stuff working. Contingency? Haha – no.

Discussion around tasks would also be a “waste of time” since any time not coding “isn’t productive”.

So everyone would jump into building stuff as fast as possible. The client would see updates, suggest changes (because the functionality wasn’t quite what they wanted) and project managers would then argue with them because there wasn’t enough time to redo stuff and the code that had been thrown together matched the vague requirements that had been signed off.

With two weeks of budget remaining, we’d likely have about a month of work still to do – the one consistent thing about working on broken code is that random small tasks will blow up occasionally and eat up days.

So, the last two weeks of the project, everyone will be working 14 hour days, including weekends (for no extra pay), just to get everything done.

And we’d meet the deadline.

The code would be low quality, the software would be buggy, the cumulative technical debt would loom ever higher, the client would be unhappy at some of the functionality, but we’d hit the deadline and ship.

And then another tender would come in. Rinse and repeat.

Out of that six person team, four quit within a year, and one requested to be taken off all work for that team. One poor soul is still there.

Nails

As a developer, I don’t like to check in hacks or knowingly broken code. Sometimes it can’t be helped – hotfixing code in production, last minute changes for a demo etc. – but it should never be the norm.

I also don’t like to work long days regularly. In general, it’s bad for your health and your relationships.

Sometimes it’s fine. Hell, sometimes I’ll get caught up in some problem and you’d have to fight me to take my laptop away at 3am. But that’s different. Developers are problem solvers and sometimes the problem becomes and all-consuming monster that will be on your mind until you beat it into submission. In those situations, it makes sense to work on the solution as long as it feels necessary.

I don’t like to be working at 3am solely because there isn’t enough time to meet the arbitrary deadline imposed for a piece of work.

In one of the cycles I mentioned above, my manager told me he didn’t want me working long hours. I said that was great and asked if the deadline had moved. He said no. The deadline remained the same and had to be met, the amount of work was the same, and the team size was the same. He just didn’t want me working long hours. I think that was my last cycle.

Diminishing Replacements

On projects like this, developers will start to look around for other jobs, maybe go on a few interviews.

Unless you’re paying way above market rates (in which case, why are you penny-pinching with budgets?) or have amazing perks, your best developers are going to leave. And then you’re going to have to try and hire quality replacements quickly since you have no contingency in your project budget. And that’s neither cheap nor easy. And just piles pressure onto the remaining team members.

Again, I’ve worked in places where a high percentage of developers who could leave, did. So what you mostly get left with are the devs who nobody else wants to hire, and the ones who don’t care. That’s not a fun working environment. Believe me: I know. Ask me for horror stories sometime.

Solutions

So, as a manager, what can you do? When planning out work, keep this in mind:

time = features x quality of work

If your budget or deadline isn’t big enough, you have to lose either features or quality. The alternative is artificially increasing time by overworking your developers and that’s going to lead to morale drops and team members quitting.

If you find that developers are working long hours regularly, have a look at the causation. Do you need more developers? Are your deadlines too short? Are you miscommunicating the importance of the work? Can you offer time in lieu or paid overtime to compensate?

(as an aside, I once worked three 90+ hour weeks in a row, then got given 2 days in lieu as thanks – oh how I laughed)

Is there a culture of overwork? Are the senior developers/managers/CEO seen to be working late night most nights? If so, they’re setting a bad precedent for your company culture.

A good work/life balance is important, and that has to be pushed from on-high. Otherwise you’re going to end up with a team of zombies.