

Beware your project’s Schwarzschild radius - robheaton
http://peternixey.com/post/54026285667/beware-your-projects-schwarzschild-radius

======
anologwintermut

       The Schwarzschild radius (sometimes historically referred   
       to as the gravitational radius) is the radius of a sphere 
       such that, if all the mass of an object is compressed  
       within that sphere, the escape speed from the surface of    
       the sphere would equal the speed of light.
       --Wikipedia
    

Personally, I think your project getting so big that not even light can escape
is a far better image (your project would literally be a black hole) than the
on the article implies where you cannot get a rocket of the surface.

~~~
comrade_ogilvy
A rather stretched poetic usage of Schwarzschild radius, and it seems the
author simply stumbled away from the denotational meaning. Nonetheless the
metaphor worked for me.

I am unaware of a specific name for the concept that a larger rocket has
diminishing returns because of the disproportionate addition of fuel weight.
Like the article suggests, one has to wrestle with the payload requirements to
get out of this trap.

------
A1kmm
If you have larger projects, agile project management methodologies have a
good solution:

The Scrum method advocates keeping two backlogs - a product backlog and a
sprint backlog; the sprint backlog is created by the team off the product
backlog at the beginning of a fixed duration sprint (and adjusted by the team
if needed), and the sprint backlog belongs to the team, and can't be changed
by the business / users (instead, new issues go to the product owner, who can
add them to the product backlog for them to get picked up at future sprints).
The team is supposed to produce something that is 'complete' for some
definition of complete at the end of each sprint.

Because sprints are fixed in time (maximum of one month) and have finite scope
(whatever items on the product backlog the team are able to take to
completion), each sprint delivers iterative forward progress towards the long
term full set of requirements, and even if the project runs out of money after
a few sprints, the most important requirements will have been met. The product
owner still gets to prioritise a backlog (the product backlog) according to
business and user requirements.

~~~
jbert
> even if the project runs out of money after a few sprints, the most
> important requirements will have been met. The product owner still gets to
> prioritise a backlog (the product backlog) according to business and user
> requirements.

Interesting, but if the team are choosing items from the product backlog there
seems no guarantee that the product owner will get the stuff that _they_
consider important done?

If the team assemble their sprint backlog, they'll do their own prioritisation
which may not sync with the product owner's.

------
stephengillie
_Like a bird flying into a strong wind you will slow down and may even start
to move backwards._

In a way, this reminds me more of something I read from a computing book as a
child, about early time-shared mainframes, where when overloaded a mainframe
would spend more time loading programs from disk to memory and saving them
back than it would work on any program. At one point, called a "beached
whale", the system is constantly loading and saving because there is no time
for any processing, as too many processes are fighting for CPU cycles.

------
mindstab
Ironic that GNU/HURD is also on the front page of HN

[https://news.ycombinator.com/item?id=5953737](https://news.ycombinator.com/item?id=5953737)

------
jared314
Are those graphs coming from real data or anecdotal evidence?

~~~
comrade_ogilvy
I rather liked the graphs, made up as they were. It clarified something
observable in real life projects gone wrong: in order to partially cover up
for a badly slipped schedule, new business requirements get added on. "We were
late, but we did so to release an even better product to our customers."
Unfortunately the inability to scope a project correlates with an inability to
manage ad hoc requirements and the ensuing arbitrarily raised expectation.

