เหตุใดอุตสาหกรรมไอทีจึงไม่สามารถส่งมอบโครงการขนาดใหญ่ที่ปราศจากข้อผิดพลาดได้อย่างรวดเร็วเหมือนในอุตสาหกรรมอื่น ๆ

หลังจากดูซีรีส์ MegaStructuresของ National Geographic ฉันรู้สึกประหลาดใจที่โครงการขนาดใหญ่เสร็จสมบูรณ์ เมื่อทำงานเบื้องต้น (การออกแบบรายละเอียดอื่น ๆ ) จะทำบนกระดาษสำนึกตัวเองของโครงการขนาดใหญ่ที่ใช้เวลาเพียงไม่กี่ปีหรือบางครั้งไม่กี่เดือน

ตัวอย่างเช่นแอร์บัส A380 "เปิดตัวอย่างเป็นทางการในวันที่ 19 ธันวาคม 2000" และ "ในช่วงต้นเดือนมีนาคม 2548"เครื่องบินได้ทำการทดสอบแล้ว เช่นเดียวกันกับเรือบรรทุกน้ำมันขนาดใหญ่ตึกระฟ้า ฯลฯ

เมื่อเทียบกับความล่าช้าในอุตสาหกรรมซอฟต์แวร์ฉันไม่สามารถช่วยสงสัยได้ว่าทำไมโครงการไอทีส่วนใหญ่จึงช้าหรือแม่นยำกว่าทำไมพวกเขาจึงไม่รวดเร็วและไม่ผิดพลาดในระดับเดียวกันทำให้มีคนมากพอ?

โครงการต่างๆเช่น Airbus A380 มีทั้ง:

• ความเสี่ยงที่คาดไม่ถึงที่สำคัญ: แม้ว่านี่จะไม่ใช่เครื่องบินลำแรกที่สร้างขึ้น แต่ก็ยังคงผลักดันขีด จำกัด ของเทคโนโลยีและสิ่งต่าง ๆ ที่ทำงานได้ดีสำหรับสายการบินขนาดเล็กอาจไม่ทำงานสำหรับเครื่องบินที่ใหญ่กว่าเนื่องจากข้อ จำกัด ทางกายภาพ ในทำนองเดียวกันเทคโนโลยีใหม่ที่ใช้ซึ่งยังไม่ได้ใช้เพราะตัวอย่างเช่นพวกเขายังไม่พร้อมใช้งานในปี 1969 เมื่อโบอิ้ง 747 เสร็จสิ้น

• ความเสี่ยงที่เกี่ยวข้องกับทรัพยากรมนุษย์และการจัดการโดยทั่วไป: ผู้คนเลิกกลางโครงการไม่สามารถเข้าถึงบุคคลเพราะเธออยู่ในช่วงหยุดพักร้อนข้อผิดพลาดทั่วไปของมนุษย์ ฯลฯ

ด้วยความเสี่ยงเหล่านี้ผู้คนยังคงประสบความสำเร็จในโครงการเช่นสายการบินขนาดใหญ่เหล่านั้นในระยะเวลาอันสั้นและแม้จะมีความล่าช้าในการส่งมอบโครงการเหล่านั้นก็ยังคงประสบความสำเร็จอย่างมากและมีคุณภาพสูง

เมื่อพูดถึงการพัฒนาซอฟต์แวร์โครงการขนาดใหญ่และซับซ้อนเหมือนสายการบิน (ทั้งในเชิงเทคนิคและในแง่ของการจัดการ) และมีความเสี่ยงที่ไม่คาดคิดจากโลกจริงน้อยลงเล็กน้อย

อย่างไรก็ตามโครงการไอทีส่วนใหญ่นั้นช้าและล่าช้าและการเพิ่มนักพัฒนาให้กับโครงการไม่ใช่ทางออก (จากทีมนักพัฒนาสิบถึงสองพันคนบางครั้งจะอนุญาตให้ส่งมอบโครงการเร็วขึ้นบางครั้งก็ไม่ได้และบางครั้งจะเป็นอันตรายต่อ โครงการและเพิ่มความเสี่ยงของการไม่จบเลย)

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

ความแตกต่างดังกล่าวสามารถอธิบายได้อย่างไร? เป็นเพราะความจริงที่ว่าอุตสาหกรรมการพัฒนาซอฟต์แวร์ยังเด็กเกินไปที่จะสามารถจัดการคนหลายพันคนในโครงการเดียวเพื่อส่งมอบผลิตภัณฑ์ขนาดใหญ่เกือบไร้ข้อบกพร่องได้อย่างรวดเร็ว?

มีนาคมของDeath Yourdonสัมผัสกับคำถามประเภทเมตาเหล่านี้จำนวนหนึ่ง

โดยทั่วไปอุตสาหกรรมซอฟต์แวร์ขาดสิ่งต่อไปนี้จำนวนมากซึ่งเข้ามาเกี่ยวข้องกับโครงการขนาดใหญ่

• การแบ่งมาตรฐานและรายการงาน

  • สิ่งนี้ได้ดีขึ้นอย่างแน่นอน แต่การออกแบบยังคงไม่เกิดขึ้นเพื่อแยกระบบขนาดใหญ่ออก ในบางวิธีซอฟต์แวร์ไม่สามารถเห็นด้วยกับสิ่งที่จำเป็นสำหรับโครงการที่กำหนดได้น้อยกว่าความสามารถในการแยกสิ่งต่าง ๆ ออกเป็นส่วนประกอบ
  • การบินและอวกาศ, การก่อสร้างอาคาร, รถยนต์และอื่น ๆ ทั้งหมดมีสถาปัตยกรรมที่ขับเคลื่อนด้วยส่วนประกอบที่มีส่วนต่อประสานที่แน่นหนาพอสมควร ซอฟต์แวร์ยังอนุญาตให้มีการตกเลือดมากเกินไปในพื้นที่ที่เกี่ยวข้อง

• ร่างใหญ่ของโครงการที่ประสบความสำเร็จคล้ายกัน A380 ไม่ใช่เครื่องบินใหญ่ลำแรกที่แอร์บัสสร้างขึ้น มีแอปพลิเคชั่นซอฟต์แวร์ขนาดใหญ่จำนวนมากออกมี แต่ส่วนใหญ่ของพวกเขาได้รับความเดือดร้อนอย่างมากในบางด้านหรืออื่น ๆ และจะไม่เข้าใกล้กับการถูกเรียกว่า "ประสบความสำเร็จ"

• กลุ่มนักออกแบบและผู้สร้างขนาดใหญ่ที่ทำงานในโครงการที่คล้ายกันและประสบความสำเร็จจำนวนหนึ่ง เกี่ยวข้องกับปัญหาของโครงการที่ประสบความสำเร็จไม่ได้มีความสามารถของมนุษย์ที่เคยทำมาแล้วทำให้สิ่งต่าง ๆ เป็นเรื่องยากมากจากมุมมองการทำซ้ำ

