Why management has such orgasmic attachment to numbers?

Example 1.
Mngr: split this into tasks
Me: done
Mngr: now estimate these tasks
Me: can't. Team is new and codebase is unknown. Any estimations would be subjected to huge error and I will not commit to anything if I'm not at least partially sure.
Mngr: but we need some timeline
Me: so give it yourself. I'm not doing it

Example 2.
Mngr: we need to measure how your knowledge sharing sessions impacts our organisation
Me: how?
Mngr: e.g. amount of bugs lessen in next quarter
Me: bugs can go up and down because of hundred other reasons. Also, knowledge sharing is just to inspire people, it's up to them if they keep educating and growing. Me sharing knowledge 1h per week, I can't guarantee they will understand and apply this new knowledge.
Mngr: but we need to measure it somehow, otherwise it is useless.
Me: <speechless facepalm frustrated>

I just say "it depends".

@ars1 everything "it depends" in this industry. I'm just ranting due on most common behaviour I've noticed 😉

42 // mins, hours, weeks, years..who knows.. & pass along a copy of the book if they don't get the reference..

Bad management wants to feed their Excel tables.

An estimate of time - if properly communicated - okay.

But numbers who cannot proof a thing because of the massive set of variables involves.... I think I said last time: It's like licking someone's forehead claiming it's the best way to measure his temperature.

Noooonsense.

@IntrusionCM when I google this topic, 99% articles justify measuring everything without really covering other side of this matter - useless or meaningless metrics/numbers.

Are there any good articles, books - that covers topic how meaningless metrics/numbers makes things bad?

once I saw nice idea of using progress to predict delivery. Once split to task, just complete task and with time you can predict more accurately estimate delivery of the project, also if you change number of tickets, you can see how delivery changes.

Pretty neat idea I would like to see used in my future project.

@bzq84

I'm bad at remembering books and articles.

Note that the problematic part is not _measuring_ it.

That could be even a motivational thing.

E.g. Github's commits per day feature.

Pretty neat.

It gets bad when you utilize the metrics and seemingly throw them together to justify your (as a manager / from a managers perspective) stupidness.

I e.g. absolutely love GIT.

I love GIT History.

I love looking at PRs, evaluating commit metrics and so on. Maybe as an _indicator_ if someones performance suddenly drops.

A nice talk between two persons and a lil: Everything okay? can sometimes prevent desasters.

What's not okay is to stick these metrics up someones arse as a reasoning to cut budgets (you underperform, you earn less money) or to enable a form of punishment / draconian slavery.

And the last sentence applies to a whole lot of management and to this rant.

"Anything can be turned into a weapon - the question is whether you use the weapon"

@IntrusionCM if manager will measure me with this example (commits per day) I'll keep making small git commits for every typo and other small and meaningless sh*t.

Now, everyone says that metrics are not performance, but once something is agreed to be metric, then 100% sure it will be used against you during next performance cycle.

@bzq84 bingo. and that's what i dislike.

but i never understood this type of management.

all this behaviour leads only to one possible outcome: unhappy, demotivated drones who want to get fired to leave the hellhole.

How this should improve anything is a miracle to me.

@IntrusionCM since 2years I'm fighting such mindset in my company. So far I'm loosing all the battles.

It's good to know that I'm not the only one seeing absurd of such approach. <scream>

I don’t think they will keep you on work very long.
If you can’t give even a partial estimate for a task and refuse to commit to deadlines, that’s a dev I wouldn’t want in my projects.

@NoToJavaScript yeah, I also have enough of their BS, so I guess we're on the same page 😉

I'm frustrated right now - thus my anger.

@NoToJavaScript
If you select devs by their ability to give roughly correct time estimates for what they do, you basically only get coders who mostly do repetitive tasks as only the non-creative, non-research, non-inventive tasks are deterministic enough to allow good estimates by extrapolating measurements from the past.

The result is a write-only project full of DRY violations and code copied from the internet glued together with boilerplates.
If you are really aiming hard for delivering the cheapest possible minimum viable product, that may be okay.

But don't ever search for seniors that way. Seniority is all about the non-repetitive non-deterministic and impossible to accurately time-estimate parts of software development...

@Oktokolo This is true.
But if I ask you “How long to <insert anything> ?” you should be able to give rough estimate.
If you can’t give me an estimate, you cannot do the task because you don’t even know what first step you will take. Noone asks a perfect estimate. But is it days ? weeks? Months ? That should be easy to answer for any dev for any task on any project.

@NoToJavaScript
That really depends on what <insert anything> is. First, knowing the first step isn't the same as knowing all steps, but estimates are expected to include all steps. Second, the first step may be research - in which case even thinking about trying to come up with an estimate before doing the first step is a sign of stupidity.

Sure you can guess whether it takes days, weeks, months, quarters, halves, or full years.
But most often you may still be off a unit.
Sometimes its two.
But can also be three.
And termination of the process isn't actually guaranteed...
Then we speak about humans... they generally exhibit an insane variance in productivity - especially the more creative ones (which are the ones you want for non-trivial software development).

I mean: Yes, you can generate an estimate based on your experience. But the insane error margin makes them almost useless - and managers generally don't get that.

@ars1 The best response.

In case #1 you should've stated I can only give you "high level estimate" - which can be subject to larger error margins

Ah yes, do X amount of scripts every iteration, without considering that some scripts are 5 times the size of others.

And then somehow that number gets compared in the performance cycle against other employees that aren't even in the same project, where test authoring might not even follow the same standards.

@Oktokolo thanks bro. I wouldn't ever wrote it better. Exactly my point

@NoToJavaScript i answered my Manager "2weeks up to 2 months". First step is known, but amount of skeletons in the closet found was astonishing.

Do you think my manager was happy with above?

He was not.

So I rather give no estimations.

Today he was handling me responsible for another "estimations" because I said "maybe a week". What he understood was "maximum a week with great quality".

Fuck this shit.

ex 1 is understandable as you'll need an estimate of how much time something takes to calculate the (estimated) cost of developing, which is important for setting a price / making a contract.

ex 2 is either someone who doesn't know what's good for the business or someone who has (financial) incentives which are not aligned long-term survival of the company.

As for all thy numbers thou shalt not forget: A measure that becomes a goal ceases to be a good measure.

@bzq84 Estimates are just a way to burn yourself with management. The only accurate estimates I've had before were with good agile implementations, which is what I'm going for right now. Can't really go into long term estimations though, unless "months" or "years" is good enough for whoever is asking.