Episode 6 — Longevity

This week we talk to Ian Dees, software engineer at Tektronix focused on mid level software and ways to improve the longevity of electronics that use software over time.

  • Jeff recently visited the Indianapolis Motor Speedway.
  • Ian focuses mainly on C and C++ but also moves into higher level languages and other aspects of product design while working on oscilloscopes.
  • What makes things sustainable 10 years down the road?
  • Architectural changes (that’s “refactoring”, not “rewriting”) can really help short term changes.
  • Planning schedules can end up affecting longevity. However, making software (or hardware) too extensible can create paralysis analysis.
  • Software designers often have to deal with the evolution of languages as well, vs having similar concepts in electrical engineering and mechanical engineering over the years.
  • Reliability and longevity are the same thing over time.
  • Chris likes working on redesigns in order to learn about what not to do and how to design for the long term.
  • Jeff felt drawn towards different bits of software that would “solve problems” when in fact they’ll only solve one aspect and then create new ones.
  • Ian now works with a marketing person who doesn’t just wave off the difficulty of a task; there is trust between engineering and marketing to help get a better grasp on schedule estimation.
  • What would happen if engineers-in-training were subjected to a pile of code with no tests?
  • Jeff learned hands on with drilling and tapping threads into old mills and learning the warts in a realistic product.
  • Expected lifetime can also affect the longevity of a product. Should there be a planned obsolescence or maintenance schedule?
  • In electronics, the Arrhenius Equation helps estimate how long something will last.
  • Complexity of a product (hw or sw) and the quality of the materials can all end up affecting the longevity of a product.
  • Computer systems and engineering tools can end up affecting every engineer…because you might need to pull up your design after many years.
  • Saving designs over years could have other problems. Perhaps we should follow the advice in this article, The Revolution Should Not Be Digitized.
  • Ian likes the idea of a Software Will, where you keep a running list of things you designed and might need to be passed along.

Thanks again to Ian for being on The Engineering Commons this week. To catch each update as soon as it’s posted, be sure to subscribe to the feed!

Thanks to Chris Daniel for the picture of the old circuit board!

2 thoughts on “Episode 6 — Longevity”

  1. On the value of reviewing previous work in engineering studies… I really enjoyed the comments by Jeff about getting his hands dirty in the machine shop as a summer engineering intern. I fully agree that this is a great way to learn the practicalities of engineering. I spent much of my high school (and some of my college years) working in a TV repair shop. Troubleshooting, repair, etc. is a great way to learn about what works, an what happens when it breaks, and how to figure out how “prior art” was designed and how it works.

    On the other hand, I once read that when you begin a new design, if you review how it was done by others in the past that you will instantly reduce the amount of creativity and innovation that you might include in your new design, so it might not be a good idea. So, in the end, it’s best to build upon and rely on your depth of knowledge of the fundamentals and practical considerations, rather than study specific prior art when approaching a new design.

  2. Great show – very much enjoyed the discussion – especially about the commonalities and differences among the different fields of engineering.

Comments are closed.