The Mythical Man-Month after 20 Years

"ข้าพเจ้าไม่รู้วิธีอื่นในการตัดสินอนาคต นอกจากการดูจากอดีต" — แพทริก เฮนรี (PATRICK HENRY)

"คุณไม่มีวันวางแผนอนาคตได้จากการดูอดีต" — เอ็ดมันด์ เบิร์ก (EDMUND BURKE)

การฝ่าแก่งน้ำเชี่ยว (Shooting the Rapids)

Why Is There a Twentieth Anniversary Edition?

เครื่องบินส่งเสียงครางเบาๆ ท่ามกลางความมืดมิดในขณะที่มุ่งหน้าไปยังสนามบิน LaGuardia เมฆและแสงสลัวบดบังทัศนียภาพที่น่าสนใจไปจนหมด เอกสารที่ผมกำลังศึกษาก็ดูธรรมดาและน่าเบื่อ ทว่าผมกลับไม่รู้สึกเบื่อเลย ชายแปลกหน้าที่นั่งข้างๆ ผมกำลังอ่านหนังสือ The Mythical Man-Month และผมกำลังเฝ้ารอดูว่าเขาจะมีปฏิกิริยาอย่างไร ไม่ว่าจะด้วยคำพูดหรือท่าทาง ในที่สุดขณะที่เครื่องบินกำลังเคลื่อนตัวไปยังประตูทางออก ผมก็รอไม่ไหวแล้ว:

"หนังสือเล่มนั้นเป็นอย่างไรบ้างครับ? คุณแนะนำให้คนอื่นอ่านไหม?" "หึ! ไม่มีอะไรในเล่มที่ผมไม่รู้อยู่แล้วเลย"

ผมตัดสินใจที่จะไม่แนะนำตัวว่าผมเป็นใคร

ทำไม The Mythical Man-Month ถึงยังคงยืนยงอยู่ได้? ทำไมมันยังถูกมองว่าเกี่ยวข้องกับการปฏิบัติงานซอฟต์แวร์ในปัจจุบัน? ทำไมมันถึงมีผู้อ่านนอกแวดวงวิศวกรรมซอฟต์แวร์ โดยมีการวิจารณ์ การอ้างอิง และจดหมายจากนักกฎหมาย หมอ นักจิตวิทยา นักสังคมวิทยา ตลอดจนคนในแวดวงซอฟต์แวร์? หนังสือที่เขียนขึ้นเมื่อ 20 ปีก่อนเกี่ยวกับประสบการณ์การสร้างซอฟต์แวร์เมื่อ 30 ปีก่อน จะยังเกี่ยวข้องและมีประโยชน์ได้อย่างไร?

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

คำอธิบายที่สองที่มักถูกหยิบยกขึ้นมาคือ The Mythical Man-Month พูดถึงเรื่องซอฟต์แวร์เพียงแค่เป็นส่วนประกอบ แต่เนื้อหาหลักคือเรื่องของ "คนในทีม"...

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

ประวัติศาสตร์ของมนุษย์คือบทละครที่เรื่องราวต่างๆ ยังคงเหมือนเดิม บทพูดของเรื่องราวเหล่านั้นเปลี่ยนไปอย่างช้าๆ ตามการวิวัฒนาการของวัฒนธรรม และฉากบนเวทีก็เปลี่ยนไปตลอดเวลา นั่นคือเหตุผลที่เราเห็นตัวตนในศตวรรษที่ยี่สิบของเราสะท้อนอยู่ในผลงานของเชกสเปียร์ (Shakespeare), โฮเมอร์ (Homer) และในคัมภีร์ไบเบิล ดังนั้น ตราบใดที่หนังสือเล่มนี้เป็นเรื่องเกี่ยวกับ "คนและทีม" ความล้าสมัยย่อมเกิดขึ้นได้ช้า

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

The Central Argument: Conceptual Integrity and the Architect

ความสอดคล้องทางแนวคิด (Conceptual integrity): ผลิตภัณฑ์โปรแกรมที่สะอาดและสง่างามต้องนำเสนอโมเดลทางความคิด (mental model) ที่สอดคล้องกันแก่ผู้ใช้แต่ละคน ทั้งในเรื่องของแอปพลิเคชัน, กลยุทธ์ในการใช้งานแอปพลิเคชัน และยุทธวิธีของอินเทอร์เฟซผู้ใช้ที่จะใช้ในการระบุการกระทำและพารามิเตอร์ ความสอดคล้องทางแนวคิดของผลิตภัณฑ์ ตามที่ผู้ใช้รับรู้นั้น คือปัจจัยที่สำคัญที่สุดในเรื่องความง่ายในการใช้งาน (แน่นอนว่ามีปัจจัยอื่นๆ ด้วย เช่น ความเป็นเอกภาพของอินเทอร์เฟซผู้ใช้ของ Macintosh ในทุกแอปพลิเคชันคือตัวอย่างสำคัญ ยิ่งไปกว่านั้น เป็นไปได้ที่จะสร้างอินเทอร์เฟซที่สอดคล้องกันแต่กลับใช้งานได้ค่อนข้างลำบาก ลองพิจารณา MS-DOS ดูครับ)

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

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

สถาปนิก (The architect): ผมโต้แย้งในบทที่ 4 ถึง 7 ว่าการกระทำที่สำคัญที่สุดคือการมอบหมายให้จิตใจดวงใดดวงหนึ่งทำหน้าที่เป็นสถาปนิกของผลิตภัณฑ์...

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

การแยกสถาปัตยกรรมออกจากการนำไปใช้งานและการทำให้เป็นจริง (Separation of architecture from implementation and realization): เพื่อให้งานที่สำคัญของสถาปนิกเป็นไปได้จริง จำเป็นต้องแยกสถาปัตยกรรม (นิยามของผลิตภัณฑ์ที่ผู้ใช้สัมผัสได้) ออกจากการนำไปใช้งาน สถาปัตยกรรมปะทะการนำไปใช้งานช่วยกำหนดขอบเขตที่สะอาดระหว่างส่วนต่างๆ ของงานออกแบบ และมีงานมากมายให้ทำในแต่ละฝั่งของขอบเขตนั้น

การทำซ้ำของสถาปนิก (Recursion of architects): สำหรับผลิตภัณฑ์ที่มีขนาดใหญ่มาก จิตใจดวงเดียวไม่สามารถทำหน้าที่ด้านสถาปัตยกรรมทั้งหมดได้ แม้ว่าจะแยกงานด้านการนำไปใช้งานออกไปแล้วก็ตาม ดังนั้นจึงจำเป็นที่หัวหน้าสถาปนิกของระบบจะต้องแบ่งส่วนระบบออกเป็นระบบย่อยๆ ขอบเขตของระบบย่อยต้องอยู่ที่จุดที่อินเทอร์เฟซระหว่างระบบย่อยมีน้อยที่สุดและกำหนดได้อย่างเข้มงวดง่ายที่สุด จากนั้นแต่ละส่วนจะมีสถาปนิกของตนเอง ซึ่งต้องรายงานต่อหัวหน้าสถาปนิกของระบบในเรื่องที่เกี่ยวกับสถาปัตยกรรม ชัดเจนว่ากระบวนการนี้สามารถดำเนินไปแบบซ้ำซ้อน (recursively) ได้ตามต้องการ

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

The Second-System Effect: Featuritis and Frequency-Guessing

การออกแบบสำหรับกลุ่มผู้ใช้จำนวนมาก (Designing for large user sets): หนึ่งในผลพวงของการปฏิวัติคอมพิวเตอร์ส่วนบุคคลคือ ซอฟต์แวร์สำเร็จรูปกำลังเข้ามาแทนที่แอปพลิเคชันแบบสั่งทำมากขึ้นเรื่อยๆ อย่างน้อยก็ในแวดวงการประมวลผลข้อมูลทางธุรกิจ ยิ่งไปกว่านั้น แพ็กเกจซอฟต์แวร์มาตรฐานยังขายได้เป็นแสนหรือเป็นล้านชุด สถาปนิกของระบบสำหรับซอฟต์แวร์ที่มากับเครื่องจักรต้องออกแบบมาเพื่อกลุ่มผู้ใช้จำนวนมากที่ไม่มีรูปร่างชัดเจน แทนที่จะออกแบบเพื่อแอปพลิเคชันเดียวที่กำหนดนิยามได้ในบริษัทเดียว สถาปนิกจำนวนมากในปัจจุบันต้องเผชิญกับภารกิจนี้ แต่มันเป็นเรื่องย้อนแย้งที่การออกแบบเครื่องมืออเนกประสงค์นั้นยากกว่าการออกแบบเครื่องมือเฉพาะทางมากนัก เพียงเพราะเราต้องให้ความสำคัญกับความต้องการที่แตกต่างกันของผู้ใช้ที่หลากหลาย

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

