4 ms·

Why would a coder ever be held responsible for something not specified in the requirements doc? If people wanted Y2K compliant software in the 70s and 80s they

by fleitz 15y ago

Why would a coder ever be held responsible for something not specified in the requirements doc? If people wanted Y2K compliant software in the 70s and 80s they should have specified it. As for multibillion dollar valuations, what's wrong with the valuations on MSFT, AAPL, GOOG? If you think the PE is crazy on LNKD, just short it. As for what VCs are willing to invest for particular companies those investments are more anecdotes than data.

willyt 15y ago
Because it's not unreasonable to expect the coder to supply you with something which will not fail arbitrarily in 10 years for a reason which is 100% predictable. A parallel example: If an Architect designs you a building which develops a leak because of a mistake in a construction detail you would sue for the cost of repairs and damage to property. Either in contract if available or in Tort for negligence if no contract exists.
- BoppreH 15y ago
  Buildings are expected to last, and cutting corners (on multi decade support, for example) is not exactly a "mistake" like the one that would spring a leak. Aside from that, where do you draw the line? If the software doesn't work with accented characters and it wasn't in the specs, do you blame the coder? Reading that common-but-not-currently-used-here file type? IPv6 support? Maybe it's because I'm a coder, but if you want a building to withstand an earthquake, you gotta say so.
  - joev 15y ago
    Buildings also need to be maintained and retrofitted. Around here in Cambridge, there are countless residential and commercial buildings that were built before the days of electricity and air conditioning, and even plumbing in some cases. The maintenance costs often far outweigh the initial building costs, even given inflation.
- billswift 15y ago
  >Because it's not unreasonable to expect the coder to supply you with something which will not fail arbitrarily in 10 years for a reason which is 100% predictable. Really. A coder is supposed to know that he should spend unnecessary resources (memory, mainly) to add a feature that will be needed in ten years for a program only expected to be used for five years? Most of the problems (that didn't happen is it turned out) with Y2K were because many programs that were expected to be replaced weren't. And before the mid 1990s RAM was seriously expensive, people did not buy more than necessary, "Just in Case".
- fleitz 15y ago
  Defects that are 100% predictable do not fail arbitrarily, they fail predictably. I suppose you've never used a fixed size data type (eg. int) as a primary key right?
deleted 15y ago
[deleted]

by fleitz 15y ago

willyt 15y ago

Because it's not unreasonable to expect the coder to supply you with something which will not fail arbitrarily in 10 years for a reason which is 100% predictable. A parallel example: If an Architect designs you a building which develops a leak because of a mistake in a construction detail you would sue for the cost of repairs and damage to property. Either in contract if available or in Tort for negligence if no contract exists.

BoppreH 15y ago
Buildings are expected to last, and cutting corners (on multi decade support, for example) is not exactly a "mistake" like the one that would spring a leak. Aside from that, where do you draw the line? If the software doesn't work with accented characters and it wasn't in the specs, do you blame the coder? Reading that common-but-not-currently-used-here file type? IPv6 support? Maybe it's because I'm a coder, but if you want a building to withstand an earthquake, you gotta say so.
- joev 15y ago
  Buildings also need to be maintained and retrofitted. Around here in Cambridge, there are countless residential and commercial buildings that were built before the days of electricity and air conditioning, and even plumbing in some cases. The maintenance costs often far outweigh the initial building costs, even given inflation.
billswift 15y ago
>Because it's not unreasonable to expect the coder to supply you with something which will not fail arbitrarily in 10 years for a reason which is 100% predictable. Really. A coder is supposed to know that he should spend unnecessary resources (memory, mainly) to add a feature that will be needed in ten years for a program only expected to be used for five years? Most of the problems (that didn't happen is it turned out) with Y2K were because many programs that were expected to be replaced weren't. And before the mid 1990s RAM was seriously expensive, people did not buy more than necessary, "Just in Case".
fleitz 15y ago
Defects that are 100% predictable do not fail arbitrarily, they fail predictably. I suppose you've never used a fixed size data type (eg. int) as a primary key right?

deleted 15y ago

[deleted]