3 ms·

Number 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. Isn't that the mar

Number 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. Isn't that the margin for error? I want to go up in a ship that's a little better than the absolute minimum.

rahimnathwani 3y ago
Then specify that in the requirements.
imoreno 3y ago
Margin of error should be calculated at the design stage, not as an afterthought during implementation.
dylan604 3y ago
>There's no justification for designing something one bit "better" than the requirements dictate. Are the Martian rovers outliers to this rule? >I want to go up in a ship that's a little better than the absolute minimum. This makes me think of the "this was built by the lowest bidding contractor" quote
- dclowd9901 3y ago
  The rovers likely are completely on spec but simply because of all of their redundancies and tolerances designed as they are, they exceeded on-paper minimum expectations.
  - dylan604 3y ago
    at this point though, if I was on a team that made a $newShinyToy for a space mission that did not "over perform" like this, I would personally feel shame and have a sense of failure if it only performed to the papers and end of mission came exactly when the paper said.
    - tonyarkles 3y ago
      I wouldn’t go quite that far. Generally speaking aerospace margins are there for two reasons: - To try to compensate for the worst-case situations - To try to compensate for the unknown-unknowns If you made a Mars rover that experienced a worst-case re-entry burn, got blown off-course during landing by larger-than-ever-measured surface winds, had your solar panel etched by dust in said surface winds, and completed 89 of the 90 day mission, you should still very much feel like you’ve succeeded AND you’ve provided incredibly valuable input data for the next iteration. We then refine our mental model of the Martian atmospheric conditions and revise the worst-case scenario specs for next time.
  - beckingz 3y ago
    The specs were decreased so that "success" was extremely likely, because failure is career ending.
whats_a_quasar 3y ago
This is the only one I have reservations about. It is also part of the engineer's job to understand the customer, understand what they need, and negotiate the requirements (within reason). It's hard (impossible?) for the customer to fully design exactly what they need, and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet
- firewolf34 3y ago
  You're describing the (albeit quite common) situation where requirements were not conclusive enough and need to be revised throughout lifetime of development, which can be natural as you begin to understand the problem space as you work within it. But the key is that the requirements should be as conclusive and accurate to resolving your problem as they possibly can be, at any given point in time. In the "frictionless environment, ideal world" scenario - requirements should always be completed as close to the letter as possible and no further. In the practical scenario, requirements should be written as close to perfect as can be achieved where perfect is defined as what is necessary to resolve your problem space, limited by your understanding of the problem space.
  - beckingz 3y ago
    Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements. Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.
    - tonyarkles 3y ago
      I agree completely. In the physical goods world, though, it’s not a continuous function. At points along the way, there is a very clear cost step response. Requirements evolving is totally fine and expected, but you need to periodically say “The current set is good enough, let’s build it and ship it”. Trying to do continuous delivery on manufactured items is the road to madness. My general approach to this is to try to reasonably anticipate things that could be coming down the pipe and, if possible, do the bare minimum to cheaply support the next prototype. As an example, if the product has a GPS receiver and a microcontroller and could conceivably need to do dual-receiver down the road, I’ll have a quick look for spare Tx/Rx pins on the microcontroller and just route those out to blank pads. Two benefits: - when product management asks, we have a way to build a prototype using existing parts - if there aren’t any spare pins to break out like that, I can raise it as a potential design red flag early. It’s not necessarily a show stopper, but it contributes situational awareness for when the next big step cost might show up down the road.
