[JoeAltmaier]

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.

[johnwalkr]

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]

A 1.5 factor of safety in aerospace? Outrageous. I’ll give you 1.1 and I’m being generous!

I’m kidding…

[rahimnathwani]

Then specify that in the requirements.

[firewolf34]

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

[imoreno]

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

[whats_a_quasar]

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

[c_o_n_v_e_x]

>and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet

Continuous input is a tried and true method of blowing out both budgets and timelines on building anything physical.. hardware, rockets, chemical plants, etc.

[tonyarkles]

Working at a hardware company with a software company founder (which I’ve done multiple times now) can be a frustrating experience. People used to being able to casually say “hey I want to add this new feature” and getting “$40,000 and 12-week shipping delay” as a response are generally not happy. One project I worked on shipped board v2.17; the requirements were changing so quickly that we often needed to do significant board redesigns before we’d even sent the current design to the prototyping shop. It was… fun.

[firewolf34]

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]

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]

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]

I love when you guys do that. Then when I'm hacking around w/ your machine, I can get ahold of those spare pads :)

[dylan604]

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

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.

[beckingz]

The specs were decreased so that "success" was extremely likely, because failure is career ending.

[dylan604]

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]

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.