2 ms·

>> Software should be designed to last Not necessarily true. If the requirements of the project are to be secure or fast or easy to maintain or built quickly

>> Software should be designed to last Not necessarily true. If the requirements of the project are to be secure or fast or easy to maintain or built quickly or have beautiful user experience or be maintainable or be designed to be robust & failure resistant, then that is what it should be. And if the requirements of the project are "the software must be designed to last", then the software should be designed to be designed to last. But if it's not a requirement, then no, it does not matter if it lasts. The point being that blanket statements about what software should be are missing important context about the purpose of the software and the constraints under which it was developed and the specified requirements.

natalyarostova 6y ago
I’m working on a project/product now with no established value or customer, yet. Imagine if I told sr. Mgmt “no, we still haven’t provided value. But we have ensured the design is robust and will last” lol. I’d be fired so quickly.
mcavoybn 6y ago
Couldn't you have just said "Not all software must be designed to last"? Also, the author said software should be designed to last not that it must. Lastly, you didn't address the core argument of the article which is that you should carefully select and manage dependencies. Reading your comment I wonder if you even read the article..
- andrewstuart 6y ago
  True. somewhat long winded, edited thanks.
nightski 6y ago
The problem is requirements change and often. There is definitely engineering work in making these trade offs, but I generally agree with the op that it's better to err on the side of longevity. It would be interesting to hear of software that served it's purpose well for a year or two and then was no longer needed. I'm sure these projects exist, but I'd imagine they aren't very common given how expensive software development is in the first place.

natalyarostova 6y ago

I’m working on a project/product now with no established value or customer, yet. Imagine if I told sr. Mgmt “no, we still haven’t provided value. But we have ensured the design is robust and will last” lol. I’d be fired so quickly.

mcavoybn 6y ago

Couldn't you have just said "Not all software must be designed to last"? Also, the author said software should be designed to last not that it must. Lastly, you didn't address the core argument of the article which is that you should carefully select and manage dependencies. Reading your comment I wonder if you even read the article..

andrewstuart 6y ago
True. somewhat long winded, edited thanks.

nightski 6y ago

The problem is requirements change and often. There is definitely engineering work in making these trade offs, but I generally agree with the op that it's better to err on the side of longevity. It would be interesting to hear of software that served it's purpose well for a year or two and then was no longer needed. I'm sure these projects exist, but I'd imagine they aren't very common given how expensive software development is in the first place.