Removing stuff is never obvious yet often better

Re:Removing stuff is never obvious yet often better by QuantumGood on Monday August 26, 2024 @03:04AM (#41354693)

At one time Musk stated that SpaceX data suggested that needing to add back 15% of what was removed was a useful target. He suggested that some of the biggest problems came from failure to keep requirments simple enough due to smart people adding requirements, because they offered the most credible and seemingly well-reasoned bad ideas.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by infogulch on Monday August 26, 2024 @03:13AM (#41354725)

Thanks I couldn't remember the exact number. 15% seems like a reasonable r&d overhead to reduce inefficiencies in the product. But I suspect the optimal number would change depending on the product's lifecycle stage.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by lucianbr on Monday August 26, 2024 @03:32AM (#41354821)

How would you measure / calculate something like that? Seems like adding some amount back is the right situation, and not too much either, but putting a number on it is just arrogance.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by QuantumGood on Monday August 26, 2024 @03:35AM (#41354841)

Either accepting or dismissing the number without understanding its purpose or source can also be arrogance, but I agree that throwing a number out without any additional data is of limited, but not zero, usefulness.

When I want to know more about a number, I sometimes seek to test the assumption that an order of magnitude more or less (1.5%, 150%) is well outside the bounds of usefulness—trying to get a sense of what range the number exists within

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by lucianbr on Monday August 26, 2024 @07:26AM (#41356110)

No, dismissing something that is claimed without evidence is not arrogance, but common sense.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by QuantumGood on Monday August 26, 2024 @11:08AM (#41357886)

I think we're getting hung up on the concept of dismissing. To question skeptically to learn more is different than to dismiss.

The 5 Step Design Process emphasizes making requirements "less dumb," deleting unnecessary parts or processes, simplifying and optimizing design, accelerating cycle time, and automating only when necessary.

Musk suggests that if you're not adding requirements back at least 10%-15% of the time, you're not deleting enough initially. The percentage is an estimate initially based on experience, and now for several years based on estimates from manufacturing practice.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by n4r9 on Monday August 26, 2024 @03:54AM (#41354920)

Yeah, not sure how you'd measure this apart from asking people to tag feature re-adds. And all that will happen is that people will decide that something is actually a new feature rather than a re-add because the threshold has already been hit this quarter. Literally adding work for no benefit.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by Jensson on Monday August 26, 2024 @04:22AM (#41355064)

> How would you measure / calculate something like that?

SpaceX probably has stricter processes than your average IT shop, then it isn't hard to calculate stats like that. Then when you have the number, you tune it until you are happy, and now that number is your target. They arrived at 15%. This process is no different than test coverage numbers etc, its just a useful tool not arrogance.

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by lucianbr on Monday August 26, 2024 @07:25AM (#41356107)

I have no clue what you are saying. "They did it somehow"? How? Maybe they did not measure it, but Elon just imagined it. How can we tell the difference?

[ Parent | on HN ]

Re:Removing stuff is never obvious yet often better by adamtaylor_13 on Monday August 26, 2024 @07:07AM (#41356004)

He also made it mandatory that all requirements had to be tied to a name. So there was no question as to why something was there.

[ Parent | on HN ]