Hacker News new | comments | show | ask | jobs | submit login
Beware your project’s Schwarzschild radius (peternixey.com)
29 points by robheaton 1546 days ago | hide | past | web | 9 comments | favorite



   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.


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.


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.


> 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.


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.


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

https://news.ycombinator.com/item?id=5953737


Are those graphs coming from real data or anecdotal evidence?


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.


I think they are more like anthropology graphs (e.g., http://www.flickr.com/photos/runningafterantelope/2366031003...)




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: