ทำไมโปรแกรมเมอร์จึงไม่สนใจมาตรฐาน ISO? [ปิด]

สิ่งหนึ่งที่ฉันพบบ่อยคือปัญหาที่เกิดจากโปรแกรมที่ไม่เป็นไปตามมาตรฐาน ISO

ตัวอย่างหนึ่งจะไม่ใช้ตารางประเทศ ISO แต่ทำชวเลขของพวกเขาเองซึ่งก็โอเคสำหรับสหรัฐอเมริกา (US) หรือเนเธอร์แลนด์ (NL) แต่ผิดไปอย่างน่าทึ่งสำหรับสหราชอาณาจักร (GB ไม่ใช่สหราชอาณาจักร) หรือสเปน (ES ไม่ใช่ SP) และประเทศอื่น ๆ อีกมากมาย

เป็นอีกตัวอย่างหนึ่งที่ระบุวันที่ภายใน ทำไมทุกคนจะเก็บวันที่ในวันที่ 01/02/2014? ยังไม่ชัดเจนว่าจะเป็นวันที่ 1 กุมภาพันธ์หรือ 2 มกราคมในขณะที่ถ้าคุณใช้มาตรฐาน ISO คุณเพิ่งเก็บ 2014-02-01 * และมันก็ชัดเจนวันที่ 1 กุมภาพันธ์

คำถามของฉัน: โปรแกรมเมอร์ควรสร้างโครงสร้างของตนเองเมื่อใดและเพราะเหตุใดเมื่อมีมาตรฐาน ISO พร้อมใช้งาน

_{* จัดเก็บ 2014-02-01 และจัดรูปแบบวันที่ตามลำดับเมื่อแสดงให้ผู้ใช้ปลายทางเห็น}

อย่ากล่าวถึงความอาฆาตพยาบาทซึ่งอธิบายโดยความโง่เขลาอย่างเพียงพอ - โรเบิร์ตเจ Hanlon

นั่นและขาดการสื่อสาร

ดังนั้นมันไม่ใช่การสมรู้ร่วมคิดในการต่อต้านความรู้สึกต่อต้าน ISO ทำให้ผู้คนคิดว่า "ฉันรู้ว่าฉันจะใช้สหราชอาณาจักรแทน GB" และไม่ใช่ความชอบที่ "พวกเขารู้ดีกว่า" หรือแม้แต่ความรู้สึกว่ามาตรฐานไม่ดี . มันอาจจะเป็นเพราะพวกเขาไม่รู้ว่าอยู่ที่นั่นและควรใช้มัน

ฉันหมายถึงสำหรับบางคนถ้ามันไม่ได้รวมอยู่ในVisual Studioมันก็อาจจะไม่มีอยู่จริง สำหรับคนอื่น ๆ บางทีพวกเขาอาจไม่ต้องการชุดเต็มหรือยากเกินไปที่จะดึงรายชื่อที่ชัดเจนดังนั้นพวกเขาจึงสร้างชุดย่อยของตนเองขึ้นมาเพื่อแก้ไขสถานการณ์ทันที สำหรับคนอื่น ๆ ค่าเริ่มต้นคือสิ่งที่ถูกนำมาใช้ดังนั้นการจัดรูปแบบวันที่จะไม่ "จัดรูปแบบใน ISO หรือแม้แต่ประเทศสถานที่ตั้ง" มันคือ "การจัดรูปแบบในสิ่งที่ออกมา" และหากเหมาะสมกับพวกเขา คำวิจารณ์ของโปรแกรมเมอร์ชาวอเมริกัน)

เมื่อฉันเขียนโปรแกรมใน Ruby ฉันมักจะมองข้ามมาตรฐาน ISO Ruby เสมอ ทำไม? เพราะมันมีข้อ จำกัด อย่างไม่น่าเชื่อ! ISO Ruby เป็นเซตย่อยขั้นต่ำของการแยกของ Ruby 1.8 และ Ruby 1.9 Ruby เวอร์ชันปัจจุบันซึ่งรองรับโดยการใช้งาน Ruby ทั้งหมด (หรืออย่างน้อยจะเร็ว ๆ นี้) คือ Ruby 2.1 และมีคุณสมบัติมากมายที่ทำให้การเขียนโปรแกรมง่ายขึ้น การเขียนโปรแกรมใน ISO Ruby เป็น PITA