สำหรับผลิตภัณฑ์ตลาดมวลชนที่อยู่รอดและพัฒนาผ่านมาหลายรุ่น สิ่งยั่วยวนนี้จะยิ่งรุนแรงเป็นพิเศษ ลูกค้านับล้านร้องขอฟีเจอร์นับร้อยอย่าง คำขอใดๆ ก็ตามถือเป็นหลักฐานว่า "ตลาดต้องการมัน" บ่อยครั้งที่สถาปนิกของระบบดั้งเดิมได้เลื่อนตำแหน่งไปสู่จุดที่สูงกว่าแล้ว และสถาปัตยกรรมก็ตกอยู่ในมือของคนที่มีประสบการณ์น้อยกว่าในการรักษาสมดุลของประโยชน์โดยรวมของผู้ใช้ บทวิจารณ์ Microsoft Word 6.0 เมื่อเร็วๆ นี้ระบุว่า "Word 6.0 อัดแน่นไปด้วยฟีเจอร์; การอัปเดตช้าลงเพราะภาระที่แบกไว้... Word 6.0 ทั้งใหญ่และช้า" โดยตั้งข้อสังเกตอย่างผิดหวังว่า Word 6.0 ต้องการ RAM ถึง 4 MB และกล่าวต่อไปว่าฟังก์ชันที่เพิ่มเข้ามามากมายนั้นหมายความว่า "แม้แต่เครื่อง Macintosh IIfx ก็แทบจะรับมือกับงานของ Word 6 ไม่ไหว"

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

  • พวกเขาคือใคร
  • พวกเขาต้องการอะไร
  • พวกเขา "คิดว่า" ตนเองต้องการอะไร
  • พวกเขาปรารถนาอะไร

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

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

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

แล้วเรื่อง "ผลกระทบจากระบบที่สอง" ล่ะ?: นักศึกษาที่ช่างสังเกตคนหนึ่งตั้งข้อสังเกตว่า The Mythical Man-Month แนะนำสูตรสำเร็จของหายนะ: คือการวางแผนส่งมอบเวอร์ชันที่สองของระบบใหม่ใดๆ (บทที่ 11) ซึ่งในบทที่ 5 กลับระบุว่าระบบที่สองคือระบบที่อันตรายที่สุดเท่าที่คนคนหนึ่งจะเคยออกแบบ ผมต้องยอมรับว่าเขา "จับไต๋" ผมได้จริงๆ

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

The Triumph of the WIMP Interface

หนึ่งในการพัฒนาที่น่าประทับใจที่สุดในวงการซอฟต์แวร์ตลอดสองทศวรรษที่ผ่านมา คือชัยชนะของอินเทอร์เฟซแบบ Windows, Icons, Menus, Pointing—หรือเรียกสั้นๆ ว่า WIMP ทุกวันนี้มันเป็นสิ่งที่คุ้นเคยมากจนไม่จำเป็นต้องอธิบาย แนวคิดนี้ถูกจัดแสดงต่อสาธารณะครั้งแรกโดย Doug Englebart และทีมงานจากสถาบันวิจัยสแตนฟอร์ดในงาน Western Joint Computer Conference ปี 1968 จากนั้นไอเดียก็ได้ส่งต่อไปยังศูนย์วิจัย Xerox Palo Alto Research Center (PARC) ซึ่งปรากฏออกมาเป็นเวิร์กสเตชันส่วนบุคคล Alto ที่พัฒนาโดย Bob Taylor และทีมงาน ต่อมา Steve Jobs ได้นำแนวคิดเหล่านี้ไปใช้ในเครื่อง Apple Lisa ซึ่งเป็นคอมพิวเตอร์ที่ช้าเกินกว่าจะรองรับแนวคิดเรื่องความง่ายในการใช้งานที่น่าตื่นเต้นของมันได้ ในที่สุด Jobs ก็นำแนวคิดเหล่านี้มาบรรจุไว้ใน Apple Macintosh ที่ประสบความสำเร็จในเชิงพาณิชย์ในปี 1985 และภายหลังได้ถูกนำไปใช้ใน Microsoft Windows สำหรับ IBM PC และเครื่องที่เข้ากันได้ ในที่นี้ผมจะใช้รุ่นของ Mac เป็นตัวอย่าง

ความสอดคล้องทางแนวคิดผ่านอุปมาอุปไมย (Conceptual integrity via a metaphor): WIMP เป็นตัวอย่างที่ยอดเยี่ยมของอินเทอร์เฟซผู้ใช้ที่มีความสอดคล้องทางแนวคิด ซึ่งบรรลุผลได้จากการนำโมเดลทางความคิดที่คุ้นเคยอย่าง "อุปมาแบบโต๊ะทำงาน" (desktop metaphor) มาใช้ และการขยายผลอย่างระมัดระวังและสอดคล้องกันเพื่อใช้ประโยชน์จากการสร้างภาพด้วยกราฟิกคอมพิวเตอร์ ตัวอย่างเช่น การตัดสินใจที่มีต้นทุนสูงแต่ถูกต้องในการซ้อนทับหน้าต่าง (overlay windows) แทนที่จะวางต่อเรียงกัน (tiling) นั้นเป็นสิ่งที่สอดคล้องโดยตรงกับอุปมานี้ ความสามารถในการปรับขนาดและรูปทรงของหน้าต่างคือการขยายผลที่สอดคล้องกันซึ่งมอบคุณนาประโยชน์ใหม่ๆ ให้แก่ผู้ใช้ผ่านสื่อกลางที่เป็นกราฟิกคอมพิวเตอร์ (กระดาษบนโต๊ะจริงๆ ไม่สามารถปรับขนาดและรูปทรงได้ง่ายขนาดนั้น) การลากและวาง (dragging and dropping) ก็สอดคล้องกับอุปมานี้โดยตรง การเลือกไอคอนโดยการชี้ด้วยเคอร์เซอร์ก็เป็นการเปรียบเทียบโดยตรงกับการหยิบของด้วยมือ ไอคอนและโฟลเดอร์ที่ซ้อนกันก็เป็นการจำลองเอกสารบนโต๊ะทำงานที่ซื่อสัตย์ รวมถึงถังขยะด้วย แนวคิดของการตัด คัดลอก และวาง ก็สะท้อนถึงสิ่งที่เราทำกับเอกสารบนโต๊ะทำงานจริงๆ อุปมานี้ถูกนำมาใช้อย่างซื่อสัตย์และการขยายผลก็มีความสอดคล้องกันมากเสียจนผู้ใช้ใหม่จะรู้สึก "ขัดใจ" อย่างมากกับแนวคิดที่ต้องลากไอคอนแผ่นดิสก์ไปที่ถังขยะเพื่อสั่งให้เครื่องคายแผ่นออกมา หากอินเทอร์เฟซนี้ไม่...

มีความสอดคล้องกันอย่างเกือบจะเป็นหนึ่งเดียวเช่นนี้ ความไม่สอดคล้อง (ที่ค่อนข้างแย่) นั้นก็คงจะไม่สร้างความขัดใจมากขนาดนี้

อินเทอร์เฟซแบบ WIMP ถูกบังคับให้ต้องก้าวข้ามอุปมาแบบโต๊ะทำงานไปที่จุดไหนบ้าง? ที่เห็นได้ชัดที่สุดมีสองประการคือ: เมนู (menus) และการทำงานด้วยมือเดียว เมื่อทำงานกับโต๊ะทำงานจริงๆ เราจะ "ทำ" บางอย่างกับเอกสาร แทนที่จะบอกให้ใครหรืออะไรบางอย่างไปทำ และเมื่อเราสั่งให้ใครทำอะไรบางอย่าง เรามักจะ "สร้าง" (พูดหรือเขียน) คำสั่งกริยาออกมาเอง มากกว่าที่จะเลือกจากรายการที่มีให้: "ช่วยเก็บไฟล์นี้ที" "ช่วยหาจดหมายโต้ตอบก่อนหน้านี้ให้หน่อย" "ช่วยส่งนี่ให้แมรี่จัดการด้วย" แต่น่าเสียดายที่การตีความคำสั่งภาษาอังกฤษแบบอิสระได้อย่างแม่นยำนั้นยังเกินความสามารถของเทคโนโลยีในปัจจุบัน ไม่ว่าจะเป็นคำสั่งแบบเขียนหรือแบบพูด ดังนั้นผู้ออกแบบอินเทอร์เฟซจึงต้องอยู่ห่างจากการกระทำโดยตรงต่อเอกสารไปสองก้าว พวกเขาจึงเลือกหยิบยกตัวอย่างหนึ่งของการเลือกคำสั่งจากโต๊ะทำงานปกติมาใช้อย่างชาญฉลาด นั่นคือ "ใบสั่งงานแบบพิมพ์สำเร็จ" (printed buck slip) ซึ่งผู้ใช้สามารถเลือกจากรายการคำสั่งที่มีจำกัดและมีความหมายมาตรฐาน แนวคิดนี้ถูกขยายผลไปสู่เมนูในแนวนอนที่เมื่อคลิกแล้วจะมีเมนูย่อยดึงลงมาในแนวตั้ง

การเปล่งคำสั่งและปัญหาเคอร์เซอร์สองตัว (Command utterances and the two-cursor problem): คำสั่งคือประโยคสั่งการ ซึ่งต้องมีคำกริยาเสมอและมักจะมีกรรมตรง สำหรับการกระทำใดๆ เราจำเป็นต้องระบุทั้งกริยาและนาม อุปมาเรื่องการชี้บอกว่า ในการระบุสองสิ่งพร้อมกัน เราควรมีเคอร์เซอร์ที่แตกต่างกันสองตัวบนหน้าจอ โดยแต่ละตัวถูกควบคุมด้วยเมาส์แยกกัน—ตัวหนึ่งในมือขวาและอีกตัวในมือซ้าย เพราะอย่างไรเสีย บนโต๊ะทำงานจริงๆ เราก็มักจะใช้ทั้งสองมือทำงาน (ถึงแม้มือหนึ่งมักจะทำหน้าที่จับของให้อยู่กับที่ ซึ่งบนโต๊ะทำงานคอมพิวเตอร์สิ่งนี้เกิดขึ้นโดยอัตโนมัติอยู่แล้ว) จิตใจของมนุษย์มีความสามารถในการทำงานสองมืออย่างแน่นอน เราใช้สองมือเป็นปกติในการพิมพ์ดีด ขับรถ หรือทำอาหาร แต่น่าเสียดายที่การมีเมาส์เพียงตัวเดียวก็ถือเป็นก้าวใหญ่สำหรับผู้ผลิตคอมพิวเตอร์ส่วนบุคคลแล้ว ยังไม่มีระบบเชิงพาณิชย์ใดที่รองรับการทำงานของเคอร์เซอร์เมาส์สองตัวพร้อมกันโดยใช้คนละมือ

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

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

