[HN Gopher] What Do We Know About Time Pressure in Software Deve...
___________________________________________________________________
What Do We Know About Time Pressure in Software Development?
Author : chrisaycock
Score : 50 points
Date : 2022-01-12 12:49 UTC (1 days ago)
(HTM) web link (www.computer.org)
(TXT) w3m dump (www.computer.org)
| AnimalMuppet wrote:
| "If you want it bad, that's how you're going to get it." That is,
| time pressure kills quality.
| MaysonL wrote:
| "Soon, cheap, and good. Pick two."
| commandlinefan wrote:
| I don't know - what are you going to do when they say "ok,
| soon and good". Are you going to demand a raise before you
| deliver?
| rising-sky wrote:
| > [In this article, time pressure refers to both budget pressure,
| e.g., eight hours (budget) to do a task, and schedule pressure,
| e.g., a task that must be done by tomorrow.]
|
| Aren't these the same thing? the latter being somewhere around
| 24hours give or take
| flerchin wrote:
| Not if you can have an army of people work the problem.
| alex_anglin wrote:
| Then you too can enjoy The Mythical Man Month.
| ejb999 wrote:
| in case you don't think you have time to read it all, buy 3
| or 4 copies of it to speed things up
|
| (there, I summarized it for you :>) ).
| lmilcin wrote:
| No, they are not.
|
| I may want something to be done by the end of next week and at
| the same time I would like somebody to spend less than 4 hours
| on the task. Spending entire two weeks of effort would not be
| acceptable in this case even if the task was delivered on time.
|
| An example would be a task that is not on the critical path of
| the project but still needs to be done. There is a deadline by
| which it must be delivered or it becomes part of critical path
| and starts delaying entire project.
|
| Assuming the task is performed by one person using the fraction
| of the time available before the deadline, I would like to be
| able to use the rest of that time (resource) as either a buffer
| in the project or for completion of another task. Having the
| person deliver the task before deadline but after two weeks of
| continuous work where I assume only 4 hours will be necessary
| means that the project was deprived of almost two weeks of
| buffer or there are now some other uncompleted tasks.
|
| When we are talking about project management, there is an
| important, clear distinction between time and cost.
| chrisaycock wrote:
| Treating every project as if it's in emergency mode is a great
| way to burnout the team and get shoddy work results.
|
| Another idiotic practice is multitasking since context switching
| introduces tons of overhead.
|
| And tying it all together, the importance of a project determines
| its resources. A truly critical task needs 100% focus. If a
| manager isn't willing to assign a full-time employee to a task,
| then that project isn't critical.
| disambiguation wrote:
| Well written and thorough article, but I can't help notice if
| this isn't just reverse engineering a standard MBA curriculum.
|
| > Time pressure is also reported to be the most frequent external
| cause of unhappiness among developers.
|
| > The inverted U-shaped relationship is one typical example of
| this, which means that time pressure increases efficiency up to a
| certain point, but after that increases in time pressure cause a
| decrease in efficiency
|
| A good manager knows how to sustain just the right amount of
| pressure.
| awb wrote:
| > A good manager knows how to sustain just the right amount of
| pressure.
|
| And they know about Parkinson's Law:
| https://en.m.wikipedia.org/wiki/Parkinson%27s_law
|
| > Parkinson's law is the adage that "work expands so as to fill
| the time available for its completion."
| e2e4 wrote:
| https://dilbert.com/strip/2022-01-02
| commandlinefan wrote:
| This article implies, but doesn't come right out and say,
| something that I strongly suspect: that producing an accurate (or
| even close-to accurate) software project estimate is a time-
| consuming, unpredictable task. The question nobody seems to be
| examining is whether or not the cost of doing a large, expensive
| up-front analysis that might take an arbitrary amount of time is
| less than the cost of just doing it concurrently with the
| software development itself.
| kqr wrote:
| Oh, people are examining that question alright. It's just
| complicated and therefore hard to come up with a definitive
| answer.
|
| If I had to summarise what I have read on the topic, it would
| be that either way works, but the up-front analysis is orders
| of magnitude more expensive. Some sectors require this:
| defense, nuclear, medical, and so on. In most areas, you don't
| need that and can't afford it in a competitive market.
|
| But to hint at the complexity of the question: Not only is
| every project different, there are also sneaky feedback loops
| in there.
|
| By the time you have completed the large up-front analysis the
| world is likely to have moved underneath you, invalidating some
| of the assumptions that went into the analysis. You can shape
| your analysis to account for this, for sure. But at that point
| does it still count as one up-front analysis or several? Is it
| truly up-front if it leaves options and decision points open
| for later?
|
| And it's a continuum: the more options and deferred decisions
| in the analysis, the more it starts to look like it's clearly
| done in parallel with the implementation. Where do we draw the
| line?
| nonameiguess wrote:
| While this is likely true, the problem is W2 labor tends to be
| compensated on a more or less fixed price per unit of time
| basis, and to cover that cost, you need to bill clients roughly
| in proportion to total labor time spent, and most clients
| aren't going to purchase something for an unknown price to be
| named later. So you need to estimate to give them a price.
|
| From the perspective of the seller, these estimates don't even
| need to be "accurate" as long as you're making many of them and
| the errors are symmetrically distributed. There's even math
| theory behind this called Fermi estimation. The problem is,
| from the client perspective, they can't average out the errors
| over many estimates if they're only buying one thing, and from
| the seller perspective, I don't think our errors _are_
| symmetrically distributed. Instead, we consistently
| _underestimate_ how long something will take.
|
| It's not even unique to software. There's a huge housing boom
| going on where I live, with condo developments all over the
| place, and not a single one is actually ready to open by the
| season their sign out front claims they'll be open. Defense
| acquisition. Highway construction. Everything takes longer than
| budget forecasts claim.
| kqr wrote:
| Part of the problem, especially when it comes construction
| and defense, is awarding contracts to the lowest bidder with
| effectively no punishment for exceeding the initial estimate.
| This pretty much guarantees underestimation, both for
| statistical and behavioural reasons.
| lumost wrote:
| The problem is that once someone gives a date, then they are
| judged based on that date. In some cases, the software stops
| making financial sense after some multiplier of this initial
| date.
|
| To avoid estimation you need to avoid dates and avoid projects
| that have high timeline risks. This means you would need to
| judge on speed to completion, or better customer satisfaction
| for project execution.
| coldcode wrote:
| A lot of these articles assume the work being estimated will
| remain relevant during the estimated timeframe. My last (very
| large, not FAANG) employer started every project with a hard
| deadline, estimates were only used for budgeting not time, and
| then every project changed on a daily basis until it was
| obvious it would never ship by the deadline which was changed
| at the last minute. Every single project worked like this (note
| these projects were for us not external clients). I know of no
| theory of estimation that can account for continuous change
| unknown at the start.
| int0x2e wrote:
| About 10 years ago, I worked on a large, multi team (multi-org
| really) project that was run using TOC (Theory Of Constraints).
| Put very very very simply, every team was told to give honest,
| buffer-less estimates for their primary work areas, and then a
| global project buffer was added as a factor of the sum of
| estimates. At any point in time, we worked as if every single
| thing would line up perfectly, so upcoming milestone targets
| would often feel crazy or unlikely. But people being eager to
| please, and mostly unwillingness to be the one team blocking the
| entire project - meant that folks worked hard to meet some of
| these targets. It was extremely hard. It was a bit stressful. It
| felt crazy at times. But it got done in half the time I would
| have initially expected such a complex project to take. To me,
| the most impressive thing about it all was that the project
| leader drove us all quite hard but was super cool - he explained
| that he wanted everyone to be open and honest about blockers so
| they could be moved with the full force he was given, and that
| actually, his way of measuring project progress was the rate at
| which schedules slipped.
___________________________________________________________________
(page generated 2022-01-13 23:00 UTC)