เมื่อฉันเขียนโปรแกรมใน C # ฉันก็ไม่สนใจ ISO C # ซึ่งเป็นส่วนย่อยของ C # 2.0 (และที่สำคัญกว่านั้น ISO Class Library เป็นส่วนย่อยที่เล็กมากของ. NET BCL) และฉันแทนโปรแกรมใน C # 5.0 และฉันไม่ ไม่ จำกัด ตัวเองให้ใช้เฉพาะไลบรารีที่ระบุใน ISO CLI แต่ฉันใช้ชุดย่อยทั่วไปของไลบรารีที่มีอยู่ใน. NET 4.5.2 และ Mono 3.4.0

และเมื่อทำการออกแบบเว็บไซต์ฉันชอบใช้ HTML5 มากกว่า ISO HTML (ซึ่งเป็นชุดย่อยขนาดเล็กของ HTML 4.01 Strict) อีกครั้งเนื่องจาก HTML5 นั้นมีคุณลักษณะที่หลากหลายมากกว่าชุดย่อยที่ จำกัด ของ HTML รุ่นโบราณ

ดังนั้นมีเหตุผลที่ดีสำหรับการเพิกเฉยต่อมาตรฐาน ISO

ตามตัวอย่างของคุณ "GB" คือรหัสประเทศสำหรับสหราชอาณาจักร อย่างไรก็ตาม "สหราชอาณาจักร" เป็นครั้งเดียวในรหัสมาตรฐาน MARC (US Library of Congress) ถึงแม้ว่าฉันเชื่อว่ามันเลิกใช้แล้ว และ IANA ใช้.ukสำหรับโดเมนระดับบนสุดสำหรับสหราชอาณาจักร

ดังนั้นหากบางสิ่งไม่สอดคล้องกับมาตรฐาน ISO ก็ไม่ได้หมายความว่าไม่มีการใช้มาตรฐาน อาจหมายถึงว่ามีการใช้มาตรฐานที่ต่างออกไป ( ณ @ Jörgข้อสังเกตในการแสดงความคิดเห็นเป็นสิ่งที่ดีเกี่ยวกับมาตรฐานก็คือว่ามีมากมายให้เลือกจาก.) ซึ่งในกรณีคำถามจริงๆกลายเป็นที่มาตรฐานจะเหมาะสมที่สุดสำหรับโดเมนปัญหาที่กำหนดสภาพแวดล้อม ฯลฯ ?

การตอบคำถามนั้นน่าจะเป็นไปตามความคิดเห็นเป็นส่วนใหญ่และเสื่อมถอยลงอย่างรวดเร็วในการอภิปราย "ทางศาสนา" แต่การปฏิบัติตามมาตรฐาน ISO ไม่จำเป็นต้องเป็นคำตอบที่ดีที่สุดเสมอไป ตัวอย่างเช่นหากชิ้นส่วนของซอฟต์แวร์ต้องเชื่อมต่อกับฐานข้อมูลไลบรารีมาตรฐาน MARC อาจเป็นตัวเลือกที่เหมาะสมกว่า ISO หากซอฟต์แวร์ส่วนใหญ่ในองค์กรของคุณทำสิ่งใดอย่างหนึ่งคุณอาจต้องการใช้แนวทางดังกล่าวอย่างน้อยก็ในระยะสั้น - นั่นคือ "มาตรฐาน" ขององค์กรของคุณ

นอกจากนี้มาตรฐานยังพัฒนา / เปลี่ยนแปลง สิ่งที่สอดคล้องเมื่อวานนี้อาจไม่เป็นวันนี้

และในขณะที่ฉันไม่ต้องการแยกแยะความไม่รู้และ / หรือความเฉื่อยชาเนื่องจากสาเหตุของปัญหาที่คุณชี้ให้เห็น ... นักพัฒนาอาจไม่มีเวลาพอที่จะแก้ไขปัญหาเหล่านั้น