ทางออกที่ชาญฉลาด (A brilliant solution): ต่อให้วงจรอิเล็กทรอนิกส์และซอฟต์แวร์สามารถจัดการเคอร์เซอร์สองตัวที่ทำงานพร้อมกันได้อย่างง่ายดาย แต่มันก็ยังมีปัญหาเรื่องการจัดวางพื้นที่ โต๊ะทำงานในอุปมาของ WIMP จริงๆ แล้วรวมถึงเครื่องพิมพ์ดีดด้วย และเราต้องจัดวางคีย์บอร์ดจริงๆ ลงในพื้นที่ทางกายภาพบนโต๊ะทำงานจริงๆ การมีทั้งคีย์บอร์ดและแผ่นรองเมาส์สองอันจะกินพื้นที่มากเกินระยะเอื้อมมือ ปัญหาเรื่องคีย์บอร์ดนี้สามารถเปลี่ยนให้เป็นโอกาสได้—ทำไมไม่ทำให้การทำงานสองมือมีประสิทธิภาพขึ้น โดยใช้มือหนึ่งบนคีย์บอร์ดเพื่อระบุคำกริยา และอีกมือหนึ่งบนเมาส์เพื่อเลือกคำนาม คราวนี้เคอร์เซอร์ก็จะค้างอยู่ในพื้นที่ข้อมูล ช่วยให้การเลือกคำนามที่อยู่ใกล้เคียงกันต่อเนื่องทำได้อย่างรวดเร็ว นี่คือประสิทธิภาพที่แท้จริง และคือพลังที่แท้จริงของผู้ใช้

พลังของผู้ใช้เทียบกับความง่ายในการใช้งาน (User power versus ease of use): อย่างไรก็ตาม ทางเลือกนั้นก็ต้องแลกกับสิ่งที่ทำให้เมนูใช้งานง่ายสำหรับมือใหม่—นั่นคือเมนูจะแสดงทางเลือกของคำกริยาที่ใช้งานได้ในแต่ละสถานะ เราสามารถซื้อซอฟต์แวร์สักชุด กลับมาบ้าน แล้วเริ่มใช้งานได้ทันทีโดยไม่ต้องเปิดคู่มือ เพียงแค่รู้ว่าเราซื้อมาทำอะไรแล้วทดลองคลิกคำกริยาต่างๆ ในเมนู หนึ่งในประเด็นที่ยากที่สุดที่สถาปนิกซอฟต์แวร์ต้องเผชิญคือการรักษาสมดุลระหว่างพลังของผู้ใช้กับความง่ายในการใช้งาน พวกเขาควรออกแบบเพื่อความเรียบง่ายสำหรับมือใหม่หรือผู้ใช้ชั่วคราว หรือเพื่อประสิทธิภาพสำหรับมืออาชีพ? คำตอบที่อุดมคติคือ "ให้ทั้งสองอย่าง" ในรูปแบบที่สอดคล้องกันทางแนวคิด—ซึ่งทำสำเร็จแล้วในอินเทอร์เฟซแบบ WIMP คำกริยาในเมนูที่ใช้บ่อยจะมีปุ่มลัดที่ใช้เพียงปุ่มเดียวร่วมกับปุ่มคำสั่ง ซึ่งส่วนใหญ่ถูกเลือกมาเพื่อให้กดได้ง่ายด้วยมือซ้ายเพียงมือเดียว ตัวอย่างเช่น ในเครื่อง Mac ปุ่มคำสั่ง (⌘) จะอยู่ใต้ปุ่ม Z และ X พอดี ดังนั้นการดำเนินการที่ใช้บ่อยที่สุดจึงถูกเข้ารหัสเป็น ⌘Z, ⌘X, ⌘C, ⌘V

การเปลี่ยนผ่านอย่างเป็นลำดับจากมือใหม่ไปสู่ผู้ใช้ระดับสูง (Incremental transition from novice to power user): ระบบคู่ในการระบุคำสั่งนี้ไม่เพียงแต่ตอบโจทย์ความต้องการที่ใช้ความพยายามในการเรียนรู้น้อยสำหรับมือใหม่ และความต้องการด้านประสิทธิภาพสำหรับผู้ใช้ระดับสูง แต่มันยังช่วยให้ผู้ใช้แต่ละคนสามารถเปลี่ยนโหมดการทำงานได้อย่างราบรื่น ตัวอักษรปุ่มลัดเหล่านี้จะแสดงอยู่ในเมนูข้างๆ คำกริยา เพื่อให้ผู้ใช้...

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

ความสำเร็จของการรวมเข้าด้วยกันโดยตรงในฐานะเครื่องมือบังคับใช้สถาปัตยกรรม (The success of direct incorporation as a device for enforcing architecture): อินเทอร์เฟซของ Mac ยังมีความโดดเด่นในอีกทางหนึ่ง โดยไม่ต้องมีการบังคับ ผู้ออกแบบทำให้มันกลายเป็นอินเทอร์เฟซมาตรฐานในทุกแอปพลิเคชัน รวมถึงแอปพลิเคชันส่วนใหญ่ที่เขียนโดยบริษัทภายนอก ดังนั้นผู้ใช้จึงได้รับความสอดคล้องเชิงแนวคิดในระดับอินเทอร์เฟซ ไม่เพียงแต่ในซอฟต์แวร์ที่มาพร้อมกับเครื่องเท่านั้น แต่ในแอปพลิเคชันทั้งหมด ความสำเร็จนี้เกิดขึ้นจากการที่ผู้ออกแบบ Mac สร้างอินเทอร์เฟซไว้ในหน่วยความจำแบบอ่านอย่างเดียว (ROM) ทำให้นักพัฒนาใช้งานมันได้ง่ายกว่าและเร็วกว่าการสร้างอินเทอร์เฟซเฉพาะตัวขึ้นมาเอง แรงจูงใจตามธรรมชาติเพื่อความเป็นเอกภาพนี้แพร่หลายมากพอที่จะสร้างมาตรฐานโดยพฤตินัย แรงจูงใจเหล่านี้ยังได้รับการสนับสนุนจากความมุ่งมั่นอย่างเต็มที่ของฝ่ายบริหารและการโน้มน้าวอย่างหนักจาก Apple นอกจากนี้ นักวิจารณ์อิสระในนิตยสารผลิตภัณฑ์ต่างๆ ที่ตระหนักถึงคุณค่ามหาศาลของความสอดคล้องเชิงแนวคิดข้ามแอปพลิเคชัน ยังช่วยส่งเสริมแรงจูงใจนี้โดยการวิจารณ์ผลิตภัณฑ์ที่ไม่ปฏิบัติตามอย่างรุนแรง นี่คือตัวอย่างที่ยอดเยี่ยมของเทคนิคที่แนะนำในบทที่ 6 เรื่องการบรรลุความเป็นเอกภาพโดยการส่งเสริมให้ผู้อื่นนำโค้ดของเราไปรวมไว้ในผลิตภัณฑ์ของเขาโดยตรง แทนที่จะพยายามให้พวกเขาสร้างซอฟต์แวร์ขึ้นมาเองตามข้อกำหนดของเรา

ชะตากรรมของ WIMP: ความล้าสมัย (The fate of WIMP: Obsolescence): แม้มันจะยอดเยี่ยมเพียงใด ผมคาดว่าอินเทอร์เฟซแบบ WIMP จะกลายเป็นโบราณวัตถุในอีกยุคสมัยหนึ่ง การชี้บอกจะยังคงเป็นวิธีในการระบุ "คำนาม" เมื่อเราสั่งการเครื่องจักร แต่การ "พูด" คือวิธีที่ถูกต้องที่สุดในการระบุ "คำกริยา" เครื่องมืออย่าง Voice Navigator สำหรับ Mac และ Dragon สำหรับ PC ได้มอบคุณสมบัตินี้ให้เห็นแล้วในปัจจุบัน

Don't Build One to Throw Away—The Waterfall Model Is Wrong!

ภาพสะพาน Tacoma Narrows Bridge หรือ "Galloping Gertie" ที่ลืมไม่ลง เปิดบทที่ 11 ซึ่งแนะนำอย่างรุนแรงว่า "จงวางแผนที่จะทิ้งมันไปหนึ่งชิ้น เพราะอย่างไรเสียคุณก็ต้องทำเช่นนั้นอยู่ดี" ตอนนี้ผมตระหนักแล้วว่าคำแนะนำนั้น "ผิด" ไม่ใช่เพราะมันรุนแรงเกินไป แต่เป็นเพราะมันเรียบง่ายเกินไป