• "ไม่เคย" สร้างสิ่งเดียวกันสองครั้ง ในหลาย ๆ ทางเครื่องบินก็เหมือนเครื่องบินลำอื่น ๆ มันมีทั้งปีกเครื่องยนต์ที่นั่ง ฯลฯ โครงการซอฟต์แวร์ขนาดใหญ่ไม่ค่อยพูดซ้ำ เคอร์เนลระบบปฏิบัติการแต่ละตัวแตกต่างกันอย่างมีนัยสำคัญ ดูความแตกต่างในระบบไฟล์ และสำหรับเรื่องนั้นมีระบบปฏิบัติการที่แตกต่างกันอย่างแท้จริงกี่ตัว? ของชิ้นใหญ่กลายเป็นโคลนของไอเท็มพื้นฐานในบางจุด AIX , Solaris , HP-UX ... ประกาศกลับไปที่AT & T System V Windows มีจำนวนการลากไปข้างหน้าอย่างไม่น่าเชื่อผ่านการทำซ้ำแต่ละครั้ง โดยทั่วไปแล้วตัวแปรของ Linux ทั้งหมดกลับไปที่แกนเดียวกับที่ Linus เริ่มต้น ฉันนำมันมาเพราะตัวแปรมีแนวโน้มที่จะเผยแพร่เร็วกว่าระบบปฏิบัติการที่เป็นกรรมสิทธิ์และโดดเด่นอย่างแท้จริง

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

• QA / QC ไม่ได้เน้นเท่าที่ควรหรือเป็นโครงการขนาดใหญ่ สิ่งนี้กลับไปที่การมีส่วนต่อประสานระหว่างคอมโพเนนต์และไม่มีข้อกำหนดที่เข้มงวดสำหรับวิธีการทำงานของส่วนประกอบ การคลายนั้นช่วยให้เกิดผลที่ไม่ตั้งใจและสำหรับแมลงที่จะคืบคลานเข้ามา

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

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

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

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

ดังนั้นเราจะทำอย่างไรเมื่อเราวางแผนซอฟต์แวร์ เรายังคงออกแบบอยู่ แต่ก่อนหน้านี้

ในซอฟต์แวร์ไม่มีสายการผลิตโน้ต การสร้างส่วนประกอบสุดท้ายคือ (เปรียบเทียบ) ราคาถูกและการจำลองแบบผลิตภัณฑ์ขั้นสุดท้ายนั้นสมบูรณ์และฟรีอย่างมีประสิทธิภาพ - คุณคัดลอกสิ่งประดิษฐ์ประกอบ

วิธีชี้ให้เห็นตัวเลขบางส่วน:

1. การเปลี่ยนแปลงของความต้องการหลังจากการดำเนินการเริ่มต้น ; เช่นเมื่อ Airbus A380 คันแรกเริ่มสร้างขึ้นในโรงงานฉันไม่อยากเชื่อเลยว่าถ้ามีคนต้องการที่นั่งเพิ่มอีก 200 ที่นั่งพวกเขาจะอยู่ที่นั่น แต่ในโครงการซอฟต์แวร์ขนาดใหญ่แม้หลังจากโปรแกรมเมอร์เริ่มพัฒนาผู้ใช้อีก 5 ประเภทก็สามารถเพิ่มได้
2. ความซับซ้อน - โครงการซอฟต์แวร์ขนาดใหญ่นั้นซับซ้อนอย่างยิ่ง อาจเป็นโครงการที่ซับซ้อนที่สุดที่มนุษย์ออกแบบและพัฒนา
3. ทรัพยากรไม่เพียงพอมีการใช้จ่ายในด้านสถาปัตยกรรมและขั้นตอนการออกแบบ ;
4. ความไม่บรรลุนิติภาวะภาคสนาม - วิศวกรรมซอฟต์แวร์ค่อนข้างมีระเบียบวินัยน้อยเมื่อเทียบกับพี่สาววิศวกรรมคนอื่น ๆ สิ่งนี้มีสองนัย: a) ฮิวริสติกและแนวทางปฏิบัติที่ดีมีไม่มาก b) ผู้เชี่ยวชาญที่มีประสบการณ์ไม่มาก
5. ขาดการพิสูจน์ทางคณิตศาสตร์ - ในกรณีส่วนใหญ่วิธีการทางคณิตศาสตร์ไม่ได้ใช้เพื่อพิสูจน์ว่าชิ้นส่วนของซอฟต์แวร์ทำงานตามที่ต้องการ ใช้การทดสอบแทน สิ่งนี้ถือเป็นจริงในสาขาวิศวกรรมอื่น ๆ ที่ต้องอาศัยคณิตศาสตร์เป็นอย่างมาก เหตุผลนี้มีความซับซ้อน
6. Rush - ผู้จัดการหลายคนมีกำหนดเวลาที่ไม่สามารถทำได้ ดังนั้นคุณภาพของรหัสจะถูกวางไว้ที่สองเนื่องจากกำหนดเวลา

ตอบคำถามอย่างเคร่งครัด - ฉันมักจะเชื่อว่าคนอื่นมีความคาดหวังสูงมาก (โดยเฉพาะในเวลาส่งมอบ) จากโปรแกรมเมอร์และไม่เข้าใจว่าซอฟต์แวร์ขนาดใหญ่ยากเพียงใด

หลักฐานของคำถามนั้นมีข้อบกพร่องเล็กน้อย ทั้ง A380 และ Boeing 787 ได้รับการส่งมอบล่าช้าหลายปี

ในกรณีของ A380 ความล่าช้าส่วนใหญ่เกิดจากหน่วยแอร์บัสของฝรั่งเศสและเยอรมันโดยใช้ซอฟต์แวร์การออกแบบCATIA รุ่นที่ต่างกันและไม่เข้ากันเล็กน้อย สิ่งนี้ประจักษ์อย่างขัดกันว่าเป็นชุดสายไฟที่ไม่ค่อยเหมาะกับเครื่องบิน

ไม่มีอะไรผิดปกติกับ CATIA ซึ่งเป็นซอฟต์แวร์ออกแบบอากาศยานที่ใช้กันอย่างแพร่หลาย แต่มีบางคนที่ทิ้งลูกบอลการตั้งค่าซอฟต์แวร์

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

ทั้ง A380 และ B787 ต้องปรับเปลี่ยนการออกแบบปีกหลังจากเครื่องบินลำแรกมีปัญหาเชิงโครงสร้าง

