To add context: InSight was proposed to a cost-capped, competitive NASA program. Within competed programs, you can't spend money on nice-to-have's. You have to come in under a cost cap, while demonstrating you will achieve science objectives. Period.

The science objectives are carefully time-bound by a very knowledgeable science team, and from those science requirements, all the engineering requirements, including lifetimes, are derived. InSight didn't need more than one Mars year for the science, so that's that.

There were 2 instruments. In the case of the heat probe, they needed to observe at least one full annual heating cycle. For the seismograph, I think they had an approximate event rate and they needed to capture X number of events of a given magnitude to get insight (heh!) into the subsurface structure.

Here's a description of how this works in general, from someone who was involved in InSight formulation and who is in the leadership of mission formulation at JPL:

https://science.nasa.gov/science-red/s3fs-public/atoms/files...

The whole presentation is great: the first introductory slides, some InSight examples, and the last 3 slides in particular give background on some of my claims above.

The person who (with the PI, Bruce Banerdt) led the InSight "requirements trace" is Peg Frerking (https://scholar.google.com/citations?user=t6XZBAIAAAAJ&hl=en), who is now a JPL fellow in part because of her work in adding engineering rigor to the formulation process.

As this thread shows, it's very easy for clever engineers to add on nice-to-have's that are not required to meet science objectives. That's how you get overruns.

Here's another recent HN reference point on capabilities that don't contribute to a great product: https://news.ycombinator.com/item?id=34032672 [Steve Jobs Insult Response]