การปฏิบัติตามมาตรฐาน ISO ไม่ได้เป็นกิจกรรมที่ไม่มีค่าใช้จ่ายเสมอไป หากมาตรฐานเฉพาะไม่ได้นำมาใช้ในชุดเครื่องมือที่เธอใช้อยู่โปรแกรมเมอร์กำลังเผชิญกับตัวเลือกที่จำเป็น: ถูกกว่าหรือไม่ที่จะใช้งานอย่างถูกต้องในตอนนี้หรือไม่ใช้มาตรฐานและจัดการกับการแปลงในภายหลัง

มันง่ายที่จะพูดว่า "เฮ้คุณควรใช้มาตรฐาน" แต่ทุกอย่างมีค่าใช้จ่าย และมีเหตุผลที่ดีที่โปรแกรมเมอร์อาจไม่ต้องการนำมาตรฐาน ISO มาใช้

• ลูกค้าอาจปฏิบัติตามมาตรฐานที่เป็นกรรมสิทธิ์หรือไม่ใช่ ISO ดีกว่าที่จะใส่ใจกับมาตรฐานที่ลูกค้าคาดหวังกว่าปล่อยให้ปวดหัวโดยไม่ตั้งใจสำหรับผู้สืบทอดโดยซ่อนการใช้งานเพิ่มเติมนอกเหนือจากสิ่งที่ลูกค้าต้องการและภาษาของคุณต้องการ
• อาจมีข้อมูลที่มีอยู่จำนวนมากและการแปลงหรือการแบ่งรูปแบบอาจยังไม่สามารถทำได้ หากคุณมีผู้ติดต่อลูกค้าและสัญญาที่มียี่สิบปีที่มีวันที่ท้องถิ่นคุณไม่จำเป็นต้องเปลี่ยนเขตข้อมูลนับร้อยล้านทั้งหมดเหล่านี้เป็นวันที่มาตรฐาน ISO จนกว่าคุณจะสามารถทำมันได้
• การยึดมั่นในมาตรฐานอาจกำหนดต้นทุนที่สูงกว่าผลประโยชน์ที่มอบให้ หากคุณกำลังจัดการกับรายการทั้งหมดภายในสหรัฐอเมริกาตัวอย่างเช่นรหัสห้าตัวอักษร ISO-3166-2 (US-NY) คืออักขระที่ไม่จำเป็นสามตัวในรหัสไปรษณีย์มาตรฐานสหรัฐอเมริกา (NY)

ในกรณีของโปรแกรมเมอร์ / นักออกแบบฐานข้อมูลที่ไม่มีประสบการณ์ก็เป็นเพราะไม่รู้ พวกเขามีแนวโน้มที่จะบูรณาการล้อเพราะพวกเขาไม่รู้จักกลุ่มคนที่ทอดอุตสาหกรรมพูดคุยปัญหาและเกิดขึ้นกับมาตรฐานที่ได้รับการอนุมัติจากทุกคนที่เข้าร่วมบ่อยครั้งหลังจากการสนทนานานมากแก้ไข ฯลฯ เมื่อเร็ว ๆ นี้เพื่อนร่วมงาน ของฉันแสดงให้เห็นอย่างไม่น่าเชื่อเมื่อฉันบอกเขาว่ามีมาตรฐาน ISO เกี่ยวกับว่าสัปดาห์ที่กำหนดถือว่าเป็นสัปดาห์สุดท้ายของปีหรือหนึ่งปีแรกของปีถัดไป ( ISO 8601 ) เขาไม่เชื่อว่ามีมาตรฐานเกี่ยวกับบางสิ่งที่เฉพาะเจาะจง ฉันบอกเขาว่าความถูกต้องของแอพพลิเคชั่นมากมายนั้นขึ้นอยู่กับมาตรฐานนั้น