โครงการขนาดใหญ่ที่ซับซ้อนนั้นยากสำหรับมนุษย์ในทุกสาขา

ผู้ชายตึกระฟ้าที่นี่ ไม่แน่ใจว่าฉันสามารถตอบคำถามของคุณได้หรือไม่ แต่ฉันสามารถทำให้แสงบางอย่างเป็นรายการต่าง ๆ ในเธรดได้ อาคารเกิดขึ้นอย่างรวดเร็วจริง ๆ ข้อ จำกัด ที่สำคัญคือสถานที่ (ข้อบังคับ) แต่โดยทั่วไปจะใช้เวลา 3 ถึง 10 ปีสำหรับอาคารสูงตั้งแต่ต้นจนจบ

ฉันคิดว่าการเปรียบเทียบอาคารใหม่กับโครงการซอฟต์แวร์ใหม่นั้นไม่แม่นยำมาก สิ่งปลูกสร้างใหม่ใกล้กับเคอร์เนลหรือระบบปฏิบัติการเวอร์ชันใหม่ ในส่วนนี้การพัฒนาซอฟต์แวร์นั้นเร็วกว่ามาก เราไม่เคยสร้างจากศูนย์เพราะจะเป็นงานที่มีความเสี่ยงสูงที่ลูกค้าจะไม่สมัคร การออกแบบและการพัฒนาส่วนใหญ่ในอาคารนั้นเป็นสิ่งที่พิสูจน์ได้และเสร็จสมบูรณ์แล้ว

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

การออกแบบใช้เวลาหนึ่งเดือนสำหรับแนวคิดในการทำแผนผังสองถึงหกเดือนในการออกแบบการพัฒนาอีกหกเดือนเพื่อดูรายละเอียดและเอกสารการก่อสร้างโดยทีมงานสถาปนิกที่ปรึกษาวางแผนวิศวกรโครงสร้างวิศวกรลมวิศวกรบริการปริมาณและต้นทุนที่ปรึกษานักสำรวจ วิศวกรการเข้าถึงและรายการดำเนินต่อไป ...

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

ความซับซ้อน - ฉลาดมีความแตกต่าง แต่โดยรวมมันอาจจะเหมือนกัน เราไม่เพียง แต่มีหน่วยงานที่เกี่ยวข้องและมีหลายระดับของ abstractions และส่วนต่อประสานที่เป็นชั้น แต่ยังมีคนที่มีความเชี่ยวชาญเป็นพิเศษในส่วนเล็ก ๆ ของกระบวนการที่ทำให้การสื่อสารเป็นเรื่องยากมาก

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

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

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

จากนั้นการออกแบบเหล่านั้นใช้เวลานานเท่าใด ปี? สอง? สิบปี? การออกแบบเป็นส่วนที่ซับซ้อนที่สุดในการสร้างบางสิ่งบางอย่างการก่อสร้างนั้นง่าย

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

การสร้างตัวเองถูกจัดการโดยอัตโนมัติโดยคอมไพเลอร์ และด้วยเหตุนี้เราจึงสามารถสร้างผลิตภัณฑ์ทั้งหมดได้ในเวลาไม่กี่นาที

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

ลองนึกภาพว่าในช่วงกลางของการออกแบบเครื่องบินแอร์บัสเอ 380 นั้นมีใครบางคนเข้าร่วมการประชุมและกล่าวว่า "เฮ้สามารถสร้างมันขึ้นมาเป็นเครื่องบินจำลองได้หรือไม่" คนอื่น ๆ เข้าร่วมในการพูดว่า "ใช่แล้วใช่ triplane มีปีกที่ดีกว่า" เจ้าปีถัดไปใช้เวลาเปลี่ยนการออกแบบ A380 เป็น triplane ในการประชุมอื่นมีคนพูดว่า "เครื่องบิน Triplane? นั่นเก่าเราต้องการเครื่องบินปีกสองชั้นเพียงแค่เอาปีกใดปีกหนึ่งออก"

หรือลองจินตนาการว่าในช่วงกลางของโครงการก่อสร้างสะพานใครบางคนพูดว่า "เฮ้เราเพิ่งทำข้อตกลงกับ บริษัท ขนส่งพวกเขาต้องการสะพานให้สูงขึ้นอีก 40 ฟุตเพราะเรือของพวกเขาสูงขึ้นมากขอบคุณ ."

นี่คือเหตุผลบางประการที่ทำให้โครงการซอฟต์แวร์ขนาดใหญ่และขนาดเล็กสิ้นสุดในความล้มเหลวในอัตราที่น่าตกใจ

ในฐานะที่เป็นคนที่มีพื้นฐานด้านวิศวกรรมเครื่องกลทำงานด้านไอทีฉันมักจะสงสัยเกี่ยวกับสาเหตุของอัตราความสำเร็จต่ำในด้านไอที

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

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

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

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

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

ฉันเกรงว่าฉันจะไม่เห็นด้วยกับคำสั่งของคุณ

แอร์บัสและโบอิ้งเป็นสองตัวอย่างของ บริษัท ที่สร้างเครื่องบิน มี บริษัท กี่แห่งที่สร้างเครื่องบิน น้อยมากถ้าคุณจะเปรียบเทียบกับจำนวน บริษัท ที่สร้างซอฟต์แวร์

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

ดูรถยนต์ มีผู้ผลิตคุณภาพสูงที่สร้างรถยนต์ที่มีความทนทานและสูงมาก (คิดว่า Land Rover, Mercedes) และมีผู้ผลิตรถยนต์ที่มีอายุไม่ถึงปีโดยไม่ต้องซ่อม (คิด Kia หรือ Cherry) นี่เป็นตัวอย่างที่สมบูรณ์แบบของอุตสาหกรรมที่มีด่านกั้นต่ำกว่าเล็กน้อยหากคุณเริ่มมีผู้เล่นที่อ่อนแอกว่า

ซอฟต์แวร์ไม่แตกต่างกัน ในทางกลับกันคุณมีผลิตภัณฑ์ buggy จำนวนมากเช่น Windows, Office, Linux, Chrome หรือ Google Search เป็นโครงการคุณภาพสูงที่ส่งมอบตรงเวลาและมีระดับคุณภาพใกล้เคียงกับเครื่องบิน

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

ซอฟต์แวร์ก็ต้องการเช่นกัน ถ้ามีเพียงคนที่ใช้เวลามากกับการวินิจฉัยการป้องกันหรือการตรวจสอบสถานะและคุณภาพของซอฟต์แวร์เหมือนกับที่ทำกับผลิตภัณฑ์เชิงกล / เชิงกายภาพ คุณอ่านบันทึกแอปพลิเคชันของคุณทุกครั้งก่อนเปิดใช้งานหรือไม่ .. ถ้าเป็นเครื่องบินคุณจะต้อง ;-)

