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

"No, it's less effort than that"

smartguess.is

Post reply on HN
Print view View original

241–250 of 388 posts

Re: "No, it's less effort than that"

#241

Post by ballenf »

corry wrote: post #167

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unkn…

It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations.

The best case is to:

- line up the work in order of priority, taking into account prerequisites

- have sufficient stories in a ready for dev state

- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)

- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog

- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)

- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars

- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)

- be very careful that you don't make this approach the standard way of working

Re: "No, it's less effort than that"

#242

Post by kjkjadksj »

andyjohnson0 wrote: post #134
ResearchCode wrote: post #133

Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.

Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.

While thats true, business leaders still need to realize developing software is not the same sort of economic activity as running a horseshoe press or something. Machine can’t just be ran faster. You can’t also just plug another machine in the wall and expect it to know exactly what to do and double your output. Roadblocks often emerge that cannot be foreseen at all short of taking even more time to speculate on these potential blocks down the road.

Certain jobs do have these estimates better managed. For example, tunnel construction often hits unknown things underground that delays the project substantially in time and money. However this is par for the course with tunnel construction and such delays are even expected at this point.

Re: "No, it's less effort than that"

#243

Post by orwin »

rrr_oh_man wrote: post #152
orwin wrote: post #113

Earlier quoted context omitted.

Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved. I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done wh…

Any downsides to this approach, from your experience?

I only have 10 month working like this, but yes. More linked to the code than to the approach, but sometimes I become easy to get lost on the 'I also need to fix this' and deliver the code _really_ late. My way of dealing with it is simple: at 4pm (I usually stop at 6), I take a 15 minutes break, talk with people (remote or not), make some tea and stuff, recenter myself. Then I check what can be merged into master before 6, scrap the commits I won't use, rebase the rest into one or two commits, then push and ask for review (once it was the '30 minute task' that pulled a lot of other shit, in this case I stopped and called the team lead/PM to redefine the card).

Then if I still have time I do reviews, administrative work and probably end the day there. The nature of our team make that time management suitable.

Re: "No, it's less effort than that"

#244

Post by jghn »

jalapenos wrote: post #159

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - s…

Sometimes, but not always.

I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook.

But when I've been the manager pushing for smaller estimates, it's been because the business realities were that delivering *something* in a given time frame is critical. And if it requires making a house of cards and cutting corners, well at least we'll have survived long enough to deal with that problem later. And when I've been in that situation I received the usual pushback from engineering - the same pushback I would give in their shoes - that this is a terrible idea, will doom us to fail in the future, and we need to put in the leg work now to avoid future pain.

I've gone back to being an engineer but that experience as a manager has helped me quite a bit when dealing with this sort of divide.

Re: "No, it's less effort than that"

#245

Post by ResearchCode »

ejb999 wrote: post #174
ResearchCode wrote: post #151

Earlier quoted context omitted.

How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.

I agree, but a lot of big companies are all in on Agile and you (as a developer) don't really get a lot of say on the matter. Some high-paid consultants got paid a lot of money to sell it to the CEO, who then mandates it....so we are stuck with it ...until those same consultants have some other methodology-du-jour to sell.

Forcing every team in the company to use the same project management framework because consultants who never created great software claimed it's a panacea. Interesting decision.

Re: "No, it's less effort than that"

#246

Post by replyifuagree »

ballenf wrote: post #241
corry wrote: post #167

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unkn…

It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations. The best case is to: - line up the work in order of priority, taking into account prerequisites - have sufficient stories in a ready for dev state - during crunch time, be strategic about ticket assignment (you pay for this in the long term wi…

>be very careful that you don't make this approach the standard way of working

Legacy management steeped in manufacturing has entered the chat!

Re: "No, it's less effort than that"

#247

Post by GoToRO »

bdcravens wrote: post #179
GoToRO wrote: post #63

Earlier quoted context omitted.

Well then bussiness people are also disconnected from reality. If a developer can write code and estimate and deliver in time for bussiness, then he is not an employee. He is a founder. What you want is people that deliver like a founder but that don't get any share of the profits. You want gullible people.

The word you're looking for is stakeholder, not founder. Nonetheless, do you believe the opposite is true? If a developer doesn't feel like they are adopting the perspective of the business, are they a disposable resource?

You don't have to ask me, the latest layoffs prove that they are disposable even if the company has record profits.

Re: "No, it's less effort than that"

#248

Post by replyifuagree »

bloopernova wrote: post #207
jnovek wrote: post #187

Earlier quoted context omitted.

It’s not at all like sales quotas. The salesperson’s upside is directly linked to their quota, they are incentivized to fudge it as much as they can. What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.

Incentive to increase estimate might be: Deliver under estimate and get a bonus, raise, influence, or just plain old "well done" Be lazy and only work half the time while delivering "on time". Only work on the project half the time, spending the other half on something more worthy/interesting.

>Only work on the project half the time, spending the other half on something more worthy/interesting.

This is actually a pretty common motivation for devs who work under legacy management.

Re: "No, it's less effort than that"

#249

Post by Groxx »

regularfry wrote: post #81
nmstoker wrote: post #69

I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here. However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy. What's frustrating as a stakeholder is ludicrous estimates, which don't even s…

I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error…

Yeah, the 30 minute tasks would more frequently be quick if there was room for them.

You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.

Re: "No, it's less effort than that"

#250

Post by replyifuagree »

jalapenos wrote: post #159

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - s…

Your are correct in the majority of places where developers work. And this is simply because most developers work under legacy management where they are siloed off from the business - so typical Machiavellian silo on silo violence is employed to get one silo to commit to the desires of another silo.

It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.

Post reply on HN