ในกรณีของโปรแกรมเมอร์ / นักออกแบบฐานข้อมูลที่มีประสบการณ์มันไม่สนใจที่เกิดจาก"รู้ดีกว่า"กลุ่มอาการที่ไม่ได้คิดค้นขึ้นที่นี่และ / หรือความโอ่อ่า พวกเขาไม่เชื่อถือ ISO หรือหน่วยมาตรฐานอื่น ๆ เพราะพวกเขาคิดว่ารหัส ISO นั้น"ไม่เสถียรพอ"หมายความว่ามันจะเปลี่ยนสักวัน ดังนั้นพวกเขาจึงสร้างรหัส / ตัวระบุที่คิดค้นขึ้นเองหรือที่เพิ่มขึ้นโดยอัตโนมัติเพื่อขัดขวางการทำงานร่วมกันซึ่งพวกเขาไม่สนใจเช่นกัน ดูคำถามที่คล้ายกันนี้การออกแบบฐานข้อมูลถึงแม้ว่าจะเอียง พวกเขาให้เหตุผลเช่น:

ฉันอาจไม่ต้องการให้การออกแบบฐานข้อมูลของฉันขึ้นอยู่กับกลุ่มบุคคลที่สาม (IATA, ISO) โดยไม่คำนึงว่ามาตรฐานของพวกเขาจะเสถียรแค่ไหน หรือฉันอาจไม่ต้องการพึ่งมาตรฐานใด ๆ เลย

ผู้ที่ไม่สนใจมาตรฐานก็ใช้พอร์ต USB มาตรฐานซื้อดีวีดีและ BluRays ขนาดมาตรฐานแล้วขับรถยนต์ด้วยยางที่ได้มาตรฐาน

คนมักจะเพิกเฉยต่อมาตรฐาน ISO: ตัวอย่างเช่นคุณเขียน

ถ้าคุณใช้มาตรฐาน ISO คุณเพียงแค่เก็บ 20140201 * และมันก็ชัดเจนวันที่ 1 กุมภาพันธ์

แต่การกระทำอย่างเต็มที่ ISO8601 ที่สอดคล้องกับความเป็นจริง2014/02/01 (ดูxkcd 1179 ด้วย )

เหตุผลหนึ่งคือโดเมนแอปพลิเคชันและผู้ใช้อาจไม่ใช้มาตรฐานเหล่านี้ด้วยตนเอง แม้ว่าบางโดเมนจะใช้มาตรฐานบางอย่าง แต่บางโดเมนก็อาจมีทางเลือกที่แตกต่างจากมาตรฐาน ISO บ่อยครั้งด้วยเหตุผลทางประวัติศาสตร์

หากผู้ใช้ของคุณใช้ "สหราชอาณาจักร" ในขั้นตอนที่มีอยู่แล้ว⁽¹⁾เพื่ออ้างถึง "สหราชอาณาจักรบริเตนใหญ่และไอร์แลนด์เหนือ" ไม่จำเป็นต้องใช้ "GB" ในโครงสร้างข้อมูลของพวกเขา (โดยเฉพาะอย่างยิ่งถ้าคุณต้องการ ค่าเฉลี่ยของประเทศนั้นไม่ใช่ประเทศที่ "ISO" เช่นการแยกประเทศสหราชอาณาจักรหรือมีความแตกต่างเล็กน้อยกับหมู่เกาะแชนเนลและอื่น ๆ ) แน่นอนคุณอาจมีการแมประหว่างการนำเสนอที่เก็บข้อมูลภายใน แต่บางครั้งมันก็ค่อนข้างจะอยู่ด้านบน คุณไม่ค่อยเขียนโปรแกรมเพื่อประโยชน์ของการเขียนโปรแกรมคุณมักจะต้องปรับตัวเข้ากับสภาพแวดล้อมของคุณ ⁽²⁾

คุณต้องจำไว้ว่ามาตรฐานเหล่านี้มีการพัฒนาควบคู่ไปกับซอฟต์แวร์ บ่อยครั้งที่คุณต้องพัฒนาภายใต้บริบทของซอฟต์แวร์ชิ้นอื่น ๆ ซึ่งบางอันอาจได้รับการออกแบบอย่างไม่สมบูรณ์ซึ่งบางอันอาจยังได้รับผลกระทบจากการตัดสินใจแบบดั้งเดิม