firewolf34 3y ago
Requirements set constraints which guide the development process. Without them set early on, you risk not understanding completely what you're setting out to do, you risk differing expectations/assumptions between members of your team, and you risk creep as the project goes on which means you will diverge from your intended outcome. In any project, resources (time, money, etc) are limited so the most successful project will be one that uses resources most efficiently. So good explicit requirements allow you to determine the most efficient manner to achieve them as they codeify the problem and give you goalposts to optimize within. This all relies on you being able to set good requirements from the outset, which can be done by understanding what you're setting out to achieve (the problem you're trying to solve). I have a comment in this thread which discusses the consequences of this rule specifically. https://news.ycombinator.com/item?id=37069168 https://news.ycombinator.com/item?id=37069168
johnwalkr 3y ago
Good requirements include margins. In aerospace it's common to see[1] a system requirement that says "...shall supply a peak current of 1.0A for 1.0s", a general requirement somewhere else that says "...power supplies used for the purpose of X shall be designed to a margin of 1.5 for current and a margin of 2.0 for time", and a child of both that says "...shall supply a peak current of 1.5A for 2.0s, including margins". That being said, I work in aerospace and if a company aims to meet the above requirements but maximimize or minimize some aspect, e.g. make a light/cheap/competitive product, how do you do that? There's always a few engineers that will die on the hill of "but there is no requirement for mass of this particular component" or "you said I should minimize mass but that's not a real requirement" (many organizations reject anything but "shall requirements" when it comes to formal review). TBC or TBD values can be used, but then it's difficult for everyone to understand if the value is a target or just something to be updated later. On the other hand, there's always a few engineers who will happily work for an extra year to optimize something way too much. Sometimes a requirement is flat-out incompatible with another requirement, too. Requirements are so important but they are just a tool, and also sometimes require iteration. Number 38 goes in the right direction, but I would personally want to add "46. Sometimes requirements are wrong". [1] These are simplified examples
- elteto 3y ago
  A 1.5 factor of safety in aerospace? Outrageous. I’ll give you 1.1 and I’m being generous! I’m kidding…

rahimnathwani 3y ago

Then specify that in the requirements.

imoreno 3y ago

Margin of error should be calculated at the design stage, not as an afterthought during implementation.

dylan604 3y ago

>There's no justification for designing something one bit "better" than the requirements dictate. Are the Martian rovers outliers to this rule? >I want to go up in a ship that's a little better than the absolute minimum. This makes me think of the "this was built by the lowest bidding contractor" quote

dclowd9901 3y ago
The rovers likely are completely on spec but simply because of all of their redundancies and tolerances designed as they are, they exceeded on-paper minimum expectations.
- dylan604 3y ago
  at this point though, if I was on a team that made a $newShinyToy for a space mission that did not "over perform" like this, I would personally feel shame and have a sense of failure if it only performed to the papers and end of mission came exactly when the paper said.
  - tonyarkles 3y ago
    I wouldn’t go quite that far. Generally speaking aerospace margins are there for two reasons: - To try to compensate for the worst-case situations - To try to compensate for the unknown-unknowns If you made a Mars rover that experienced a worst-case re-entry burn, got blown off-course during landing by larger-than-ever-measured surface winds, had your solar panel etched by dust in said surface winds, and completed 89 of the 90 day mission, you should still very much feel like you’ve succeeded AND you’ve provided incredibly valuable input data for the next iteration. We then refine our mental model of the Martian atmospheric conditions and revise the worst-case scenario specs for next time.
- beckingz 3y ago
  The specs were decreased so that "success" was extremely likely, because failure is career ending.

whats_a_quasar 3y ago

This is the only one I have reservations about. It is also part of the engineer's job to understand the customer, understand what they need, and negotiate the requirements (within reason). It's hard (impossible?) for the customer to fully design exactly what they need, and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet

firewolf34 3y ago
You're describing the (albeit quite common) situation where requirements were not conclusive enough and need to be revised throughout lifetime of development, which can be natural as you begin to understand the problem space as you work within it. But the key is that the requirements should be as conclusive and accurate to resolving your problem as they possibly can be, at any given point in time. In the "frictionless environment, ideal world" scenario - requirements should always be completed as close to the letter as possible and no further. In the practical scenario, requirements should be written as close to perfect as can be achieved where perfect is defined as what is necessary to resolve your problem space, limited by your understanding of the problem space.
- beckingz 3y ago
  Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements. Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.
  - tonyarkles 3y ago
    I agree completely. In the physical goods world, though, it’s not a continuous function. At points along the way, there is a very clear cost step response. Requirements evolving is totally fine and expected, but you need to periodically say “The current set is good enough, let’s build it and ship it”. Trying to do continuous delivery on manufactured items is the road to madness. My general approach to this is to try to reasonably anticipate things that could be coming down the pipe and, if possible, do the bare minimum to cheaply support the next prototype. As an example, if the product has a GPS receiver and a microcontroller and could conceivably need to do dual-receiver down the road, I’ll have a quick look for spare Tx/Rx pins on the microcontroller and just route those out to blank pads. Two benefits: - when product management asks, we have a way to build a prototype using existing parts - if there aren’t any spare pins to break out like that, I can raise it as a potential design red flag early. It’s not necessarily a show stopper, but it contributes situational awareness for when the next big step cost might show up down the road.

firewolf34 3y ago

Requirements set constraints which guide the development process. Without them set early on, you risk not understanding completely what you're setting out to do, you risk differing expectations/assumptions between members of your team, and you risk creep as the project goes on which means you will diverge from your intended outcome. In any project, resources (time, money, etc) are limited so the most successful project will be one that uses resources most efficiently. So good explicit requirements allow you to determine the most efficient manner to achieve them as they codeify the problem and give you goalposts to optimize within. This all relies on you being able to set good requirements from the outset, which can be done by understanding what you're setting out to achieve (the problem you're trying to solve). I have a comment in this thread which discusses the consequences of this rule specifically. https://news.ycombinator.com/item?id=37069168 https://news.ycombinator.com/item?id=37069168

johnwalkr 3y ago

Good requirements include margins. In aerospace it's common to see[1] a system requirement that says "...shall supply a peak current of 1.0A for 1.0s", a general requirement somewhere else that says "...power supplies used for the purpose of X shall be designed to a margin of 1.5 for current and a margin of 2.0 for time", and a child of both that says "...shall supply a peak current of 1.5A for 2.0s, including margins". That being said, I work in aerospace and if a company aims to meet the above requirements but maximimize or minimize some aspect, e.g. make a light/cheap/competitive product, how do you do that? There's always a few engineers that will die on the hill of "but there is no requirement for mass of this particular component" or "you said I should minimize mass but that's not a real requirement" (many organizations reject anything but "shall requirements" when it comes to formal review). TBC or TBD values can be used, but then it's difficult for everyone to understand if the value is a target or just something to be updated later. On the other hand, there's always a few engineers who will happily work for an extra year to optimize something way too much. Sometimes a requirement is flat-out incompatible with another requirement, too. Requirements are so important but they are just a tool, and also sometimes require iteration. Number 38 goes in the right direction, but I would personally want to add "46. Sometimes requirements are wrong". [1] These are simplified examples

elteto 3y ago
A 1.5 factor of safety in aerospace? Outrageous. I’ll give you 1.1 and I’m being generous! I’m kidding…