I think it was due to voids in the hinge area causing localized plasma impingement and heating. The v3 design has a more continuous shape around the hinges.
Right. I’d have to go back and find explicit statements about the redesigns, but as I recall the v1 Starship had the flaps further forward and lots of tiles missing around the hinges. V2 moved the flaps back so that the hinge is shielded more by the curve of the body, but still had not enough tiles. V3 has almost continuous coverage using much more uniquely curved tiles. They look harder to make but not as bad as the shuttle’s.
I had a manager institute PERT estimations for every task/sticky, which was interesting but not necessarily worth it.
In the end, the work takes the time it takes, and nobody knows how long that will be ahead of time. Fiddling around with estimates helps with ranking but not prediction.
If the work takes the time it takes and nobody knows how long with that, why not track and iterate on the predictions versus outcomes creating experience and data that would enable prediction and prediction refinement?
Over time the estimates should be trending closer to outcome, as the process improves in breaking down and specifying the details that impact prediction & work, and the statistical gap from previous estimates gets baked into future estimates. The process, capabilities, ability to identify diverging factors, and correction of initial estimates should all be maturing concurrently.
The entire point of using fuzzy numbers is to enable fuzzy yet usable predictions. Similar work in a similar situation, armed with specific statistics and outcome, should be highly predictable at the team and individual level over time.
Sure, that’s the theory behind middle management. Unfortunately the bosses who run the places keep saying yes to things that have never been done before and for which few priors exist.
Alternately, it captures a bit of so many things (tech-debt in codebase, mental health of team, task risks) that it's best to avoid trying to link it to any one thing.
The past X weeks of point-estimates is what you use to forecast which things fit in the next Y weeks, and you can't have both stability and forecast accuracy. Any attempt to permanently "peg" a point to a certain number of man-hours is going to interfere with that accuracy.
> If we pipe seq to less and look at the list of running processes using ps aux, we can see that the seq program is not running. ... This explains why the seq program is killed when it is piped to less.
This explanation isn't correct, since a running `less` would not close the pipe and is still a reader. Writes to the pipe would block until `less` fully consumed it, or until `less` was quit such as with the `q` command.
The text _is_ correct if you add a missing step to `q`uit out of the `less` program. I think this step must have been dropped along the way. Unfortunately the screen capture doesn't show this step either.
There's a big red disclaimer at the top of the page: "Ancient CS 61 Content Warning!!!!!1!!! This is not the current version of the class. This site was automatically translated from a wiki. The translation may have introduced mistakes (and the content might have been wrong to begin with)."
The description of `seq` isn't even correct: "If a second argument is provided, the numbers will stop printing at the once the second number has been reached. Otherwise, the numbers will continue forever"
Nope, `seq`'s arguments are defined as `[first [incr]] last`. With a single argument, it counts up from 1 to `last`. Maybe some previous version of `seq` behaved differently, but not as far as I can recall.
But again, can't hold anything against the page given the disclaimer.
Wouldn’t the seq process keep writing to output until the output buffer of the pipe got full and then the next write would block and seq would just pause waiting for the write call to unblock? Or my understanding of piping is incorrect?
The slide says something like "run the command `seq 2 10000000 | less` and check `ps`, notice that `seq` isn't running". But that isn't how the processes will behave, `seq` will continue running (albeit blocked) until `less` is dead or closes the pipe.
It's funny, I also read the book as a teen, and I came away from it amazed that IBM was dedicating entire team members to inter-/extra-team communication.
Before that I hadn't even considered how necessary a product manager or project manager were in software development.
But it was the "No Silver Bullet" essay added as a bonus in my copy that I think about the most. "Never again will we see a 10x productivity increase in a decade", this is self-evident now but must have been crushing to people who had experienced the first compilers, the first high-level languages, the first interactive terminals, and waited for the next incredible leap.
reply