ความผิดพลาดที่ใหญ่ที่สุดในแนวคิด "สร้างเพื่อทิ้ง" คือการที่มันยอมรับโมดูลแบบลำดับขั้นหรือ "โมเดลน้ำตก" (waterfall model) ของการสร้างซอฟต์แวร์โดยปริยาย โมเดลนี้มีที่มาจากแผนภูมิ Gantt ของกระบวนการที่เป็นขั้นตอน และมักจะถูกวาดดังรูปที่ 19.1 Winston Royce ได้ปรับปรุงโมเดลแบบลำดับขั้นนี้ในบทความคลาสสิกปี 1970 โดยเสนอให้:

  • มีการส่งข้อมูลกลับ (feedback) จากขั้นตอนหนึ่งไปยังขั้นตอนก่อนหน้าบ้าง
  • จำกัดการส่งข้อมูลกลับไว้เฉพาะขั้นตอนที่อยู่ก่อนหน้าทันทีเท่านั้น เพื่อควบคุมต้นทุนและความล่าช้าของกำหนดการที่เกิดขึ้น

เขาให้คำแนะนำแก่ผู้สร้างก่อนที่หนังสือเล่มนี้จะออกเสียอีกว่าให้ "สร้างมันสองครั้ง" บทที่ 11 ไม่ใช่บทเดียวที่แปดเปื้อนด้วยโมเดลน้ำตกแบบลำดับขั้นนี้ แต่มันแทรกซึมอยู่ทั่วทั้งเล่ม เริ่มต้นตั้งแต่กฎการจัดตารางเวลาในบทที่ 2 กฎพื้นฐานนั้นจัดสรร 1/3 ของกำหนดการให้กับการวางแผน, 1/6 ให้กับการเขียนโค้ด, 1/4 ให้กับการทดสอบส่วนประกอบ และ 1/4 ให้กับการทดสอบระบบ

รูปที่ 19.1 โมเดลน้ำตกของการสร้างซอฟต์แวร์

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

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

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

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

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

An Incremental-Build Model Is Better—Progressive Refinement

การสร้างระบบโครงร่างแบบต้นจนจบ (Building an end-to-end skeleton system): Harlan Mills ซึ่งทำงานในสภาพแวดล้อมของระบบเรียลไทม์ ได้สนับสนุนตั้งแต่ช่วงแรกๆ ว่าเราควรสร้างวงจรการตรวจสอบ (polling loop) พื้นฐานของระบบเรียลไทม์ โดยมีการเรียกใช้รูทีนย่อย (stubs) สำหรับฟังก์ชันทั้งหมด (รูปที่ 19.2) แต่เป็นเพียงรูทีนที่ว่างเปล่า คอมไพล์มันเสีย แล้วทดสอบมันดู มันจะรันวนไปวนมาโดยไม่ได้ทำอะไรเลย แต่ทำ "ความว่างเปล่านั้น" ได้อย่างถูกต้อง

รูปที่ 19.2

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

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

เนื่องจากเรามีระบบที่ทำงานได้ตลอดเวลา:

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

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

ตระกูลของพาร์นาส (Parnas Families)

David Parnas เป็นผู้นำทางความคิดที่สำคัญในด้านวิศวกรรมซอฟต์แวร์ตลอดช่วง 20 ปีที่ผ่านมา ทุกคนคุ้นเคยกับแนวคิดเรื่องการซ่อนข้อมูล (information-hiding) ของเขา แต่สิ่งที่คนคุ้นเคยน้อยกว่าแต่สำคัญมาก คือแนวคิดของ Parnas ในการออกแบบผลิตภัณฑ์ซอฟต์แวร์ให้เป็น "ตระกูลของผลิตภัณฑ์ที่เกี่ยวข้อง" (family of related products) เขาผลักดันให้ผู้ออกแบบคาดการณ์ทั้งการขยายในแนวระนาบและเวอร์ชันต่อๆ ไปของผลิตภัณฑ์ และนิยามฟังก์ชันหรือความแตกต่างของแพลตฟอร์มเพื่อสร้าง "ผังตระกูล" ของผลิตภัณฑ์ที่เกี่ยวข้องกัน (รูปที่ 19.3)

รูปที่ 19.3

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