แม้ว่าคุณจะดูรูปแบบการจัดเก็บข้อมูลภายในความกำกวมบางอย่างยากที่จะแก้ไข ตัวอย่างเช่นเท่าที่ฉันรู้ Excel ใช้ตัวเลขทศนิยมเพื่อเป็นตัวแทนของการประทับเวลา: มันใช้จำนวนเต็มเป็นจำนวนวันนับตั้งแต่วันที่อ้างอิงแล้วสิ่งที่หลังจากทศนิยมแสดงเศษส่วนของ 24 ชั่วโมงเพื่อให้คุณชั่วโมง .. ปัญหาคือสิ่งนี้จะป้องกันไม่ให้คุณคำนึงถึงเขตเวลาของบัญชีหรือการปรับเวลาตามฤดูกาล (23h หรือ 25h ในหนึ่งวัน) และ Excel จะแปลงวันที่ / เวลาให้เป็นรูปแบบภายในตามค่าเริ่มต้น ไม่ว่าคุณต้องการใช้รูปแบบ ISO หรือไม่กลายเป็นสิ่งที่ไม่เกี่ยวข้องหากซอฟต์แวร์ชิ้นอื่นที่คุณต้องทำงานด้วยไม่ทำให้คุณต้องเลือก

_{(1) ฉันไม่ได้หมายถึง "ขั้นตอนการเขียนโปรแกรม" ที่นี่}

_{(2) อย่าถามฉันว่าทำไมคนไม่ใช้มาตรฐานเหล่านั้นในชีวิตประจำวันของพวกเขาด้วย ฉันหมายถึง YYYYmmdd นั้นชัดเจน dd / mm / YYYY นั้นชัดเจน แต่การสั่งซื้อวันที่ด้วยคำสั่งขนาดกลางขนาดเล็กและใหญ่อย่างละเอียดเช่น mm / dd / YYYY ที่ไม่สมเหตุสมผล :-)}

ทำไมฉันจะไม่ใช้มาตรฐาน ISO 3166-1 alpha-2รหัสประเทศ?

เพราะฉันใช้รหัสประเทศSTANAG 1059 ... และในสหราชอาณาจักรนั้นเป็นรหัสสำหรับสหราชอาณาจักร (แทน GB ตามมาตรฐาน ISO 3166-1)

อีกทางหนึ่งฉันสามารถใช้รหัสประเทศของFIPS - อีกครั้งสหราชอาณาจักรเป็นรหัสประเทศของสหราชอาณาจักร

มีหลายมาตรฐาน (ISO และไม่ใช่ ISO) และบางครั้งโดเมนใช้เฉพาะ / ต้องการมาตรฐานที่เข้ากันไม่ได้กับมาตรฐาน ISO

การจัดเก็บ 20140201 นั้นไม่ได้คลุมเครือเลย เฉพาะเมื่อคุณรวมความรู้ที่เป็นไปตามมาตรฐาน ISO เท่านั้นมันจะไม่มีความชัดเจน สิ่งเดียวกันนี้จะทำในวันที่ 01/02/2014: เมื่อคุณรวมความรู้ว่ารูปแบบคือ mm / dd / yyyy มันก็ไม่มีความชัดเจนอย่างสมบูรณ์แบบ

ตราบใดที่แอปพลิเคชันไม่จำเป็นต้องเชื่อมต่อกับแอปพลิเคชันอื่น ๆ มาตรฐานที่มีเอกสารที่ดีก็สามารถทำงานได้ตามปกติ

มีการแลกเปลี่ยนระหว่างสิ่งที่ง่ายสำหรับมนุษย์ (ฉันมักจะใช้ 1-2-2014) และคอมพิวเตอร์ (ที่จะดีกว่าด้วยการเป็นตัวแทนไบนารีแทน ISO) โปรแกรมเมอร์สามเณรมักจะยึดติดกับสิ่งที่พวกเขาสามารถเข้าใจได้ง่ายขึ้นโปรแกรมเมอร์ที่มีประสบการณ์เริ่มเห็นประโยชน์ของการจัดเก็บข้อมูลที่เน้นไปที่คอมพิวเตอร์

ประเด็นที่ยังไม่ได้กล่าวถึงคือความเหมาะสมทางวัฒนธรรมของมาตรฐานสากล