กลุ่มอาคารดิจิทัลสามารถเป็น 1 หรือ 0 ไม่มีสิ่งใดแทรกอยู่ระหว่างกันได้

การออกแบบเครื่องจักรกลมีระดับด่านเก็บค่าผ่านทาง ฉันสามารถใส่หมุดที่สมบูรณ์แบบหนึ่งอันลงในบริดจ์ได้และส่วนใหญ่จะไม่ล้มลงอย่างไรก็ตามในโค้ดแม้แต่เพียงครั้งเดียวที่ใส่ 0 โดยที่ 1 ควรจะล้มเหลวทั้งโปรแกรม

เนื่องจากลักษณะเชิงตรรกะและเชิงซ้อนของการคำนวณการเปลี่ยนแปลงใด ๆ แม้แต่น้อยมากอาจนำไปสู่ความล้มเหลวอย่างรุนแรง

ฉันมักจะสงสัยในสิ่งเดียวกัน แน่นอนว่ามันให้ความรู้สึก (บางครั้ง) เหมือนกับว่าเราเป็นกลุ่มมือสมัครเล่นที่ไม่มีความคิดว่าเรากำลังทำอะไรอยู่ ฉันไม่ชอบคำอธิบายที่วางความผิดต่อผู้จัดการหรือปัจจัยภายนอกอื่น ๆ - เราผู้พัฒนาควรรับผิดชอบสิ่งที่เราสร้าง

ผมคิดว่าเราอยู่ในธุรกิจที่ข้อผิดพลาดที่มีราคาถูก ซอฟต์แวร์การซ่อมแซมมีราคาถูกเมื่อเทียบกับการสร้างตึกระฟ้าหรือเรียกคืนโทรศัพท์มือถือที่ขายทุกเครื่อง

นี้ได้สร้างวัฒนธรรมที่ข้อบกพร่องเป็นส่วนหนึ่งของชีวิตประจำวัน พวกเขาได้รับการยอมรับด้วยยักไหล่ ในขณะที่ข้อบกพร่องบางอย่างอาจหลีกเลี่ยงไม่ได้ แต่พวกมันควรควบคุมการทำงานประจำวันของเราหรือไม่? ฉันเข้าใจผู้จัดการที่ไม่รู้สึกว่า QA คุ้มค่ากับปัญหาเพราะพวกเขาคาดหวังข้อบกพร่องอยู่ดี ฉันไม่เข้าใจโปรแกรมเมอร์ที่ไม่ได้ใช้ความพยายามในการสร้างรหัสปราศจากข้อผิดพลาดเพราะการแก้ไขข้อบกพร่องน่าเบื่อเหมือนนรก

ในสาระสำคัญฉันเชื่อว่ามันเป็นปัญหาทางวัฒนธรรมและฉันหวังว่ามันจะเปลี่ยนไป

มาตรฐานทางด้านวิศวกรรมและการปฏิบัติที่แตกต่างกันมากในด้านไอที (เป็นอุตสาหกรรมที่เป็นอิสระ) มากกว่าในการบินและอวกาศ นี้อาจจะเป็นส่วนใหญ่เข้าใจได้ง่ายโดยพิจารณาว่าผู้เชี่ยวชาญด้านไอทีตอบสนองเมื่อพบเอกสารมาตรฐานไอทีในการบินและอวกาศ ตัวอย่างเช่นมาตรฐานStrike Strike ร่วม C ++ที่ได้ทำทางอินเทอร์เน็ตในครั้งล่าสุด

หลายคนแสดงความยินดีหรือลาออกอย่างโหยหา (หวังว่าเราจะทำแบบนั้นได้); และหลายคนตอบโต้ด้วยการเยาะเย้ยโดยอ้างว่าไม่มีวิธีปฏิบัติในการส่งมอบผลิตภัณฑ์ผู้บริโภคในลักษณะนี้ สิ่งนี้อาจถูกต้องตามความคาดหวังไม่ใช่ของผู้บริโภค แต่เป็นการจัดการ มีความไม่ไว้วางใจอย่างมากสำหรับผู้เขียนโค๊ดที่เพิ่งเขียนโค้ดและโค้ดเป็นเวลาสองสามสัปดาห์ พระเจ้าช่วยผู้เขียนโปรแกรมที่ออกแบบบางอย่างเป็นเวลาสองสัปดาห์ ไม่เช่นนั้นกับเครื่องบิน

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

บางสิ่งจากฉัน:

1- มาตรฐานและชิ้นส่วน: พวกเขาเป็นผู้ผลิตเครื่องบินไม่ใช่นักพัฒนา ฉันไม่แน่ใจทั้งหมด แต่ฉันเดาว่าชิ้นส่วนจำนวนมากถูกเอาต์ซอร์ซ พวกเขาไม่ได้สร้างอิเล็กทรอนิคส์ / เครื่องดนตรีของตัวเองพวกเขาได้รับที่นั่งจากบาง บริษัท เครื่องยนต์อาจถูกพัฒนาที่อื่น ๆ เป็นต้น

ในทางกลับกันโครงการซอฟท์แวร์มักเริ่มต้นจากศูนย์ด้วยกรอบ / ตัวช่วยเล็ก ๆ

2- เวลาที่จะตีตลาด: เวลาไม่ใช่ปัญหาสำคัญสำหรับเครื่องบิน ฉันพนันได้เลยว่าการออกแบบของแอร์บัสเสร็จสิ้นไปหลายปีก่อนที่มันจะเสร็จสิ้นและพวกเขาก็เลือกที่จะละเลยความก้าวหน้าครั้งสำคัญที่อาจเกิดขึ้นในเวลานั้น (เช่นเดียวกับผู้ผลิตรถยนต์เช่นเทคโนโลยีที่ทันสมัยที่พวกเขาพัฒนาในขณะนี้จะเข้าสู่ถนนภายใน 5-10 ปี)

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

3- Release-cycle และรุ่น - เครื่องบินจะต้องเสร็จสิ้นอย่างสมบูรณ์เมื่อ "ปล่อย" ไม่มีรุ่นเบต้าที่เสถียรสร้างขึ้นทุกคืนหรือคล้ายกัน นอกจากนี้เมื่อดำเนินการเสร็จแล้วจะสามารถแก้ไขได้เพียงเล็กน้อย คุณไม่สามารถเพิ่มระดับอีก 100 ที่นั่งให้กับโบอิ้งที่มีอยู่แล้วมันเป็นไปไม่ได้

