6 ms·

I would still argue level three does not exist - future proofing is futile over the short or long term, and only maintainance is the solution. Good article othe

I would still argue level three does not exist - future proofing is futile over the short or long term, and only maintainance is the solution. Good article otherwise though!

hinkley 9y ago
I sincerely believe you can design for maintenance, however. It's the only form of future proofing that seems to work. There are analogs in the mechanical world. Some of the most beloved motorcycles, bikes, cars, boats are easy to work on. Chevy made a straight six that people modified so heavily that people got multiples of the original horsepower out of it. It was simple, sturdy, easy to hang things off of and to modify. The Open-Closed Principle tries to capture that idea in a sentence. But from all appearances the nuances of the concept seem to entirely escape people far too often.
philipov 9y ago
Future proofing is futile, but creating maintainable code should be on the short list of priorities. Unfortunately, it seems that all too often the single-minded desire to ship as quickly as possible overrides any consideration for the future at all.
sirclueless 9y ago
This doesn't really work as a blanket statement. Future proofing and trying to guarantee bug-free code is worth something -- for example if I'm building a space shuttle to go to the moon, I want some degree of certainty that software bugs will not cause that mission to fail, and I might be willing to spend a lot of time and money to ensure that doesn't happen. I think a more accurate statement of this sentiment is that investing time and effort into preventing future bugs and problems stops being worth it after a certain point (and perhaps earlier than many software engineers would think).
- boilerupnc 9y ago
  Interesting read about the level of effort and process invested in the Space Shuttle's software (~1996): https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff. For a TLDR, this answer (https://space.stackexchange.com/questions/9260/how-often-if-ever-was-software-updated-in-the-shuttle-orbiter#answer-9271 https://space.stackexchange.com/questions/9260/how-often-if-...) is great. My favorite excerpt: The Shuttle software consists of ca. 420,000 lines. The total bug count hovers around 1. At one point around 1996, they built 11 versions of the code with a total of 17 bugs.
larschdk 9y ago
Level three definitely exists, and it's useful to be able to talk about levels of correctness. That doesn't mean it's always required to be level 3 correct. That entirely depends on your risk profile. If you're doing a one-off server side maintenance tool, it may be fine. If you're doing flight control software for an airplane, it's not.

I would still argue level three does not exist - future proofing is futile over the short or long term, and only maintainance is the solution. Good article otherwise though!

hinkley 9y ago

I sincerely believe you can design for maintenance, however. It's the only form of future proofing that seems to work. There are analogs in the mechanical world. Some of the most beloved motorcycles, bikes, cars, boats are easy to work on. Chevy made a straight six that people modified so heavily that people got multiples of the original horsepower out of it. It was simple, sturdy, easy to hang things off of and to modify. The Open-Closed Principle tries to capture that idea in a sentence. But from all appearances the nuances of the concept seem to entirely escape people far too often.

philipov 9y ago

Future proofing is futile, but creating maintainable code should be on the short list of priorities. Unfortunately, it seems that all too often the single-minded desire to ship as quickly as possible overrides any consideration for the future at all.

sirclueless 9y ago

This doesn't really work as a blanket statement. Future proofing and trying to guarantee bug-free code is worth something -- for example if I'm building a space shuttle to go to the moon, I want some degree of certainty that software bugs will not cause that mission to fail, and I might be willing to spend a lot of time and money to ensure that doesn't happen. I think a more accurate statement of this sentiment is that investing time and effort into preventing future bugs and problems stops being worth it after a certain point (and perhaps earlier than many software engineers would think).

boilerupnc 9y ago
Interesting read about the level of effort and process invested in the Space Shuttle's software (~1996): https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff. For a TLDR, this answer (https://space.stackexchange.com/questions/9260/how-often-if-ever-was-software-updated-in-the-shuttle-orbiter#answer-9271 https://space.stackexchange.com/questions/9260/how-often-if-...) is great. My favorite excerpt: The Shuttle software consists of ca. 420,000 lines. The total bug count hovers around 1. At one point around 1996, they built 11 versions of the code with a total of 17 bugs.

larschdk 9y ago

Level three definitely exists, and it's useful to be able to talk about levels of correctness. That doesn't mean it's always required to be level 3 correct. That entirely depends on your risk profile. If you're doing a one-off server side maintenance tool, it may be fine. If you're doing flight control software for an airplane, it's not.