พิจารณามาตรฐานสากลสำหรับการวัด เรานำเสนอสิ่งเหล่านั้นให้กับผู้ใช้ในสหรัฐอเมริกา ฉันไม่แน่ใจว่าผู้ใช้ในสหรัฐอเมริกาของคุณจะมีความสุขกับกิโลเมตรกิโลกรัมและลิตร

พิจารณาว่ามาตรฐานสากลถูกเขียนขึ้นโดยรัฐบาล หากรัฐบาลสเปนเลือกที่จะไม่รับรู้ภาษาบาสก์แล้วจะได้รับข้อกำหนด ISO ได้อย่างไร นี่เป็นปัญหาอย่างหนึ่งของภาษาถิ่นและครีโอลของกลุ่มชายขอบ

แม้แต่รหัสประเทศก็มีปัญหา: ไครเมียตอนนี้ได้รหัสประเทศของตัวเองแล้วหรือยัง? ในที่สุดจะพบสูตร (เช่น "อดีตสาธารณรัฐยูโกสลาเวียแห่งมาซิโดเนีย") แต่ใบสมัครของคุณอาจต้องใช้เวลาในการรอจนกว่าการทูตหรือสงครามจะสิ้นสุดลง

พิจารณาว่ามาตรฐานสากลเขียนขึ้นโดยคำนึงถึงการใช้งานเป็นพิเศษ สิ่งเหล่านี้อาจไม่ตรงกับใบสมัครของคุณทั้งหมด ตัวอย่างเช่นหากคุณเก็บภาษาไว้เพื่อส่งตัวอักษรคุณอาจต้องการเขียนรหัสคนตาบอดอย่างชัดเจนแม้ว่าพวกเขาจะพูดภาษาอังกฤษได้ดีก็ตาม องค์กรสถิติตระหนักดีถึงความจำเป็นในการระบุความหมายที่แน่นอนของตัวแปร (หรือที่รู้จักว่า "ข้อมูลเมตา" ของตัวแปร) เนื่องจากพวกเขาพบกับทุกกรณีที่เป็นไปได้ในระหว่างการสำรวจสำมะโนประชากร ความแม่นยำบางอย่างนั้นคุ้มค่าสำหรับฟิลด์ฐานข้อมูล

ประเด็นสุดท้ายคือในการเลือกตัวเลือกเหล่านี้โปรแกรมของคุณอาจสร้างข้อความทางการเมือง ความจริงเรื่องนี้อาจยุ่งกับโค้ดที่ดีที่สุด (เช่นคุณอาจต้องการชื่อหลายภาษาสำหรับภาษาเดียวกัน)

ในประสบการณ์ของฉันโปรแกรมเมอร์ไม่ได้ใช้มาตรฐาน ISO ด้วยเหตุผลหลายประการเช่น:

• "ฉันไม่รู้ว่ามีมาตรฐาน ISO" (สิ้นสุดเป็นเหตุผลที่ถูกต้องเมื่อคุณได้รับการบอก!)
• "มาตรฐานไม่สามารถเข้าถึงได้ (ไม่สามารถหา / ซื้อสำเนา)" (จริงเหรอ?)
• "มาตรฐานนั้นเข้มงวดเกินไป" (โดยปกติแล้วถ้ามาตรฐานบอกว่า "ไม่" ก็มีเหตุผลที่ดีอย่าเพิกเฉยต่อความกังวลของคุณและลูกค้าของคุณ!)
• "มาตรฐานไม่รวมฟังก์ชั่น / ไลบรารีล่าสุด" (ไม่มีมาตรฐานรวมทุกไลบรารีที่คุณต้องการใช้เพื่อให้เป็นไปตามมาตรฐานสำหรับสิ่งที่มันรวม / ครอบคลุมและสอดคล้องกับมาตรฐานสำหรับสิ่งต่าง ๆ มันไม่ได้)
• "มาตรฐานยุ่งยากเกินไปที่จะใช้" (แก้ตัวที่ใช้มากเกินไป แต่ดูด้านล่าง)

