[pleasecalllater]

This is what I observed in a couple of companies. The most amazing thing is that some developers think that all is fine, some even like it.

Set a deadline without asking the developers. Or ask them and ignore their estimates. Or ask them and ignore that they will know after some initial checks which will take two days ("nope, we must know the deadline now") - so it's basically just guessing.

Then the deadline is "set in stone". This means only that it's a good way to punish the developers. Then they are forced to work during weekends.

At the end they are punished with bad yearly reviews, decreased bonuses etc. Sometimes some are even fired.

Then the management just moves the deadline to another, equally stupid, term. Of course they will get the full bonus "you see, the developers are lazy, but we fired the worst one".

Then the cycle repeats. The most funny thing is when the deadline is for some internal stuff where the client is fully internal and really doesn't care if the product will be this month or the next one.

[whatshisface]

Most bad management practices boil down to answers to the question, "how can you manage people you don't trust when they're doing work you don't understand?" Of course if you've reached that point, the grevious mistakes have already been made.

[codeisawesome]

It’s depressing to think about the whole industry operating like this. Other than being very flexible on where you work and moving soon as the BS train picks up steam - any other tips to survive?

[EnderMB]

As someone that has spent years in consultancies and agencies, this one stings a lot.

A slightly different scenario I see all the time, even today, is when a company takes on a fixed-cost job to build something. We come up with a basic MVP feature set, run it through the standard MoSCoW process, and then estimate how long each feature will take.

We end up with a final figure, and it's over budget. We strip things out, and it's still over budget. Rather than cut out features the client wants, estimates are cut down to fit the budget, or planning time is stripped out and we're expected to go straight into a build.

Funny enough, these projects always run over, and we always end up missing a ton of stuff the client wanted, because in the process of being lean we forgot to do any kind of documentation of changes, or to explicitly get in writing what the feature is supposed to do.

[oceanghost]

I worked for a company that would do this exactly, with an additional variable. The sales folks' bonuses were based on the original estimate, not any overruns. So they'd promise the customer a certain feature set then, write up the minimum feasible estimate, collect their bonuses, then blame engineering for the extra cost, feature creep, etc... when it was all by design.

[klancaster]

I worked with a non-technical manager (banking background, somehow wormed his way into managing development) who never asked devs what they thought a task would take. I finally convinced him that this could not possibly work. I sat with him the first time he asked a dev how long the current task would take. The dev said "4 weeks". This guy said "I think it should take 2, so that is what I am putting in the schedule". Mind you, this guy had never written a line of code and had NO basis for his "thought" on the task length.

[_def]

Haha that's great. "Let's settle with 3! Ha, good deal."

Things like these make me sometimes think that the whole business world is just a bunch of people lying to each other. Very depressing.

[wikiman]

My personal favorite are the bosses that poll the group and pick the lowest estimate

[newdaynewuser]

Another trick management plays is they will ask you for super rough estimates. And tell you that whatever estimate you give doesn't mean anything.

So you play safe and give them a super rough estimates and a lot of buffer.

And now all of sudden you are invited to meeting to explain your super rough estimates. You remind them that it is just a super rough estimate. They ignore that.

Now if you are weak, they will get you to cut your estimate. If you are strong they will ignore your rough estimate.

So they create a deadline based on your estimate. You remind them that it is just a rough estimate and deadline seems unfair. They tell you just do your best, deadline is not a super strict deadline.

Of course, project scope is bigger and there is scope creep. You are unlikely to make deadline.

All of sudden you are being asked why is project going to miss deadline. They tell you you did estimation, you need to meet this deadline. Work extra hours.

You try to remind them that you were asked for a super rough estimate but you are ignored.

Also your teammates hate you because they think you promised the deadline and now they have to work over weekend to cleanup your mess.

[mekane8]

It took me like four years working in a consulting agency to finally realize that I should refuse to give any estimates when I couldn't be pretty close to certain of the accuracy.

[jpm_sd]

Equally bad, ask inexperienced developers to come up with schedule estimates, then insist that they be held accountable to those laughably inaccurate estimates.

[kbrannigan]

We have a new trick too, every task in the backlog is estimated as 1 day worth of work. Most of the times those tasks take 3-4 days tops, Even when we say otherwise, they still force the 1 day story rule...

[phaedrus]

[The common definition of estimate is] "the most optimistic prediction that has a non-zero probability of coming true." ... Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished estimating. -- Tom DeMarco ---- as quoted in the book, "Software Estimation" by Steve McConnell.

[jrs235]

Off topic. Nice username! I wouldn't have stopped or noticed except from reading HN comments on the ZATAOMM story posted the other day.