2 Fixed spelling/grammar.
source | link

Compliance with an ISO standard is not always a cost-free activity. If a particular standard isn't already implemented in the toolkit she's using, a programmer is faced with a necessary choice: Is it cheaper to properly implement the properlythis now, or not implement the standard and deal with conversions latterlater?

It's easy to say "hey, you should always implement the standard", but everything has a cost. And there are some good reasons why a programmer may not want to implement an ISO standard.

  • The customer may be following a proprietary or non-ISO standard. Better to hew to the standard a customer is expecting than leave unintended headaches for your successor by hiding an additional implementation besides what the customer wants and your language requires.
  • There may be a great deal of existing data, and a conversion or format-break may not yet be feasible. If you have twenty years of customer contacts and contracts keyed with local date-times, you don't necessarily want to change all those hundreds of millions of fields to ISO standard dates until you can do it right.
  • Adherence to the standard may impose a greater cost than the benefit provides. If you're dealing with entries entirely within the United States, for example, the five-character ISO-3166-2 code (US-NY) is three unneeded characters over the standard US postal code (NY).  

Compliance with an ISO standard is not always a cost-free activity. If a particular standard isn't already implemented in the toolkit she's using, a programmer is faced with a necessary choice: Is it cheaper to properly implement the properly now, or not implement the standard and deal with conversions latter?

It's easy to say "hey, you should always implement the standard", but everything has a cost. And there are some good reasons why a programmer may not want to implement an ISO standard.

  • The customer may be following a proprietary or non-ISO standard. Better to hew to the standard a customer is expecting than leave unintended headaches for your successor by hiding an additional implementation besides what the customer wants and your language requires.
  • There may be a great deal of existing data, and a conversion or format-break may not yet be feasible. If you have twenty years of customer contacts and contracts keyed with local date-times, you don't necessarily want to change all those hundreds of millions of fields to ISO standard dates until you can do it right.
  • Adherence to the standard may impose a greater cost than the benefit provides. If you're dealing with entries entirely within the United States, for example, the five-character ISO-3166-2 code (US-NY) is three unneeded characters over the standard US postal code (NY).  

Compliance with an ISO standard is not always a cost-free activity. If a particular standard isn't already implemented in the toolkit she's using, a programmer is faced with a necessary choice: Is it cheaper to properly implement this now, or not implement the standard and deal with conversions later?

It's easy to say "hey, you should always implement the standard", but everything has a cost. And there are some good reasons why a programmer may not want to implement an ISO standard.

  • The customer may be following a proprietary or non-ISO standard. Better to hew to the standard a customer is expecting than leave unintended headaches for your successor by hiding an additional implementation besides what the customer wants and your language requires.
  • There may be a great deal of existing data, and a conversion or format-break may not yet be feasible. If you have twenty years of customer contacts and contracts keyed with local date-times, you don't necessarily want to change all those hundreds of millions of fields to ISO standard dates until you can do it right.
  • Adherence to the standard may impose a greater cost than the benefit provides. If you're dealing with entries entirely within the United States, for example, the five-character ISO-3166-2 code (US-NY) is three unneeded characters over the standard US postal code (NY).
1
source | link

Compliance with an ISO standard is not always a cost-free activity. If a particular standard isn't already implemented in the toolkit she's using, a programmer is faced with a necessary choice: Is it cheaper to properly implement the properly now, or not implement the standard and deal with conversions latter?

It's easy to say "hey, you should always implement the standard", but everything has a cost. And there are some good reasons why a programmer may not want to implement an ISO standard.

  • The customer may be following a proprietary or non-ISO standard. Better to hew to the standard a customer is expecting than leave unintended headaches for your successor by hiding an additional implementation besides what the customer wants and your language requires.
  • There may be a great deal of existing data, and a conversion or format-break may not yet be feasible. If you have twenty years of customer contacts and contracts keyed with local date-times, you don't necessarily want to change all those hundreds of millions of fields to ISO standard dates until you can do it right.
  • Adherence to the standard may impose a greater cost than the benefit provides. If you're dealing with entries entirely within the United States, for example, the five-character ISO-3166-2 code (US-NY) is three unneeded characters over the standard US postal code (NY).