เหตุผลเดียวที่ฉันยอมรับจากพนักงานของฉันซึ่งไม่ได้เป็นข้อแก้ตัวที่ไม่ดีคือ "มาตรฐานไม่ดีพอ" - ได้รับการสนับสนุนจากหลักฐาน บางครั้งความซับซ้อนของมาตรฐาน ISO ที่นำมาใช้นั้นไม่ได้สัดส่วนกับปัญหา / วิธีแก้ไข บางครั้งบริบทที่คุณจะใช้งานโซลูชันของคุณนั้นแตกต่างจากมาตรฐานอย่างมาก และบางครั้งมาตรฐานก็สามารถปรับปรุงได้นั่นคือความก้าวหน้าที่เกิดขึ้น

บ่อยครั้งที่ความล้มเหลวในการใช้มาตรฐาน ISO อาจเกิดจากความไม่มีประสบการณ์ความเกียจคร้านหรือความเย่อหยิ่ง ฉันเสียใจที่ต้องบอกว่าโปรแกรมเมอร์ที่พูดภาษาอังกฤษนั้นมีความผิดโดยเฉพาะอย่างยิ่งในเรื่องความเป็นสากลและเพื่อนร่วมงานในสหรัฐฯของเรามักจะมองว่า ISO เป็น "สิ่งที่ชาวยุโรปไม่เกี่ยวข้อง" (ขออภัยต่อชนกลุ่มน้อย

ISO มีมาตรฐานมากมาย เช่นเดียวกับ CCITT / ITU มาตรฐานเหล่านี้บางส่วนเป็นมาตรฐาน "แรงบันดาลใจ" ในขณะที่มาตรฐานอื่น ๆ เป็นฟังก์ชันขั้นต่ำที่จำเป็น มันมักจะไม่ชัดเจนซึ่งเป็นสิ่งที่

ฉันจำได้ว่าในปี 1980 ถามว่าทำไมผู้ขายอุปกรณ์บางรายใช้มาตรฐานย่อยหนึ่งชุดในขณะที่ผู้ค้ารายอื่นใช้ชุดย่อยที่แตกต่างกัน นั่นคือเมื่อมันปรากฏออกมาว่ามาตรฐานมักถูกกำหนดไว้ก่อนที่สิ่งใดจะได้ผล และผู้ขายมักเลือกที่จะไม่ใช้มาตรฐานเพื่อให้พวกเขาขัดขวางการทำงานร่วมกันซึ่งทำให้พวกเขาได้เปรียบ

นั่นเป็นเหตุผลที่ฉันชอบ IETF RFC พวกเขาจะไม่กลายเป็น RFC จนกว่าจะมีการใช้งานที่เป็นอิสระ 3 รายการของ RFC

ถ้าฉันสร้างฐานข้อมูล Oracle และฉันต้องการเก็บวันที่ฉันจะใช้ประเภทข้อมูล Oracle DATE ฉันจะไม่รู้หรือไม่สนใจว่า Oracle จะปฏิบัติตามมาตรฐาน ISO หรือไม่ นี่เป็นกรณีของความสอดคล้องของฉันกับมาตรฐานอื่น (Oracle หนึ่ง) และไม่ได้ออกไปจากมาตรฐาน ISO มากนัก ดูการตอบสนองของ @ David

ในบางกรณีเมื่อฉันรู้ว่ามีมาตรฐาน ISO สำหรับสิ่งที่ฉันออกแบบค่าใช้จ่ายในการย้อนกลับและการออกแบบใหม่จะเป็นสิ่งต้องห้ามหรืออย่างน้อยก็เห็นว่าเป็นเช่นนั้น

ในระยะสั้นมีการสร้างรหัสการทำงานมากขึ้นโดยใช้มาตรฐานที่มีอยู่หรือโดยการสร้างรหัสใหม่มากกว่าการวิจัยอย่างระมัดระวังในมาตรฐานที่มีอยู่ ข้อเสียเกิดขึ้นเมื่อการรวมขนาดใหญ่ต้องการการทำงานร่วมกัน สิ่งนี้มักจะเกิดขึ้นในบริบทของโครงการในภายหลัง