Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Individuals Matter

danluu.com

Post reply on HN
Print view View original

281–290 of 419 posts

Re: Individuals Matter

#281

Post by rramadass »

dspillett wrote: post #275
rramadass wrote: post #271

Earlier quoted context omitted.

This is how planning should be done. Gauge people's expertise, put them on the path they can be most effective and then ask for their estimates. Take that to upper management and negotiate.

One problem with that is sometimes the estimates are done long before the work starts so when that item eventually gets to the top of the priority stack the person estimated for is working on something else instead. At this point things need to be re-estimated which can cause friction if the new estimate is longer (“but last time, you said…” or “when we asked Bob, he said…”). What I've done in the past is give an est…

Right, things are always probabilistic when it comes to us Humans :-)

I like to think of it like Algorithm Analysis; Best-Case (estimate by the expert mentioned above), Worst-Case (estimate by Noob who just joined the project) and Avg-Case (estimate by person who is already part of the project but is not responsible for that module). Add a fudge factor based on your reading of the circumstances and then haggle with Management. You now have a band with a upper bound and lower bound which can be realistic.

PS: You may find Douglas Hubbard's How to Measure Anything: Finding the Value of Intangibles in Business useful in this regard.

Re: Individuals Matter

#282

Post by onion2k »

Kalium wrote: post #124
paxys wrote: post #5

"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.

I got a harsh lesson about this in one of my very first jobs. A senior engineer on my team had built a rather complicated system. He was accordingly intimately familiar with all aspects of it. So when he estimated something on that system, it came with nearly all the discovery work already done. The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Nee…

The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me.

This is a really good thing to learn from, although I doubt it felt like it at the time. The key thing that every junior dev needs to take from it is that it's fine if things don't take however long the estimate is so long as you're regularly communicating with the PM. PMs hate surprises. They need to know exactly what the state of the project is at any given moment. For them to think that a story is progressing on track when it's not is very, very bad (in their minds; it doesn't actually matter most of the time.)

If you work on a story that's estimated to take 3 days and come back after 3 days saying "It's not done yet. I'm only half way through. I had to learn a ton of stuff!" then that knocks out loads of other things, and people get pissed off.

If you work on a story that's estimated to take 3 days, and in the stand up on day 2 you say "I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days" then your PM will (...should?) respect that you're keeping them informed. The senior might even step up to help you get there faster.

Practically all the actual work a PM does is communication. If you're not communicating with them then you're blocking them. No one likes that.

Re: Individuals Matter

#283

Post by fractalb »

efitz wrote: post #116

I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?” Every team I h…

You can just give a random guess on the timelines and save the developers time.

Re: Individuals Matter

#284

Post by selfhoster11 »

bodge5000 wrote: post #224
aahortwwy wrote: post #130

Earlier quoted context omitted.

> So show me a methodology that mere mortals can implement successfully. Commit to a deliverable or a deadline, but never both.

I'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?

You can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.

Re: Individuals Matter

#285

Post by Agentlien »

dspillett wrote: post #275
rramadass wrote: post #271

Earlier quoted context omitted.

This is how planning should be done. Gauge people's expertise, put them on the path they can be most effective and then ask for their estimates. Take that to upper management and negotiate.

One problem with that is sometimes the estimates are done long before the work starts so when that item eventually gets to the top of the priority stack the person estimated for is working on something else instead. At this point things need to be re-estimated which can cause friction if the new estimate is longer (“but last time, you said…” or “when we asked Bob, he said…”). What I've done in the past is give an est…

That's exactly what I was thinking of when I said we sometimes give estimates depending on who it gets assigned to. "It'll take a day if X does it, but probably three if another SE does it".

Re: Individuals Matter

#286

Post by rramadass »

hyperman1 wrote: post #260
jseban wrote: post #231

Earlier quoted context omitted.

Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this. When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a program…

I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.

>I think they underestimate the value of specific knowledge

This is the crux of the issue. When it comes to "Knowledge Work" almost every step sooner or later becomes a specialization. For example, I used to sneer at the role of a "Build Engineer" until i was forced to take up that role in one project. The combination of HW Platforms, OS versions, config switches, build flags, magic incantations etc. quickly gave me a new found respect for a job which i had considered "trivial".

Re: Individuals Matter

#287

Post by JBiserkov »

Jensson wrote: post #93
PragmaticPulp wrote: post #88

Earlier quoted context omitted.

> I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it). So your 500X engineer knows a 5000X engineer and he wrote as much code as 999 other engineers combined? (That would make him a 999X engineer, FWIW) A 500X engineer (per your measurements) would have to write 500 lines of code every day without fail,…

For any positive real number X and employed engineer A with positive productivity, I can find an employed engineer B where productivity of A is more than X times the productivity of B. Proof: Pick B to be an engineer with productivity 0. 0 * X = 0 for all X. Productivity of A is defined to be positive, so is greater than 0. Hence productivity of A is greater than X times the productivity of B.

And then there's people with negative productivity.

Re: Individuals Matter

#288

Post by caffeine »

jcims wrote: post #36

I'm an introvert, I love working from home, I live in the woods with a 1/3rd mile long driveway. Since my youngest went off to college I'm here alone with her fish and a cat. I go into town once or twice a week for supplies and the rest of the time I'm just out here in my little sanctuary enjoying the lack of people. That said, even I know that while individuals matter, teams matter more. And I don't see anything in…

I think the article also applies to teams - in particular, how not to destroy teams by ignoring the individuality of the team members, and indeed of the team itself.

Each individual grouping of humans is unique in its social dynamics, relationships, culture, expertise, etc and so will be uniquely effective or ineffective at identifying and achieving desired outcomes.

Re: Individuals Matter

#289

Post by Andy_G11 »

This is not a planning problem - this is a power problem. If competent and incompetent people alike are told to regard each other as peers in a meritocracy, a range of possible outcomes ensues.

The only option for incompetent staff will be to game the system by ensuring that they pass a load off their shoulders to competent staff and cultivate cultural and organisational aspects that let them give the impression of performance without actually having to perform.

This article is quite anecdotal but it is possible for organisations to require high performance from members. E.g. I assume that there is less scope for less competent individuals to hide out in teams like SWAT teams, heart or brain surgery teams, bands or movie crews: every one is visible and under the spotlight for delivery at any one time and relied upon by others to be at the top of their game.

Critical dependence should trim incompetence from organisations, but will only work if scrupulously applied. Perhaps logically, this might work best in fluid structures where selection and deselection of team mates / suppliers is very easy.

Re: Individuals Matter

#290

Post by badtension »

paxys wrote: post #5

"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.

In my experience it still makes sense to estimate together using the same story points (or T-shirts) when there are people ranging from almost no experience to very senior ones working on a project.

1 SP for a senior may take 1h of his time and for a junior that would be 2-3 days but it's still 1 SP - a relatively simple task. This is in contrast to a fallacy of recalculating SPs to time-based units cause if we do that we might as well just estimate in hours/days.

It's about agreeing on some baseline first (what does 1, 2, 5 SP task look like?) and going on from that. We just need to remember that velocity will be different for different people so team capacity calculation is going to be all over the place but I think this approach can be useful.

Post reply on HN