[rufflez]

In my experience, metrics are a giant waste of time for engineers and engineering managers. Project managers and folks who depend on the fruits of engineering labor on the other hand love these metrics. It is simpler (and wrongheaded) because who wants complications after all? Look at the trivialization in this article for instance - "tasks come in, and software comes out". Oh really? I had no idea!

Tasks vary drastically from project to project,including due to varying requirements, ambient software environment, technological changes and a host of other factors. Metrics are a way for project managers to pass the buck on to the engineering teams and nothing more.

[tra3]

You gotta have some way of answering the "how long is it going to take" question. There's no better way of predicting things than looking at how long things have taken in the past.

Unfortunately what everyone forgets is that historical information only applies if you are doing "a thing" that is similar to what you've done before.

[tadfisher]

One way to address this problem is to not ask the question, but to work with your teams to set goals for a longer period of time such as a quarter. Then structure your organization such that it doesn't depend on the exact timing of work completion.

[switchbak]

It really comes down to: can you provide the value we need in this area. That value might be "validate experimental research is implementable", or "perform a spike to de-risk a future effort".

There's a fog of uncertainty that gets impenetrable past a certain time horizon. We need businesses that are capable of forging ahead into the unknown, being honest about the level of confidence given our knowledge at the time. I don't see that approach coming out of MBA schools, and I think Elon's approach is in marked contrast to that.

In many ways old school grassroots agile has penetrated the lower levels of the org (to some degree), but the upper levels haven't changed in decades, and this impedance mismatch is most visible in the rigidity of planning (which is also forced on them by outside pressures).

[djbusby]

Q: how long will this take?

A: what is your budget? What other work will you sacrifice?

[doctor_eval]

> You gotta have some way of answering the "how long is it going to take" question.

Code (implementation) is an integral alert part of the software design and planning process, and you can’t know how long something will take until that’s complete.

While estimation seems to be a shibboleth of certain types of project management, the fact that implementation time estimates are rarely accurate - and often significantly wrong - suggests that they are not as vital as we’re lead to believe.

[coffeemug]

You don't ask "how long is it going to take?" You set a deadline and let the black box do whatever internal negotiations it needs to meet it.

[ip26]

Or, even more difficult, are you on track to deliver your twelve month goals? Hard to know, and easy to lie to yourself.

[throwaway787544]

I am an engineer, and I rely heavily on metrics, because my job requires quantifying that a system is working correctly. It is impossible to do that correctly without metrics.

Similarly, managing a product team is also managing a running system; that system is just made up of meat sacks whacking plastic buttons with their bony protrusions, rather than computers humming away in data centers. A product manager still needs to quantify that the system making that product is working correctly, and metrics are essential. Otherwise you will only be guessing as to how the system is working, and those guesses will be much more haphazard as the system grows.

[bergenty]

The hard truth is metrics work. I can quantify someone’s performance and if they’re not doing well put pressure on them to do better or hire someone else. Velocity is a pretty good measure of someone’s performance especially if the estimating is done in a sprint planning session with the entire team.

[jdlshore]

The harder truth is that metrics only appear to work. As soon as you use metrics to judge performance, people will start gaming them. They’ll do whatever it takes to get a good score, regardless of whether it’s good for the company or its customers.

The metrics “work,” in that they’ll go up, but the things you don’t measure will get worse, often (eventually) catastrophically.

In the case of velocity, you’ll get people taking shortcuts and sacrificing quality, both internal and external, so they can juice their numbers. The outcome is technical debt and arguments about what it means for something to be done, resulting in slower progress overall.

Source: I’ve been consulting in this space for a few decades now, and have seen the consequences of using velocity as a performance measure time and time again.

(Other metrics are just as bad. See Robert Austin, Measuring and Managing Performance in Organizations, for an explanation of why knowledge work like software development is incompletely measurable and thus subject to measurement dysfunction.)

[geekjock]

The hard truth is that using velocity to measure performance will guarantee that developers bias their estimates to ensure they make themselves look good, thereby making your "estimates" useless.

Anyone who's built software knows that estimates are guesses and are bound to change once the work actually begins (not to mention if scope changes midway through).

Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning.

[fnordpiglet]

I’m glad I don’t work on anything you’re responsible for. I’ve made a great career out of hiring the people folks like you burn out and frustrate.

I’ll bet $5 that people conform to your model by working longer than necessary and your “velocity” is considerably lower than it could be, despite being measurably consistent.