แนวทาง "Build Every Night" ของ Microsoft (Microsoft's "Build Every Night" Approach)

James McCarthy อธิบายให้ผมฟังถึงกระบวนการผลิตที่ทีมของเขาและทีมอื่นๆ ที่ Microsoft ใช้ มันคือการเติบโตแบบเพิ่มส่วนที่ดำเนินการไปจนถึงบทสรุปเชิงตรรกะ เขากล่าวว่า:

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

วัน ทีมงานนักเขียนโปรแกรม-ผู้ทดสอบหนึ่งทีมหรือมากกว่าจะส่งโมดูล (check in) พร้อมฟังก์ชันใหม่ๆ เข้ามา หลังจากการสร้างทุกครั้ง เราจะมีระบบที่รันได้เสมอ หากการสร้างล้มเหลว (build breaks) เราจะหยุดกระบวนการทั้งหมดจนกว่าจะพบปัญหาและแก้ไขได้ ตลอดเวลาทุกคนในทีมจะทราบสถานะของโครงการ

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

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

การสร้างแบบเพิ่มส่วนและการสร้างต้นแบบที่รวดเร็ว (Incremental-Build and Rapid Prototyping)

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

Harel นิยามคำว่า "ต้นแบบ" (prototype) ไว้อย่างมีประโยชน์ว่า:

[เวอร์ชันของโปรแกรมที่] สะท้อนเฉพาะการตัดสินใจออกแบบที่เกิดขึ้นในกระบวนการจัดทำโมเดลเชิงแนวคิดเท่านั้น และไม่ใช่การตัดสินใจที่ขับเคลื่อนด้วยความกังวลในเรื่องการนำไปใช้งาน

เป็นไปได้ที่จะสร้างต้นแบบที่ไม่เป็นส่วนหนึ่งของผลิตภัณฑ์ที่จะเติบโตไปสู่การส่งมอบเลย ตัวอย่างเช่น เราอาจสร้าง "ต้นแบบอินเทอร์เฟซ" ที่ไม่มีฟังก์ชันโปรแกรมจริงๆ อยู่ข้างหลัง มีเพียงเครื่องจักรสถานะจำกัด (finite-state machine) ที่ทำให้มันดูเหมือนจะทำงานตามขั้นตอนได้ เราสามารถสร้างต้นแบบและทดสอบอินเทอร์เฟซด้วยเทคนิค "พ่อมดแห่งออซ" (Wizard-of-Oz technique) โดยมีมนุษย์แอบจำลองการตอบสนองของระบบอยู่เบื้องหลัง การสร้างต้นแบบเช่นนี้มีประโยชน์มากในการรับข้อเสนอแนะจากผู้ใช้ในช่วงแรก แต่มันแยกส่วนชัดเจนจากการทดสอบผลิตภัณฑ์ที่จะส่งมอบจริง

ในทำนองเดียวกัน ผู้ลงมือทำอาจตัดสินใจสร้าง "แว่นเสมือน" (vertical slice) ของผลิตภัณฑ์ ซึ่งมีการสร้างชุดฟังก์ชันที่จำกัดอย่างสมบูรณ์ เพื่อให้แสงแดดส่องเข้าไปในจุดที่อาจมี "งูประสิทธิภาพ" (performance snakes) ซุ่มซ่อนอยู่ได้ตั้งแต่เนิ่นๆ

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

Parnas Was Right, and I Was Wrong about Information Hiding

ในบทที่ 7 ผมได้เปรียบเทียบแนวทางสองขั้วต่อคำถามที่ว่า สมาชิกในทีมแต่ละคนควรได้รับอนุญาตหรือควรได้รับการส่งเสริมให้รู้เกี่ยวกับงานออกแบบและโค้ดของคนอื่นๆ มากน้อยเพียงใด ในโครงการระบบปฏิบัติการ OS/360 เราตัดสินใจให้นักเขียนโปรแกรมทุกคนเห็นเนื้อหาทั้งหมด นั่นคือ นักเขียนโปรแกรมทุกคนมีสำเนาสมุดงานของโครงการ ซึ่งมีจำนวนรวมกันมากกว่า 10,000 หน้า

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

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

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

บทที่ 16 โต้แย้งประเด็นต่อไปนี้:

  • ความก้าวหน้าส่วนใหญ่ในอดีตของผลิตภาพซอฟต์แวร์มาจากการกำจัดความยากที่ไม่ใช่เนื้อแท้ (noninherent difficulties) เช่น ภาษาเครื่องที่ใช้งานยาก และเวลาดำเนินการแบบแบตช์ที่ล่าช้า

  • "ผลไม้ที่เก็บง่าย" (easy pickings) เหล่านี้เหลืออยู่ไม่มากแล้ว

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

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

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

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

How Mythical Is the Man-Month?

แบบจำลองและข้อมูลของ Boehm (Boehm's Model and Data)

ตลอดหลายปีที่ผ่านมา มีการศึกษาเชิงปริมาณมากมายเกี่ยวกับผลิตภาพซอฟต์แวร์และปัจจัยที่ส่งผลกระทบ โดยเฉพาะการแลกเปลี่ยนระหว่างจำนวนพนักงานในโครงการและกำหนดการ การศึกษาที่สำคัญที่สุดชิ้นหนึ่งทำโดย Barry Boehm จากโครงการซอฟต์แวร์ประมาณ 63 โครงการ ซึ่งส่วนใหญ่เป็นด้านการบินและอวกาศ และประมาณ 25 โครงการอยู่ที่ TRW หนังสือของเขาชื่อ Software Engineering Economics ไม่เพียงแต่บรรจุผลลัพธ์เท่านั้น แต่ยังมีชุดแบบจำลองต้นทุนที่เป็นประโยชน์และมีความครอบคลุมขึ้นเรื่อยๆ แม้ว่าค่าสัมประสิทธิ์ในแบบจำลองย่อมแตกต่างกันไปสำหรับซอฟต์แวร์เชิงพาณิชย์ทั่วไปและซอฟต์แวร์ด้านการบินและอวกาศที่สร้างตามมาตรฐานของรัฐบาล แต่แบบจำลองของเขาก็ได้รับการสนับสนุนจากข้อมูลจำนวนมหาศาล ผมคิดว่าหนังสือเล่มนี้จะเป็นหนังสือคลาสสิกที่มีประโยชน์ไปอีกนาน

ผลลัพธ์ของเขาช่วยยืนยันข้อความยืนยันใน The Mythical Man-Month ได้อย่างหนักแน่นว่า การแลกเปลี่ยนระหว่างคนและเดือนนั้นห่างไกลจากความสัมพันธ์แบบเส้นตรงมาก และเดือน-คนเป็นเรื่องเพ้อฝันจริงๆ ในฐานะมาตรวัดผลิตภาพ โดยเฉพาะอย่างยิ่ง เขาพบว่า:

  • มี "เวลาที่เหมาะสมที่สุดในเชิงต้นทุน" สำหรับกำหนดการส่งมอบครั้งแรก คือ $T = 2.5(MM)^{1/3}$ นั่นคือ เวลาที่เหมาะสมที่สุดในหน่วยเดือนจะแปรผันตามรากที่สามของความพยายามที่คาดหวังในหน่วยเดือน-คน ซึ่งเป็นตัวเลขที่อนุมานมาจากการประมานการขนาดและปัจจัยอื่นๆ ในแบบจำลองของเขา เส้นโค้งจำนวนพนักงานที่เหมาะสมที่สุดก็คือบทสรุปที่ตามมาจากกฎนี้
  • กราฟต้นทุนจะเพิ่มขึ้นอย่างช้าๆ เมื่อกำหนดการที่วางแผนไว้นั้นยาวกว่าจุดที่เหมาะสม คนที่มีเวลามากขึ้นก็มักจะใช้เวลามากขึ้น
  • กราฟต้นทุนจะพุ่งสูงขึ้นอย่างรวดเร็ว เมื่อกำหนดการที่วางแผนไว้นั้นสั้นกว่าจุดที่เหมาะสม
  • แทบจะไม่มีโครงการใดเลยที่ประสบความสำเร็จหากใช้เวลาน้อยกว่า 3/4 ของกำหนดการที่เหมาะสมที่สุดตามการคำนวณ ไม่ว่าจะมีจำนวนคนเข้ามาช่วยมากแค่ไหนก็ตาม! ผลลัพธ์ที่น่าอ้างอิงนี้มอบอาวุธที่แข็งแกร่งให้กับผู้จัดการซอฟต์แวร์ เมื่อผู้บริหารระดับสูงเรียกร้องให้รับปากในกำหนดการที่เป็นไปไม่ได้

กฎของบรูคส์เป็นจริงแค่ไหน?: มีการศึกษาอย่างละเอียดเพื่อประเมินความจริงของกฎของบรูคส์ (ซึ่งผมจงใจทำให้มันดูเรียบง่ายเกินจริง) ที่ว่า การเพิ่มกำลังคนในโครงการซอฟต์แวร์ที่ล่าช้าจะยิ่งทำให้มันล่าช้ามากขึ้น การวิเคราะห์ที่ดีที่สุดคือของ Abdel-Hamid และ Madnick ในหนังสือปี 1991 ที่มีคุณค่ามากชื่อ Software Project Dynamics: An Integrated Approach หนังสือเล่มนี้ได้พัฒนาแบบจำลองเชิงปริมาณของพลศาสตร์ของโครงการ บทที่เกี่ยวกับกฎของบรูคส์ได้ให้ข้อมูลเชิงลึกที่ละเอียดมากขึ้นว่าเกิดอะไรขึ้นภายใต้สมมติฐานต่างๆ ว่ามีการเพิ่มกำลังคนเมื่อไหร่ และเพิ่มอย่างไร

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

Stutzke พัฒนาแบบจำลองที่ง่ายกว่าเพื่อทำการสำรวจในทำนองเดียวกัน และได้ผลลัพธ์ที่คล้ายกัน เขาพัฒนาการวิเคราะห์โดยละเอียดเกี่ยวกับกระบวนการและต้นทุนในการปรับตัวของพนักงานใหม่ รวมถึงการที่พี่เลี้ยงต้องถูกดึงเวลาออกจากงานหลักของโครงการอย่างชัดเจน เขาได้ทดสอบแบบจำลองของเขากับโครงการจริงๆ ที่มีการเพิ่มกำลังคนเป็นสองเท่าได้สำเร็จและทำตามกำหนดการเดิมได้หลังจากที่เกิดความล่าช้าในช่วงกลางโครงการ เขาพิจารณาทางเลือกอื่นนอกเหนือจากการเพิ่มนักเขียนโปรแกรม โดยเฉพาะการทำงานล่วงเวลา (OT) สิ่งที่มีค่าที่สุดคือคำแนะนำในทางปฏิบัติมากมายว่าควรเพิ่มคน ฝึกอบรม และสนับสนุนด้วยเครื่องมืออย่างไร เพื่อลดผลกระทบจากการรบกวนให้น้อยที่สุด ที่น่าสังเกตเป็นพิเศษคือความเห็นของเขาที่ว่า คนใหม่ที่ถูกเพิ่มเข้ามาในช่วงท้ายของโครงการพัฒนาต้องเป็น "ผู้เล่นที่เป็นทีม" (team players) ที่ยินดีจะลุยงานและทำงานภายใต้กระบวนการที่มีอยู่ และต้องไม่พยายามที่จะเปลี่ยนหรือปรับปรุงกระบวนการนั้นด้วยตัวเอง!

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

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

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

People Are Everything (Well, Almost Everything)

ผู้อ่านบางคนพบว่าเป็นเรื่องแปลกที่ The Mythical Man-Month ทุ่มเทบทความส่วนใหญ่ไปกับแง่มุมด้านการบริหารจัดการของวิศวกรรมซอฟต์แวร์ แทนที่จะเป็นประเด็นทางเทคนิคที่มีอยู่มากมาย ความลำเอียงนี้ส่วนหนึ่งมาจากลักษณะบทบาทของผมในโครงการระบบปฏิบัติการ IBM OS/360 (ซึ่งตอนนี้คือ MVS/370) แต่ที่สำคัญกว่านั้น มันเกิดจากความเชื่อมั่นที่ว่าคุณภาพของ "คน" ในโครงการ รวมถึงองค์กรและการบริหารจัดการของพวกเขา คือปัจจัยแห่งความสำเร็จที่สำคัญกว่าเครื่องมือที่ใช้หรือแนวทางทางเทคนิคที่เลือก

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

พีเพิลแวร์ (Peopleware): ผลงานที่สำคัญอย่างยิ่งในช่วงไม่กี่ปีที่ผ่านมาคือหนังสือปี 1987 ของ DeMarco และ Lister ชื่อ Peopleware: Productive Projects and Teams วิทยานิพนธ์ที่เป็นรากฐานของหนังสือคือ "ปัญหาหลักของงานเราไม่ใช่เรื่องทางเทคโนโลยีเท่ากับเรื่องทางสังคมวิทยา" หนังสือเล่มนี้เต็มไปด้วยประโยคเด็ดๆ เช่น "หน้าที่ของผู้จัดการไม่ใช่การ 'ทำให้คนทำงาน' แต่เป็นการ 'ทำให้คนสามารถทำงานได้' " มันจัดการกับหัวข้อที่ดูเหมือนจะเป็นเรื่องธรรมดา เช่น พื้นที่ทำงาน, เฟอร์นิเจอร์, การรับประทานอาหารร่วมกันของทีม DeMarco และ Lister ได้ให้ข้อมูลจริงจาก Coding War Games ของพวกเขา ซึ่งแสดงให้เห็นความสัมพันธ์ที่น่าทึ่งระหว่างประสิทธิภาพการทำงานของนักเขียนโปรแกรมจากองค์กรเดียวกัน และระหว่างลักษณะของสถานที่ทำงานกับทั้งผลิตภาพและระดับของข้อบกพร่อง

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

ทำงานได้ดีขึ้น หรือ [ในทางกลับกัน] ช่วยให้คุณดึงดูดและรักษาคนเก่งๆ ไว้ได้มากขึ้น

ผมขอแนะนำหนังสือเล่มนี้อย่างยิ่งให้กับผู้อ่านทุกคนครับ

การย้ายโครงการ (Moving projects): DeMarco และ Lister ให้ความสำคัญอย่างมากกับการรวมตัวกันเป็นหนึ่งเดียวของทีม (team fusion) ซึ่งเป็นคุณสมบัติที่จับต้องไม่ได้แต่สำคัญยิ่ง ผมคิดว่าการที่ฝ่ายบริหารมองข้ามเรื่องการรวมตัวกันนี้เอง คือสาเหตุของความพร้อมที่จะ "ย้ายโครงการ" จากห้องปฏิบัติการหนึ่งไปยังอีกแห่งหนึ่งที่ผมมักสังเกตเห็นในบริษัทที่มีหลายสาขา ประสบการณ์และการสังเกตของผมจำกัดอยู่เพียงการย้ายโครงการประมาณครึ่งโหล และผมไม่เคยเห็นการย้ายครั้งไหนที่ประสบความสำเร็จเลย

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

The Power of Giving Up Power

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

โชคดีที่ปัญหานี้ไม่ได้เกิดขึ้นเฉพาะในองค์กรซอฟต์แวร์ และเหล่านักคิดที่ยิ่งใหญ่ได้เคยศึกษาเรื่องนี้ไว้แล้ว E. F. Schumacher ในหนังสือคลาสสิกของเขาชื่อ Small is Beautiful: Economics as if People Mattered ได้เสนอทฤษฎีการจัดองค์กรธุรกิจเพื่อเพิ่มความคิดสร้างสรรค์และความสุขของพนักงานให้สูงสุด สำหรับหลักการแรก เขาเลือก "หลักการทำหน้าที่เสริม" (Principle of Subsidiary Function) จากจดหมายเวียนของสมเด็จพระสันตะปาปาปิอุสที่ 11:

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

Schumacher ตีความต่อไปว่า:

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

โครงสร้างเช่นนี้จะบรรลุผลได้อย่างไร? ... องค์กรขนาดใหญ่จะประกอบด้วยหน่วยงานกึ่งอิสระมากมาย ซึ่งเราอาจเรียกว่า "บริษัทเสมือน" (quasi-firms) แต่ละหน่วยงานจะมีเสรีภาพอย่างมาก เพื่อให้...

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

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

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

"แต่ละทีมพัฒนาฟีเจอร์ (30-40 คน) เป็นเจ้าของชุดฟีเจอร์ของตนเอง เป็นเจ้าของกำหนดการ และแม้แต่กระบวนการว่าจะนิยาม สร้าง และส่งมอบอย่างไร ทีมประกอบด้วยผู้เชี่ยวชาญสี่หรือห้าด้าน รวมถึงการสร้าง การทดสอบ และการเขียนเอกสาร ทีมเป็นผู้จัดการความขัดแย้งกันเอง บอสไม่ต้องเข้ามาจัดการ ผมไม่สามารถเน้นย้ำได้มากพอถึงความสำคัญของการมอบอำนาจ (empowerment) การที่ทีมต้องรับผิดชอบต่อความสำเร็จของตนเอง"

Earl Wheeler อดีตหัวหน้าธุรกิจซอฟต์แวร์ของ IBM ที่เกษียณอายุแล้ว เล่าให้ผมฟังถึงประสบการณ์ของเขาในการเริ่มมอบอำนาจลงสู่เบื้องล่าง ซึ่งแต่เดิมเคยรวมศูนย์อยู่ที่ฝ่ายบริหารระดับแผนกของ IBM มาอย่างยาวนาน:

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

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

What's the Biggest New Surprise? Millions of Computers

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

การปฏิวัติไมโครคอมพิวเตอร์ได้เปลี่ยนวิธีที่ทุกคนใช้งานคอมพิวเตอร์ Schumacher ได้ระบุความท้าทายไว้เมื่อกว่า 20 ปีก่อนว่า:

อะไรคือสิ่งที่เราต้องการจริงๆ จากนักวิทยาศาสตร์และนักเทคโนโลยี? ผมควรจะตอบว่า: เราต้องการวิธีการและอุปกรณ์ที่:

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

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

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

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

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

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

ท้ายที่สุด สื่อสร้างสรรค์รูปแบบใหม่ๆ ได้เกิดขึ้นได้เพราะความแพร่หลายของคอมพิวเตอร์ส่วนบุคคล ไฮเปอร์เท็กซ์ (Hypertexts) ที่เสนอโดย Vannevar Bush ในปี 1945 สามารถใช้งานได้จริงเฉพาะบนคอมพิวเตอร์เท่านั้น งานนำเสนอและประสบการณ์มัลติมีเดียเคยเป็นเรื่องใหญ่—ที่ยุ่งยากเกินไป—ก่อนที่จะมีคอมพิวเตอร์ส่วนบุคคลและซอฟต์แวร์ที่รุ่มรวยและราคาถูก ระบบสภาพแวดล้อมเสมือนจริง (virtual-environment systems) ซึ่งปัจจุบันยังไม่ราคาถูกหรือแพร่หลายนัก แต่กำลังจะเป็นเช่นนั้น และมันจะกลายเป็นสื่อสร้างสรรค์อีกรูปแบบหนึ่ง

การปฏิวัติไมโครคอมพิวเตอร์ได้เปลี่ยนวิธีที่ทุกคนสร้างซอฟต์แวร์ กระบวนการซอฟต์แวร์ในทศวรรษ 1970 เองก็ได้เปลี่ยนไปเพราะการปฏิวัติไมโครโปรเซสเซอร์และความก้าวหน้าของเทคโนโลยีที่ส่งเสริมมัน ความยากที่เป็นส่วนประกอบภายนอก (accidental difficulties) ของกระบวนการสร้างซอฟต์แวร์เหล่านั้นหลายอย่างได้ถูกกำจัดไปแล้ว คอมพิวเตอร์ส่วนบุคคลที่รวดเร็วกลายเป็นเครื่องมือปกติของนักพัฒนาซอฟต์แวร์ จนทำให้แนวคิดเรื่องเวลาดำเนินการ (turnaround time) แทบจะเป็นสิ่งที่ล้าสมัยไปแล้ว คอมพิวเตอร์ส่วนบุคคลในปัจจุบันไม่เพียงแต่เร็วกว่าซูเปอร์คอมพิวเตอร์ในปี 1960 แต่มันยังเร็วกว่าเวิร์กสเตชัน Unix ในปี 1985 เสียอีก ทั้งหมดนี้หมายความว่าการคอมไพล์นั้นทำได้อย่างรวดเร็วแม้ในเครื่องที่สเปกต่ำที่สุด และหน่วยความจำขนาดใหญ่ช่วยกำจัดการรอคอยการเชื่อมโยงข้อมูลบนดิสก์ นอกจากนี้หน่วยความจำขนาดใหญ่ยังช่วยให้สามารถเก็บตารางสัญลักษณ์ (symbol tables) ไว้ในหน่วยความจำร่วมกับโค้ดวัตถุ (object code) ได้ ทำให้การแก้ไขข้อผิดพลาดในระดับภาษาระดับสูงโดยไม่ต้องคอมไพล์ใหม่กลายเป็นเรื่องปกติ

ในช่วง 20 ปีที่ผ่านมา เราผ่านพ้นยุคของการใช้การแบ่งเวลา (time-sharing) ในฐานะระเบียบวิธีหลักสำหรับการสร้างซอฟต์แวร์มาเกือบทั้งหมดแล้ว ในปี 1975 การแบ่งเวลาเพิ่งจะเข้ามาแทนที่การประมวลผลแบบแบตช์ในฐานะเทคนิคที่แพร่หลายที่สุด เครือข่ายในตอนนั้นถูกใช้เพื่อให้ผู้สร้างซอฟต์แวร์เข้าถึงไฟล์ที่ใช้ร่วมกันและเข้าถึงเครื่องจักรส่วนกลางที่ทรงพลังสำหรับการคอมไพล์ การเชื่อมโยง และการทดสอบ แต่ในปัจจุบัน เวิร์กสเตชันส่วนบุคคลทำหน้าที่เป็นเครื่องมือประมวลผลเอง และเครือข่ายมีหน้าที่หลักในการให้การเข้าถึงไฟล์ที่ใช้ร่วมกันซึ่งเป็นผลงานที่ทีมกำลังพัฒนาอยู่ ระบบไคลเอนต์-เซิร์ฟเวอร์ (Client-server systems) ทำให้การเข้าถึงส่วนกลางเพื่อส่งงาน (check-in) สร้างระบบ (build) และการรันกรณีทดสอบกลายเป็นกระบวนการที่แตกต่างและเรียบง่ายขึ้น

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

Whole New Software Industry—Shrink-Wrapped Software

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

อุตสาหกรรมซอฟต์แวร์แบบดั้งเดิม (The classical software industry): ในปี 1975 อุตสาหกรรมซอฟต์แวร์ประกอบด้วยส่วนประกอบหลายอย่างที่ระบุตัวตนได้ชัดเจนและแตกต่างกันบ้าง ซึ่งทั้งหมดนี้ยังคงมีอยู่ในปัจจุบัน:

  • ผู้ผลิตคอมพิวเตอร์ (Computer vendors): ผู้จัดหาระบบปฏิบัติการ คอมไพเลอร์ และโปรแกรมอรรถประโยชน์สำหรับผลิตภัณฑ์ของตน
  • ผู้ใช้แอปพลิเคชัน (Application users): เช่น แผนก MIS ของบริษัทสาธารณูปโภค ธนาคาร บริษัทประกันภัย และหน่วยงานรัฐบาล ซึ่งสร้างซอฟต์แวร์แพ็กเกจเพื่อใช้งานเองภายในองค์กร
  • ผู้สร้างแอปพลิเคชันตามสั่ง (Custom application builders): ผู้รับจ้างสร้างซอฟต์แวร์เฉพาะทางสำหรับผู้ใช้ หลายรายเชี่ยวชาญด้านแอปพลิเคชันเพื่อการป้องกันประเทศ ซึ่งมีข้อกำหนด มาตรฐาน และกระบวนการทางการตลาดที่เฉพาะตัว
  • ผู้พัฒนาแพ็กเกจเชิงพาณิชย์ (Commercial package developers): ซึ่งในเวลานั้นเน้นการพัฒนาแอปพลิเคชันขนาดใหญ่สำหรับตลาดเฉพาะทาง เช่น แพ็กเกจวิเคราะห์ทางสถิติ และระบบ CAD

Tom DeMarco สังเกตเห็นการแตกส่วนของอุตสาหกรรมซอฟต์แวร์แบบดั้งเดิม โดยเฉพาะในส่วนของผู้ใช้แอปพลิเคชัน:

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

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

โลกของระบบปฏิบัติการได้รวมตัวกัน (Operating system worlds have coalesced): ในปี 1975 ระบบปฏิบัติการมีอยู่มากมาย: ผู้ผลิตฮาร์ดแวร์แต่ละรายมีระบบปฏิบัติการที่เป็นกรรมสิทธิ์อย่างน้อยหนึ่งระบบต่อหนึ่งสายผลิตภัณฑ์ หลายรายมีถึงสองระบบ ปัจจุบันทุกอย่างช่างแตกต่างกันนัก! "ระบบเปิด" (Open systems) คือคำขวัญ และมีสภาพแวดล้อมระบบปฏิบัติการที่สำคัญเพียงห้าแห่งที่ผู้คนนิยมทำตลาดแอปพลิเคชันแพ็กเกจ (เรียงตามลำดับเวลา):

  • สภาพแวดล้อม IBM MVS และ VM
  • สภาพแวดล้อม DEC VMS
  • สภาพแวดล้อม Unix (ในรูปแบบต่างๆ)
  • สภาพแวดล้อม IBM PC ไม่ว่าจะเป็น DOS, OS/2 หรือ Windows
  • สภาพแวดล้อม Apple Macintosh

อุตสาหกรรมซอฟต์แวร์สำเร็จรูป (The shrink-wrapped industry): สำหรับนักพัฒนาในอุตสาหกรรมซอฟต์แวร์สำเร็จรูป เศรษฐศาสตร์นั้นแตกต่างจากอุตสาหกรรมแบบดั้งเดิมอย่างสิ้นเชิง: ต้นทุนการพัฒนาจะถูกหารด้วยจำนวนยอดขายมหาศาล ขณะที่ต้นทุนการบรรจุหีบห่อและการตลาดกลับดูเป็นเรื่องใหญ่ขึ้นมา ในอุตสาหกรรมการพัฒนาแอปพลิเคชันภายในองค์กรแบบดั้งเดิม กำหนดการและรายละเอียดของฟังก์ชันสามารถเจรจากันได้ แต่ต้นทุนการพัฒนาอาจเจรจาไม่ได้ ในทางตรงกันข้าม ในตลาดเปิดที่มีการแข่งขันกันอย่างดุเดือด กำหนดการและฟังก์ชันกลับเป็นตัวกำหนดต้นทุนการพัฒนาเกือบทั้งหมด ดังที่คาดไว้ เศรษฐศาสตร์ที่แตกต่างกันอย่างสิ้นเชิงนี้ได้ก่อให้เกิดวัฒนธรรมการเขียนโปรแกรมที่แตกต่างกันค่อนข้างมาก อุตสาหกรรมแบบดั้งเดิมมักจะถูกครอบงำโดยบริษัทขนาดใหญ่ที่มีสไตล์การบริหารและกระบวนการทำงานที่เป็นระบบ...

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

Buy and Build—Shrink-Wrapped Packages As Components

ความทนทานและผลิตภาพของซอฟต์แวร์ที่ดีขึ้นอย่างก้าวกระโดดจะเกิดขึ้นได้ก็ต่อเมื่อมีการเลื่อนระดับขึ้นไป และสร้างโปรแกรมโดยการประกอบโมดูลหรือวัตถุเข้าด้วยกัน แนวโน้มที่น่าสนใจอย่างยิ่งคือการใช้แพ็กเกจซอฟต์แวร์ตลาดมวลชนเป็นแพลตฟอร์มในการสร้างผลิตภัณฑ์ที่รุ่มรวยและปรับแต่งได้มากขึ้น ระบบติดตามรถบรรทุกถูกสร้างขึ้นบนแพ็กเกจฐานข้อมูลและการสื่อสารแบบสำเร็จรูป ระบบสารสนเทศนักศึกษาก็เช่นกัน หน้าโฆษณาในนิตยสารคอมพิวเตอร์นำเสนอ HyperCard stacks นับร้อยชุด และเทมเพลตที่ปรับแต่งสำหรับ Excel, ฟังก์ชันพิเศษนับสิบรายการในภาษา Pascal สำหรับ MiniCad หรือฟังก์ชันใน AutoLisp สำหรับ AutoCad

เมตาโปรแกรมมิง (Metaprogramming): การสร้าง HyperCard stacks, เทมเพลต Excel หรือฟังก์ชัน MiniCad บางครั้งเรียกว่า "เมตาโปรแกรมมิง" ซึ่งเป็นการสร้างชั้นสื่อกลางใหม่ที่ปรับแต่งฟังก์ชันการทำงานสำหรับกลุ่มผู้ใช้เฉพาะของแพ็กเกจนั้นๆ แนวคิดเมตาโปรแกรมมิงไม่ใช่เรื่องใหม่ เพียงแค่กลับมาได้รับความนิยมอีกครั้งและเปลี่ยนชื่อใหม่ ในช่วงต้นทศวรรษ 1960 ผู้ผลิตคอมพิวเตอร์และแผนกสารสนเทศ (MIS) ขนาดใหญ่หลายแห่งมีกลุ่มผู้เชี่ยวชาญเล็กๆ ที่สร้าง "ภาษาโปรแกรมแอปพลิเคชัน" ทั้งภาษาขึ้นมาจากแมโครในภาษาแอสเซมบลี แผนก MIS ของ Eastman Kodak มีภาษาแอปพลิเคชันที่ใช้ภายในซึ่งกำหนดขึ้นบน IBM 7080 macroassembler ในทำนองเดียวกันกับ Queued Telecommunications Access Method ของ IBM OS/360 เราอาจอ่านโปรแกรมโทรคมนาคมที่ดูเหมือนจะเป็นภาษาแอสเซมบลีได้หลายหน้าก่อนที่จะเจอคำสั่งในระดับภาษาเครื่องจริงๆ ทุกวันนี้ "ชิ้นส่วน" ที่เหล่านักเมตาโปรแกรมนำเสนอมีขนาดใหญ่กว่าแมโครเหล่านั้นหลายเท่า การพัฒนาของตลาดรองเหล่านี้เป็นเรื่องที่น่าส่งเสริมอย่างยิ่ง—ในขณะที่เรามัวแต่รอให้เกิดตลาดสำหรับคลาส C++ ที่มีประสิทธิภาพ แต่ตลาดของเมตาโปรแกรมที่นำกลับมาใช้ใหม่ได้กลับเติบโตขึ้นอย่างเงียบๆ

สิ่งนี้เป็นการจัดการกับ "เนื้อแท้" อย่างแท้จริง เนื่องจากการสร้างงานบนพื้นฐานของแพ็กเกจยังไม่ส่งผลกระทบต่อพนักงาน MIS ทั่วไปในปัจจุบันมากนัก...

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

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

ถ้าอย่างนั้นเราต้องการอะไร? เราสามารถระบุผู้ใช้แพ็กเกจสำเร็จรูปได้เป็นสี่ระดับ:

  • ผู้ใช้แบบตามสภาพ (as-is user): ผู้ที่ใช้งานแอปพลิเคชันในรูปแบบตรงไปตรงมา และพึงพอใจกับฟังก์ชันและอินเทอร์เฟซที่นักออกแบบเตรียมไว้ให้
  • นักเมตาโปรแกรม (metaprogrammer): ผู้ที่สร้างเทมเพลตหรือฟังก์ชันต่อยอดบนแอปพลิเคชันเดียว โดยใช้อินเทอร์เฟซที่เตรียมไว้ให้ โดยมีวัตถุประสงค์หลักเพื่อช่วยลดภาระงานให้แก่ผู้ใช้ปลายทาง
  • ผู้เขียนฟังก์ชันภายนอก (external function writer): ผู้ที่เขียนโค้ดเพิ่มฟังก์ชันเข้าไปในแอปพลิเคชันโดยตรง สิ่งเหล่านี้คือคำสั่งพื้นฐานใหม่ของภาษาแอปพลิเคชันซึ่งจะเรียกไปยังโมดูลโค้ดที่แยกต่างหากซึ่งเขียนด้วยภาษาอเนกประสงค์ เราต้องการความสามารถในการเชื่อมต่อฟังก์ชันใหม่เหล่านี้เข้ากับแอปพลิเคชันในรูปแบบของคำสั่งที่ถูกดักจับ (intercepted commands), การเรียกกลับ (callbacks), หรือฟังก์ชันที่ถูกนิยามทับ (overloaded functions)
  • นักเมตาโปรแกรมที่ใช้หนึ่งแอปพลิเคชัน หรือโดยเฉพาะอย่างยิ่งหลายแอปพลิเคชัน เป็นส่วนประกอบในระบบที่ใหญ่กว่า: นี่คือผู้ใช้ที่ความต้องการยังไม่ได้รับการตอบสนองที่ดีนักในปัจจุบัน และเป็นรูปแบบการใช้งานที่สัญญาว่าจะช่วยเพิ่มประสิทธิภาพอย่างมหาศาลในการสร้างแอปพลิเคชันใหม่ๆ

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

แอปพลิเคชันบางตัว เช่น FoxPro มี "รูหนอน" (wormholes) ที่อนุญาตให้ส่งชุดคำสั่งเข้าไปได้ แต่ข้อมูลที่ได้รับกลับมานั้นมีน้อยมากและไม่ได้ถูกแจกแจง รูหนอนเหล่านี้เป็นการแก้ไขเฉพาะหน้า (ad hoc fix) สำหรับความต้องการที่แท้จริงซึ่งต้องการโซลูชันที่ถูกออกแบบมาเป็นมาตรฐานสากล การมี "ภาษาสคริปต์" (scripting language) เพื่อควบคุมปฏิสัมพันธ์ท่ามกลางกลุ่มของแอปพลิเคชันนั้นมีพลังมหาศาล Unix เป็นระบบแรกที่จัดหาฟังก์ชันประเภทนี้ให้ผ่านท่อ (pipes) และรูปแบบไฟล์ข้อความ ASCII มาตรฐาน ปัจจุบัน AppleScript เป็นตัวอย่างที่ดีในเรื่องนี้

The State and Future of Software Engineering

ผมเคยถาม Jim Ferrell หัวหน้าภาควิชาวิศวกรรมเคมีที่มหาวิทยาลัยนอร์ทแคโรไลนาสเตต ให้ช่วยเล่าประวัติของวิศวกรรมเคมีที่แตกต่างจากวิชาเคมีปกติ เขาจึงเล่าเรื่องราวที่น่าทึ่งแบบสดๆ นานถึงหนึ่งชั่วโมง เริ่มต้นจากการมีอยู่ของกระบวนการผลิตที่หลากหลายมาตั้งแต่สมัยโบราณสำหรับผลิตภัณฑ์หลายชนิด ตั้งแต่เหล็กไปจนถึงขนมปังและน้ำหอม เขาเล่าว่าศาสตราจารย์ Arthur D. Little ได้ก่อตั้งภาควิชาเคมีอุตสาหกรรมที่ MIT ในปี 1918 เพื่อค้นหา พัฒนา และสอนพื้นฐานทางเทคนิคร่วมกันที่ทุกกระบวนการมีเหมือนกัน ในช่วงแรกมีเพียงกฎพื้นฐาน (rules of thumb) จากนั้นก็ตามมาด้วยแผนภูมิที่สร้างจากประสบการณ์ (empirical nomograms) สูตรสำหรับการออกแบบชิ้นส่วนเฉพาะอย่าง และสุดท้ายจึงเป็นแบบจำลองทางคณิตศาสตร์สำหรับการถ่ายโอนความร้อน มวล และโมเมนตัมในถังบรรจุเดี่ยว ในขณะที่เรื่องราวของ Ferrell ดำเนินไป ผมรู้สึกทึ่งกับจุดคู่ขนานมากมายระหว่างการพัฒนาของวิศวกรรมเคมีและวิศวกรรมซอฟต์แวร์ที่เกิดขึ้นตามมาหลังจากนั้นเกือบ 50 ปีพอดี

Parnas เคยตำหนิผมที่เขียนเรื่องเกี่ยวกับวิศวกรรมซอฟต์แวร์เลย เขาเปรียบเทียบสาขาซอฟต์แวร์กับวิศวกรรมไฟฟ้า และรู้สึกว่าเป็นการทึกทักเอาเองที่จะเรียกสิ่งที่เราทำว่าวิศวกรรม เขาอาจจะพูดถูกที่ว่าสาขานี้จะไม่มีวันพัฒนาไปสู่วิชาชีพวิศวกรรมที่มีฐานทางคณิตศาสตร์ที่แม่นยำและครอบคลุมเท่ากับวิศวกรรมไฟฟ้า เพราะอย่างไรเสีย วิศวกรรมซอฟต์แวร์ก็เหมือนกับวิศวกรรมเคมี ที่เกี่ยวข้องกับปัญหาที่ไม่เป็นเส้นตรงของการขยายขนาดไปสู่กระบวนการในระดับอุตสาหกรรม และเหมือนกับวิศวกรรมอุตสาหการที่มักถูกทำให้สับสนโดยความซับซ้อนของพฤติกรรมมนุษย์อยู่เสมอ อย่างไรก็ตาม ลำดับเหตุการณ์และช่วงเวลาของการพัฒนาวิศวกรรมเคมีทำให้ผมเชื่อว่า วิศวกรรมซอฟต์แวร์ในวัย 27 ปีอาจจะยังไม่สิ้นหวัง แต่อาจเป็นเพียงความไม่บรรลุนิติภาวะ เหมือนที่วิศวกรรมเคมีเคยเป็นในปี 1945 หลังสงครามโลกครั้งที่ 2 เท่านั้นที่วิศวกรเคมีเริ่มจัดการกับพฤติกรรมของระบบการไหลต่อเนื่องที่เชื่อมต่อกันแบบวงจรปิด (closed-loop interconnected continuous-flow systems) อย่างจริงจัง

ความกังวลที่โดดเด่นของวิศวกรรมซอฟต์แวร์ในปัจจุบันคือสิ่งที่ระบุไว้ในบทที่ 1 ทุกประการ:

  • วิธีออกแบบและสร้างชุดของโปรแกรมให้เป็นระบบ
  • วิธีออกแบบและสร้างโปรแกรมหรือระบบให้เป็นผลิตภัณฑ์ที่ทนทาน ผ่านการทดสอบ มีเอกสารประกอบ และมีการสนับสนุน
  • วิธีรักษาการควบคุมทางปัญญาเหนือความซับซ้อนในปริมาณมหาศาล

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

Fifty Years of Wonder, Excitement, and Joy

ผมยังจำความรู้สึกมหัศจรรย์และยินดีได้อย่างแจ่มชัด เมื่อตอนที่ผมอายุ 13 ปี ได้อ่านเรื่องราวเกี่ยวกับพิธีเปิดตัวคอมพิวเตอร์ Harvard Mark I เมื่อวันที่ 7 สิงหาคม 1944 ซึ่งเป็นสิ่งมหัศจรรย์ทางไฟฟ้าเครื่องกลที่ Howard Aiken เป็นสถาปนิก และวิศวกรของ IBM ได้แก่ Clair Lake, Benjamin Durfee และ Francis Hamilton เป็นผู้ออกแบบการนำไปใช้งาน และสิ่งที่กระตุ้นความอยากรู้อยากเห็นไม่แพ้กันคือการได้อ่านบทความ "As We May Think" ของ Vannevar Bush ในนิตยสาร Atlantic Monthly ฉบับเดือนเมษายน 1945 ซึ่งเขาเสนอแนวคิดการจัดระเบียบความรู้ให้เป็นโครงข่ายไฮเปอร์เท็กซ์ขนาดใหญ่ และมอบเครื่องจักรให้ผู้ใช้สำหรับทั้งการเดินตามรอยเดิมและสร้างเส้นทางความเชื่อมโยงใหม่ๆ

ความหลงใหลในคอมพิวเตอร์ของผมได้รับการกระตุ้นอย่างแรงกล้าอีกครั้งในปี 1952 เมื่อการทำงานช่วงปิดเทอมฤดูร้อนที่ IBM ในเมืองเอนดิคอตต์ รัฐนิวยอร์ก ทำให้ผมได้มีประสบการณ์ลงมือเขียนโปรแกรมจริงๆ บนเครื่อง IBM 604 และได้รับการสอนอย่างเป็นทางการในการเขียนโปรแกรมเครื่อง IBM 701 ซึ่งเป็นเครื่องจักรแบบเก็บโปรแกรมได้รุ่นแรกของบริษัท การเรียนต่อในระดับบัณฑิตศึกษาภายใต้ Aiken และ Iverson ที่ Harvard ทำให้ความฝันในอาชีพของผมกลายเป็นความจริง และผมก็หลงรักมันไปตลอดชีวิต

ในบรรดามนุษยชาติ มีเพียงส่วนน้อยเท่านั้นที่พระเจ้าประทานสิทธิพิเศษให้เลี้ยงชีพด้วยสิ่งที่เขาพร้อมจะทำแม้ไม่มีค่าตอบแทน เพราะทำด้วยความหลงใหล ผมรู้สึกขอบคุณอย่างยิ่งครับ มันยากที่จะจินตนาการถึงช่วงเวลาที่น่าตื่นเต้นไปกว่าการได้มีชีวิตอยู่ในฐานะผู้คลั่งไคล้คอมพิวเตอร์ จากกลไกเครื่องกล สู่หลอดสุญญากาศ ทรานซิสเตอร์ จนถึงวงจรรวม เทคโนโลยีได้ระเบิดพลังออกมา คอมพิวเตอร์เครื่องแรกที่ผมได้ทำงานด้วยหลังจากจบจาก Harvard คือซูเปอร์คอมพิวเตอร์ IBM 7030 Stretch ซึ่งครองตำแหน่งคอมพิวเตอร์ที่เร็วที่สุดในโลกระหว่างปี 1961 ถึง 1964 โดยมีการส่งมอบเพียงเก้าเครื่องเท่านั้น ส่วน Macintosh Powerbook ของผมในวันนี้ไม่เพียงแต่จะเร็วกว่า มีหน่วยความจำมากกว่า และดิสก์ใหญ่กว่า แต่มันยังมีราคาถูกกว่าถึงหนึ่งพันเท่า (หากคิดตามค่าเงินคงที่คือถูกกว่าถึงห้าพันเท่า) เราได้เห็นการปฏิวัติคอมพิวเตอร์, การปฏิวัติคอมพิวเตอร์อิเล็กทรอนิกส์, การปฏิวัติมินิคอมพิวเตอร์ และการปฏิวัติไมโครคอมพิวเตอร์ ซึ่งแต่ละครั้งได้นำพาจำนวนคอมพิวเตอร์เพิ่มขึ้นหลายหลัก

สายวิชาการที่เกี่ยวข้องกับคอมพิวเตอร์ก็ได้ระเบิดพลังออกมาเช่นเดียวกับเทคโนโลยี เมื่อผมเป็นนักศึกษาบัณฑิตศึกษาในช่วงกลางทศวรรษ 1950 ผมสามารถอ่าน...

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