ซอฟต์แวร์ในทางตรงกันข้ามมีการเปลี่ยนแปลงที่เพิ่มขึ้นซึ่งมักจะเป็นเพียง "สร้างงานที่" แต่ไม่จำเป็นต้องเสร็จผลิตภัณฑ์ นอกจากนี้ในไอทีมันไม่แปลกที่จะพูดว่า "เฮ้เรามาเพิ่มช่องเก็บสัมภาระอีกอันลงในระนาบของเราซึ่งมีน้ำหนักเพิ่มขึ้นอีก 50 ตัน"

ฉันคิดว่าคำตอบนั้นง่ายมาก:

1) การสร้างและการใช้งานทางกายภาพนั้นมีมานานเท่าที่ผู้คนมีอยู่ - เรามีเวลาหลายพันปีในการพัฒนาวิธีการและเทคนิคของเราในการดำเนินโครงการทางกายภาพ ซอฟต์แวร์ 'โครงสร้าง' ซึ่งต้องใช้ทักษะชุดใหม่และแตกต่างกันมีอายุไม่เกิน 50 ปี - เรายังไม่มีเวลาพอที่จะเข้าใจได้

2) โครงสร้างเสมือนจริงนั้นยากกว่า - คุณต้อง 'เห็น' สิ่งต่าง ๆ ในใจที่ไม่มีความจริงทางกายภาพใด ๆ ต้องให้คุณวิเคราะห์และสรุปข้อมูลจำนวนมากก่อนที่คุณจะรู้ว่าผลิตภัณฑ์ของคุณควรมีลักษณะอย่างไรและขั้นตอนที่ต้องใช้ในการสร้าง ไม่เช่นนั้นเมื่อสร้างสะพานหรืออาคาร

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

ฉันจะลองตอบโดยใช้สำเนาคำต่อคำของบทความจากรำพึงที่ฝังตัวของ Jack Ganssle ขณะที่สิ่งนี้บอกว่าเฟิร์มแวร์ทุกหนทุกแห่งเพียงแค่แทนที่ด้วยซอฟต์แวร์

เมื่อเทียบกับอะไร

เฟิร์มแวร์เป็นสิ่งที่แพงที่สุดในจักรวาล ในหนังสือที่ยอดเยี่ยมของเขา "กฎหมายของออกัสติน" นอร์แมนออกัสตินอดีตซีอีโอของ Lockheed Martin บอกเล่าเรื่องราวเกี่ยวกับปัญหาที่พบโดยชุมชนป้องกัน เครื่องบินรบประสิทธิภาพสูงคือความสมดุลของความต้องการที่ขัดแย้งกัน: ช่วงเชื้อเพลิงกับประสิทธิภาพ ความเร็วเทียบกับน้ำหนัก ดูเหมือนว่าในช่วงปลายยุค 70 นักสู้จะหนักพอ ๆ กับที่เคยเป็นมา ผู้รับเหมาที่มักจะแสวงหาผลกำไรที่มากขึ้นมองหาสิ่งที่พวกเขาสามารถเพิ่มค่าใช้จ่ายได้มาก แต่ก็ไม่มีผลอะไรเลย

คำตอบ: เฟิร์มแวร์ ค่าใช้จ่ายไม่มีที่สิ้นสุดมวลเป็นศูนย์ ตอนนี้ Avionics รับผิดชอบค่าใช้จ่ายของนักสู้มากกว่าครึ่ง นั่นเป็นความเปลี่ยนแปลงครั้งใหญ่เมื่อคุณพิจารณานักสู้ชาวอเมริกันรุ่นล่าสุดคือ F-22 ซึ่งมีราคาสูงถึงสามในพันล้านต่อป๊อป ออกัสตินแทบจะร้องด้วยความยินดีเมื่อเขาเล่าเรื่องนี้

แต่ทำไมซอฟต์แวร์ถึงมีราคาแพง Tom DeMarco เคยตอบคำถามนี้ด้วยคำสามคำนี้เทียบกับอะไร เขาพูดคุยเกี่ยวกับกรณีทางธุรกิจที่ค่อนข้างน่าเบื่อ แต่คำตอบนั้นได้สะท้อนอยู่ในใจของฉันมาหลายปี เมื่อเทียบกับอะไร ด้วยซอฟต์แวร์ที่เราสร้างพฤติกรรมของผลิตภัณฑ์ที่มีความซับซ้อนเป็นประวัติการณ์ แน่นอนว่ารหัสนั้นแพง แต่ไม่เคยมีใครในประวัติศาสตร์ของอารยธรรมที่มีการสร้างอะไรที่ซับซ้อนมาก

พิจารณาการจัดเรียงฟองต่อไปนี้ยกขึ้นอย่างไร้ยางอายจาก Wikipedia และไม่ได้ตรวจสอบความถูกต้อง:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

มันเป็นตัวละครที่ไม่ใช่ที่ว่างเพียง 110 ตัวบางทีอาจจะถูกโยนทิ้งไปในหนึ่งหรือสองชั่วโมง สมมติว่าเราไม่มีซอฟต์แวร์และต้องใช้การเรียงลำดับโดยใช้กลยุทธ์อื่น ราคาเท่าไหร่

