Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
ars171419dI just say "it depends".
sladuled834919d42 // mins, hours, weeks, years..who knows.. & pass along a copy of the book if they don't get the reference..
IntrusionCM637919dBad 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.
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.
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.
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.
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.
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.
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.
myss458118dIn case #1 you should've stated I can only give you "high level estimate" - which can be subject to larger error margins
Sputnik7918dAh 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.
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.
saucyatom123018dex 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.
ars171416d@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.