วิศวกรเครื่องกลอาจโอ้อวดว่าอาชีพของเขาสร้างเครื่องคัดแยกก่อนคอมพิวเตอร์ พิจารณาเครื่องคัดแยกการ์ด 82 รุ่นในยุคพ. ศ. 2492 ของไอบีเอ็ม ( http://www.columbia.edu/acis/history/sorter.html ) ด้วยปริมาณงานสูงสุด 650 ใบต่อนาทีซึ่งน้อยกว่ารหัสข้อมูลของเราอาจจัดการแม้ใน 4 MHz Z80 แน่นอนว่ารุ่น 82 นั้นมีการเรียงลำดับบัตรหนึ่งใบในแต่ละครั้งเท่านั้น การเรียงลำดับสำรับอย่างสมบูรณ์อาจใช้เวลาหลายสิบรอบ

ใช้เวลาในการออกแบบและสร้างสัตว์ร้ายนี้นานเท่าไหร่ ปีไม่ต้องสงสัยเลย และฟังก์ชั่นของ pales นั้นเทียบกับรหัสของเราซึ่งเร็วกว่ามากและสามารถจัดการชุดข้อมูลขนาดยักษ์ได้ แต่นั่นคือปี 1949 ใช้เวลานานแค่ไหนในการสร้างฟองเรียงจากชิ้นส่วนอิเล็กทรอนิกส์ - โดยไม่มี FPGAs และ VHDL หรือ CPU

ในหนึ่งชั่วโมงฉันจัดการไดอะแกรมบล็อกคร่าวๆหนึ่งระดับชิปเหนือระดับ (บล็อกมีชื่อเช่น "adder," "สลัก 16 บิต" และสิ่งที่คล้ายกัน) แต่ตรรกะการเรียงลำดับนั้นค่อนข้างยุ่งเหยิงอย่างชัดเจนดังนั้นฉันเพิ่งโยนใน PLD โดยสมมติว่าในบางจุดมันคงไม่ยากเกินไปที่จะเขียนสมการที่เหมาะสม และใช่บางทีอาจทำลายกฎที่ไม่สามารถตั้งโปรแกรมได้ แต่การออกแบบและแก้ไขข้อบกพร่องทั้งหมดโดยใช้ประตูในเวลาที่สมเหตุสมผลไม่น่าจะเป็นแก๊สบัค - อะ - แกลลอน

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

การแปลแผนภาพบล็อกคร่าวๆเป็นแผนผังอาจใช้เวลาหนึ่งวัน จากนั้นมีเวลาในการออกแบบและผลิต PCB, สั่งซื้อและโหลดชิ้นส่วน (และเปลี่ยนการออกแบบเพื่อจัดการกับปัญหาที่สิ้นสุดที่ไม่คาดคิด แต่หลีกเลี่ยงไม่ได้) และแน่นอนทำให้วงจรทำงาน เราอาจพูดถึงความพยายามหลายสัปดาห์และเงินจำนวนมากสำหรับบอร์ดชิ้นส่วนและอุปกรณ์ทดสอบที่เหมาะสม

ทั้งหมดนี้เพื่อแทนที่โค้ด 7 บรรทัด โปรแกรมฝังตัวจริงไม่กี่โปรแกรมมีน้อยกว่า 10,000 รายการ มากมายเกินหนึ่งล้าน ต้องใช้ฮาร์ดแวร์และวิศวกรรมจำนวนเท่าไรในการแทนที่โปรแกรมคอมพิวเตอร์ขนาดใหญ่พิเศษ

พิจารณาโปรแกรมจริงเช่นสเปรดชีต มันต้องใช้วงจรเท่าไหร่ในการสร้างโดยไม่มีโปรเซสเซอร์? มันอาจเป็นขนาดของเมือง

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

ดังนั้นที่นั่น! ซอฟต์แวร์ / เฟิร์มแวร์มีความซับซ้อนที่เหนือชั้น

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

เนื่องจากเยาวชนที่เป็นญาติกันของวิศวกรรมซอฟต์แวร์และการจัดการเป็นวินัยจึงมีข้อมูลที่ผิดและการหลอกลวงที่ยังคงเป็นความจริง ( ดูอ้างอิงนี้ ) ซึ่งเป็นอุปสรรคต่อการพัฒนาซอฟต์แวร์และวิศวกรรมโดยรวม

นักพัฒนาบางคนไม่ได้ถูกสร้างขึ้นอย่างเท่าเทียมกัน บางคนดีคนอื่นดีไม่

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

มหาวิหารใช้เวลาสร้างมากถึง 100 ปี

เครื่องบินแอร์บัสบางลำต้องการรหัส 1 ล้านเส้นในการทำงาน

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

โครงการขนาดใหญ่มักเกิดขึ้นในองค์กรขนาดใหญ่ หากคุณไม่เคยทำงานในองค์กรขนาดใหญ่มีสิ่งหนึ่งที่รับประกันได้ว่าจะฆ่าประสิทธิภาพและประสิทธิผล: ระบบราชการ

น่าแปลกที่หลายคนไม่ทราบว่าระบบราชการคืออะไร (มักสับสนกับการเมือง) หรือแม้ว่า / เมื่อพวกเขามีปัญหาเกี่ยวกับระบบราชการ

เราเพิ่งสรุปโครงการที่จะใช้การรับรองความถูกต้องของสมาร์ทการ์ด แต่เดิมประมาณว่าสามเดือน ใช้เวลา 15 เดือน ไม่มีค่าใช้จ่ายงบประมาณขอบเขตหรือเหตุผลทางเทคนิคสำหรับความล่าช้า ขอบเขตนั้นแคบจริงๆ - เฉพาะบัญชีที่มีสิทธิ์ยกระดับ (บัญชีผู้ดูแลระบบ) ประมาณ 1,200 บัญชีทั้งหมด

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

ฉันมีเวอร์ชั่นที่สั้นกว่าสำหรับคุณ:

ไม่ว่าจะทำอะไรง่ายหรือคล่องตัวเราเขียนโปรแกรมเพื่อทำแทนเรา

จากนั้นต่อสู้กับกระบวนการเมตาแทน

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

มีปัจจัยอื่นอีกมากมาย - บางคนพูดถึงที่นี่ - แต่ฉันต้องการเพิ่มประเด็นนี้ในการสนทนา

ขาดความรับผิดชอบ ... ผู้คนจะถูกฟ้องร้องเมื่อเครื่องบินตก อุตสาหกรรมซอฟต์แวร์ปฏิเสธความรับผิดชอบในข้อบกพร่องของซอฟต์แวร์ใด ๆ ดังนั้นการสร้างแรงจูงใจในการสร้างผลิตภัณฑ์ที่แข็งแกร่งและปลอดภัย

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

สิ่งนี้เป็นไปได้ แต่ยากทั้งในทางปฏิบัติและตามธรรมชาติของมนุษย์ในโครงการซอฟต์แวร์

ในส่วนอุตสาหกรรมอื่น ๆ ได้เรียนรู้วิธีที่ยากที่การแบ่งแยกแบบนี้เป็นสิ่งที่ดี ตัวอย่างเช่นถ้าคุณจะใช้เครื่องยนต์อากาศยานของ Rolls Royce คุณไม่จำเป็นต้องใช้สลักเกลียวและจุดยึดของ Rolls Royce พิเศษที่ใช้งานได้กับปีกที่มีการออกแบบเฉพาะและถ้าคุณพยายามเปลี่ยนไปใช้ Pratt และ Whitney คุณต้องออกแบบปีกทั้งใบจากพื้นดินขึ้นมา (ซึ่งในทางกลับกันต้องมีการออกแบบใหม่อย่างสมบูรณ์ของลำตัวซึ่งในทางกลับกันคุณจะต้องซื้อที่นั่งที่แตกต่างกันซึ่งในทางกลับกันคุณจะต้องซื้อระบบความบันเทิง ที่...). อาจมีการเชื่อมโยงบางอย่าง - คุณไม่สามารถสลับเครื่องยนต์ได้โดยไม่ต้องใส่ใจ - แต่โครงการขนาดใหญ่โดยทั่วไปจะทำงานได้ดีขึ้นเมื่อสิ่งต่าง ๆ ลดน้อยลง

ฉันยืนยันว่าโครงการซอฟต์แวร์ขนาดใหญ่ที่ออกแบบเป็นกลุ่มของโครงการซอฟต์แวร์ขนาดเล็กที่มีอินเตอร์เฟสที่สะอาดระหว่างกันจะไม่ล้มเหลวโดยเฉพาะอย่างยิ่งตราบใดที่โครงการขนาดใหญ่แก้ไขได้จริงโดยกลุ่มของโครงการขนาดเล็ก (เป็นไปได้ที่จะทำผิดพลาดในเรื่องนี้)

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

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

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

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

ดังนั้นโดยเนื้อแท้เหตุผลที่ทำให้การส่งมอบโครงการขนาดใหญ่และประมาณการระยะเวลาโครงการและ Roadmap เป็นเรื่องยากคือการพัฒนาซอฟต์แวร์และโดยเฉพาะอย่างยิ่งการออกแบบการทำงานนั้นเป็นสาขาที่ซับซ้อนมาก ความซับซ้อนเป็นปัญหาราก

คำจำกัดความของ "โครงการขนาดใหญ่" เบ้

โครงการขนาดใหญ่ทางเทคนิคสามารถส่งมอบตรงเวลาและไม่มีที่ติได้รับมันเป็นสิ่งที่ถูกสร้างขึ้นหลายครั้งหลายปีที่ผ่านมา

• โคลน Pac-Man
• เครื่องคิดเลข
• โปรแกรมแก้ไขข้อความ

ฉันแน่ใจว่าคุณกำลังคิดว่า ... "แต่นี่เป็นโครงการขนาดเล็ก ! โปรแกรมแก้ไขข้อความนั้นเรียบง่าย " ฉันจะไม่เห็นด้วยกับคุณ คอมพิวเตอร์มีความซับซ้อนอย่างมาก เพียงแค่ติดตั้งและตั้งค่าผู้ใช้บนระบบปฏิบัติการอาจเป็นเรื่องยากในบางครั้งและคุณไม่ได้เขียนระบบปฏิบัติการหรือสร้างฮาร์ดแวร์

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

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

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

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

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

Airbus A380ไม่ใช่โครงการที่ประสบความสำเร็จอย่างที่คุณพูดถึง ฉันทำงานใน บริษัท CAD / CAM และฉันได้รับแจ้งว่า (เรามี Airbus prioject ด้วย) ล่าช้าไปสองสามปีเพราะพวกเขาใช้ซอฟต์แวร์รุ่นต่างกันใน บริษัท อื่น นั่นคือส่วนต่าง ๆ ได้รับการออกแบบในส่วนต่าง ๆ ของโลก และเมื่อรวมเข้าด้วยกันพวกเขาก็รู้ว่าการออกแบบทั้งหมดไม่สามารถบูรณาการได้ดังนั้นพวกเขาจึงต้องออกแบบใหม่ในรุ่นเดียว ดังนั้นเมื่อมองดูแล้วฉันไม่คิดว่ามันจะประสบความสำเร็จ ถ้าก่อนหน้านี้เมื่อ 2-3 ปีที่ผ่านมามันจะเป็นเกมเปลี่ยนให้แอร์บัส

นอกจากนี้เกี่ยวกับซอฟต์แวร์ที่มีประสิทธิภาพคุณดูที่เครื่องบินรถยนต์ (ABS, EPS, ระบบควบคุมสภาพอากาศ ฯลฯ ) หรือกระสวยอวกาศซึ่งมีซอฟต์แวร์มากกว่า 50% ที่ใช้งานพวกเขาและเชื่อฉันว่าพวกเขาแข็งแกร่งมาก เป็นเพียงว่าเราอยู่ใกล้กับซอฟต์แวร์มากขึ้นและมีโปรแกรมซอฟต์แวร์อีกมากมายดังนั้นเราจึงเห็นข้อผิดพลาดเพิ่มเติม

เยี่ยมชม: http://www.globalprojectstrategy.com/lessons/case.php?id=23 และดูว่า Airbus A380 ประสบความสำเร็จมากเพียงใด

วิศวกรซอฟต์แวร์ที่นี่มีพื้นฐานด้านวิศวกรรมและภรรยาที่ทำงานด้านการก่อสร้าง เราได้พูดคุยกันมานาน (และโต้แย้ง) เกี่ยวกับความแตกต่างของงาน

วิศวกรรมซอฟแวร์เกี่ยวกับการออกแบบสิ่งใหม่ ๆ เกือบทุกสิ่งพื้นฐานได้กระทำในห้องสมุดโอเพนซอร์สที่ไหนสักแห่ง ในเกือบทุกงานที่วิศวกรซอฟต์แวร์จ้างเธอต้องออกแบบสิ่งที่ไม่มีอยู่

ในบางสิ่งบางอย่างเช่นการก่อสร้างและวิศวกรรมรูปแบบส่วนใหญ่สิ่งต่าง ๆ ที่จะเป็น 'ห้องสมุด' ในซอฟต์แวร์ได้รับการออกแบบมาอย่างสมบูรณ์แล้ว ต้องการสร้างหอคอยหรือไม่? เพียงคัดลอกและวางแผนจากโครงสร้างที่มีอยู่ด้วยการปรับเปลี่ยนเล็กน้อย

ในความเป็นจริงหนึ่งในเหตุผลหลักที่ฉันตัดสินใจไม่เป็นวิศวกรคือคุณใช้เวลาส่วนใหญ่ในการออกแบบปรับปรุงการประดิษฐ์ที่มีอยู่ 10% เมื่อเวลาเดียวกันสามารถใช้ในการเขียนโปรแกรมที่มองเห็นได้ชัดเจนขึ้นเช่นเครือข่ายสังคมออนไลน์ .

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

มองย้อนกลับไปว่ามาตรฐานมีการเปลี่ยนแปลงอย่างสมบูรณ์ตั้งแต่ชุดประกอบไปเป็น C ++ เป็น Java, JavaScript, C #, PHP และอื่น ๆ มีรหัสไม่มากที่สามารถรีไซเคิลได้เมื่อ 10 หรือ 20 ปีก่อน นี่เป็นสิ่งที่แตกต่างอย่างมากที่จะบอกว่า ... อุตสาหกรรมยานยนต์หรือวิชาการบินเมื่อคุณสามารถปรับปรุงการออกแบบจากหลายทศวรรษที่ผ่านมา

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

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

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

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

โครงการขนาดเล็กจะดีกว่า ภรรยาของฉันเคยขอให้ฉันทำงานใน บริษัท ใหญ่ มันจบลงด้วยการโต้แย้งว่า บริษัท ใหญ่ ๆ เป็น บริษัท ที่ไม่ดี ... สำหรับเธอ บริษัท ใหญ่มีทรัพยากรประสบการณ์การบริหารโครงการที่ใช้งานได้และกระบวนการที่เหมาะสม สำหรับฉันแล้ว บริษัท ยักษ์ใหญ่เป็นไดโนเสาร์ที่ใช้เวลาส่วนใหญ่ในการแก้ไขโค้ดทดสอบและจัดทำเอกสาร

ฉันเคยเห็นโครงการไอทีมูลค่าหลายล้านดอลลาร์ทำงานโดยคนน้อยกว่า 10 คน ผู้คนจำนวนมากจะชะลอโครงการและเพิ่มระบบราชการที่ไม่จำเป็น WhatsAppเป็นตัวอย่างของโครงการ 'เล็ก' ที่มีมูลค่าหลายพันล้านดอลลาร์ ไม่ใช่โครงการขนาดใหญ่ที่เป็นไปไม่ได้ แต่คุณไม่ต้องการคนหลายพันคนในการผลิตซอฟต์แวร์มูลค่าหลายพันล้านดอลลาร์

เหตุผลข้อหนึ่งที่ไม่ได้กล่าวถึงในคำถามอื่น ๆ คือเขตข้อมูลของซอฟท์แวร์สร้างนวัตกรรมด้วยความเร็วสูงซึ่งเกิดขึ้นได้ยากในโลกของวัสดุ

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

หากเครื่องบินถูกสร้างขึ้นเหมือนซอฟต์แวร์เราจะเปลี่ยนวัสดุด้วยรุ่นอื่น ๆ เพิ่มความจุและความเร็วเป็นสองเท่าทุก ๆ 18 เดือนแทนที่เทคโนโลยีเครื่องยนต์สำหรับรุ่นใหม่แต่ละรุ่นด้วยสิ่งที่คิดค้นขึ้นมาใหม่ในขณะที่เพิ่มความสามารถในการว่ายน้ำและค้นหามนุษย์ต่างดาว ชีวิต.

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

สำหรับฉันปัญหาหลักที่ใบหน้าวิศวกรรมซอฟต์แวร์คือการใช้เคสผู้ใช้และข้ามแพลตฟอร์ม

ใช้กรณี

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

ผู้ใช้งาน

ใครเป็นผู้ดำเนินงานเครื่องบิน นักบินนักบินนักบินผู้ดูแล (ถ้านับ) และผู้ควบคุมหอคอย พวกเขาเป็นมืออาชีพและมีคำอธิบายงานที่ชัดเจน ซอฟต์แวร์ถูกใช้โดย noobs และ dummies ไม่ต้องพูดถึงแฮ็กเกอร์และแครกเกอร์ที่ชั่วร้ายในขณะที่ยังต้องรวมกับโมดูลอื่น ๆ (เช่นOpenIDหรือGoogle AdSense ) หากเครื่องบินสามารถทำงานได้โดยหุ่นในขณะที่ยังคงรอดจากขีปนาวุธหรือโจรนินจาคุณสามารถพูดได้ว่าเครื่องบินนั้นมีคุณภาพเหมือนกันกับซอฟต์แวร์

ข้ามแพลตฟอร์ม

เครื่องบินบินอยู่บนท้องฟ้าของโลกเท่านั้น ฉันไม่แน่ใจเกี่ยวกับวิธีการจัดการสภาพภูมิอากาศที่มีหมอกหนาหรือมีลมแรงหรือร้อนเย็นและชื้น แต่เครื่องบินไม่ได้ถูกออกแบบให้บินในระดับที่แตกต่างกันแรงโน้มถ่วง (ฉันจะประหลาดใจถ้ามันสามารถบินไปดาวอังคาร ) บางครั้งแอปพลิเคชันจะต้องอยู่รอดได้ในหลายแพลตฟอร์มเช่น Internet Explorer, Google Chrome , FirefoxและSafariสำหรับเบราว์เซอร์ (ขออภัยOpera ) หรือ Windows XP / 7/8 หรือระดับ Linux สำหรับ OS ไม่ต้องพูดถึงอุปกรณ์มือถือและความละเอียดและทิศทางที่แตกต่างกัน

หากคุณคิดว่าอุตสาหกรรมอื่น ๆ ทำโครงการให้เสร็จโดยไม่มีเหตุการณ์คุณควรอ่านเรื่องราวเกี่ยวกับอาคาร Citigroup Center ที่สร้างขึ้นในปี 1977 แม้หลังจากผ่านไปเกือบ 7 ปีของการวางแผนและการก่อสร้างอาคารก็เสร็จสมบูรณ์ด้วยข้อบกพร่องด้านการออกแบบที่รุนแรง คาดว่าจะมีเหตุการณ์พายุทุก 16 ปี

กล่าวอีกนัยหนึ่งสำหรับทุก ๆ ปีที่ Citicorp Center กำลังยืนมีโอกาส 1 ใน 16 ที่จะยุบ

นักออกแบบดั้งเดิมไม่ได้ตระหนักถึงปัญหา แต่โชคดีที่มันถูกจับโดยนักเรียนที่เรียนอาคาร

ทุกอย่างดูเหมือนจะดี - จนกระทั่งในขณะที่ LeMessurier บอกว่าเขาได้รับโทรศัพท์ ตามที่ LeMessurier ในปี 1978 นักศึกษาสถาปัตยกรรมระดับปริญญาตรีติดต่อเขาด้วยการเรียกร้องอย่างกล้าหาญเกี่ยวกับอาคารของ LeMessurier: ที่ Citicorp Centre สามารถพัดไปในสายลม

การซ่อมแซมถูกสร้างขึ้นในคืนที่เกี่ยวข้องกับคนจำนวนน้อยที่สุดเพื่อรักษาความลับของข้อบกพร่องในการออกแบบ

มีการเตรียมแผนอพยพฉุกเฉินสำหรับรัศมี 10 บล็อกโดยรอบอาคาร

พวกเขาเชื่อมกันตลอดทั้งคืนและหยุดพักกลางวันเมื่ออาคารผู้โดยสารกลับไปทำงาน

เรื่องนี้ยังคงเป็นความลับจนกระทั่งผู้เขียนโจมอร์เกนสเติร์นได้ยินเรื่องนี้ในงานเลี้ยงและสัมภาษณ์ LeMessurier Morgenstern ได้ทำลายเรื่องราวใน The New Yorker ในปี 1995

ซึ่งทำให้เกิดคำถาม; จำนวนข้อบกพร่องร้ายแรงอื่น ๆ ในโครงการที่ได้รับการซ่อมแซมหรือเพิกเฉยโดยไม่เปิดเผยต่อสาธารณะ

• ข้อบกพร่องการออกแบบที่เกือบจะเช็ดตึกระฟ้า NYC (slate.com)
• ศูนย์ซิตี้กรุ๊ป (wikipedia.com)