ปี 1968 นกได้โปรเจกต์ใหญ่#

นกเป็นหัวหน้าโปรเจกต์ งานคือทำระบบจ่ายเงินเดือนให้โรงงานทอผ้าที่มีพนักงาน 2,000 คน

ทีมมี 10 คน แบ่งเป็นแผนก

ส่วนคนเจาะบัตร อยู่อีกห้องหนึ่ง เป็นอีกแผนก

บนผนังห้องทีมแปะแผนงาน 18 เดือน เป็นแถบงานไล่ลงเป็นขั้นบันได

แผนงานแบบนี้เรียกว่า Gantt chart (ตารางแท่งบอกว่างานไหนทำช่วงไหน)

ขั้นที่ 1 เซ็นปิดแฟ้มสเปก#

นักวิเคราะห์ไปประชุมกับฝ่ายบุคคลของโรงงานหลายรอบ

จดทุกอย่างลงแฟ้ม เรียกว่า spec (เอกสารบอกว่าระบบต้องทำอะไร)

ในบันทึกประชุมมีประโยคหนึ่งว่า “จ่ายเงินทุกงวด”

ไม่มีใครถามต่อว่า งวดคือทุกสัปดาห์หรือทุกเดือน

จำประโยคนี้ไว้นะครับ เดี๋ยวมันกลับมา

พอแฟ้มเสร็จ ลูกค้าเซ็นอนุมัติ ปิดแฟ้ม

ในวิธีนี้ แฟ้มที่เซ็นแล้วเหมือนสัญญา ขั้นต่อไปทุกขั้นสร้างต่อจากมัน

ขั้นที่ 2 ออกแบบด้วยกล่องกับลูกศร#

นักออกแบบวาด flowchart (ผังงาน กล่องกับลูกศรบอกลำดับการทำงาน)

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

แล้วก็แบ่งกล่องในผังให้โปรแกรมเมอร์แต่ละคนรับไปทำ

ข้อมูลที่ต้องส่งต่อกันระหว่างคน เขียนไว้ในเอกสารแผ่นเดียว

ในแผ่นนั้นมีช่อง “วันที่”

แต่ไม่ได้บอกว่าเรียงแบบวัน/เดือน/ปี หรือเดือน/วัน/ปี

จำอันนี้ไว้ด้วยครับ 555+

ทำไมยุคนี้เขียนโค้ดง่ายขึ้นแล้ว แต่ยังช้าอยู่?#

เพราะภาษาอ่านง่ายขึ้นก็จริง แต่ระหว่างทางจากหัวคนเขียนไปถึงเครื่อง มีหลายมือ และต้องรอคิวรันเครื่องเหมือนเดิม

โปรแกรมเมอร์ในทีมนกใช้ภาษา COBOL ภาษาสำหรับงานธุรกิจ ที่คณะทำงานชื่อ CODASYL เริ่มออกแบบในปี 1959

จุดเด่นคือใช้คำภาษาอังกฤษเป็นคำสั่ง อ่านแล้วพอเดาได้ เช่น

MULTIPLY HOURS BY RATE GIVING PAY.

แปลตรงๆ คือ เอาชั่วโมงคูณค่าแรง ได้เป็นเงินเดือน

เทียบกับเลข 0 กับ 1 ในตอนที่ 2 นี่สบายขึ้นเยอะ

แต่ขั้นตอนยังยาวอยู่

1. โปรแกรมเมอร์เขียนโค้ดด้วยดินสอลงกระดาษฟอร์มเป็นตาราง ช่องละตัวอักษร
2. ส่งฟอร์มไปห้องเจาะบัตร คนเจาะบัตรพิมพ์ลงเครื่องเจาะบัตร IBM 029 ที่ออกมาปี 1964 ทีละบรรทัด
3. เอาปึกบัตรไปส่งห้องเครื่อง รอผล

ลายมือก็เป็นปัญหาได้

เลข 0 กับตัว O เขียนคล้ายกันมาก คนเจาะบัตรอ่านผิดได้ง่าย

เดือนที่ 10 เอางานทุกคนมาต่อกัน#

แต่ละคนเขียนส่วนของตัวเองเสร็จแล้ว

ถึงเวลาเอามาต่อกัน แล้วทดสอบ

เปิดมาก็เจอเรื่องแรก

ถาดบัตร “คำนวณเงินเดือน” มีสองถาด

เพราะโปรแกรมเมอร์สองคนแก้งานชุดเดียวกัน คนละสำเนา

ยุคนั้นยังไม่มีเครื่องมือเก็บประวัติการแก้โค้ดแบบที่เราใช้กันทุกวันนี้

ต้องไล่ถามกัน ว่าถาดไหนคือตัวล่าสุด

เรื่องที่สองหนักกว่า

พอรันจริง โปรแกรมพัง

เครื่องพิมพ์ทุกอย่างที่อยู่ในหน่วยความจำออกมาเป็นตัวเลขยาวเหยียดหลายหน้า เรียกว่า core dump (พิมพ์หน่วยความจำทั้งก้อนออกมาให้คนไล่หาเอง)

ไล่กันอยู่นาน ถึงเจอว่า

คนหนึ่งเก็บวันที่แบบวัน/เดือน อีกคนเก็บแบบเดือน/วัน

ช่อง “วันที่” ที่ไม่มีใครระบุตั้งแต่ขั้นออกแบบ มาระเบิดเอาตอนนี้

แก้เอกสาร แก้โค้ดสองคน เจาะบัตรใหม่ ส่งรันใหม่

Gantt chart บนผนังเลื่อนไปอีกหลายสัปดาห์

เดือนที่ 14 ลูกค้าเพิ่งได้เห็นของจริง#

ในที่สุดระบบก็รันผ่าน

ฝ่ายบุคคลมาดูสลิปเงินเดือนที่พิมพ์ออกมา

แล้วพูดประโยคที่ทำให้ทั้งห้องเงียบ

“โรงงานเราจ่ายเงินทุกสัปดาห์นะ”

คำว่า “ทุกงวด” ในแฟ้มสเปกตั้งแต่เดือนแรก ไหลลงมาทุกขั้น จนมาโผล่ตอนท้าย

ทีนี้ต้องย้อนกลับไปแก้

เปิดแฟ้มที่เซ็นไปแล้ว วาดผังใหม่ เขียนโค้ดใหม่ เจาะบัตรใหม่

ยิ่งความผิดเกิดตั้งแต่ขั้นแรก ยิ่งต้องย้อนไกล ยิ่งแพง

เรื่องจริงของยุคนี้#

เรื่องของนกเป็นเรื่องสมมติ

แต่ปัญหาแบบนี้เกิดจริงทั่ววงการ และกับโปรเจกต์ที่ใหญ่กว่ามาก

IBM System/360 กับ OS/360

เดือนเมษายนปี 1964 IBM ประกาศเปิดตัว System/360 คอมพิวเตอร์ทั้งตระกูลที่ใช้ software ร่วมกันได้ เครื่องเล็กเครื่องใหญ่รันโปรแกรมเดียวกันได้

ฝั่ง hardware ไปได้ดี

แต่ฝั่ง software คือ OS/360 (ระบบปฏิบัติการของเครื่องตระกูลนี้) ล่าช้าหนัก

คนที่เข้าไปคุม OS/360 ในปี 1964 คือ Fred Brooks

ทีมยิ่งช้า ก็ยิ่งเพิ่มคน แต่ยิ่งเพิ่มคน กลับยิ่งช้า

ปี 1975 Brooks เขียนหนังสือ The Mythical Man-Month สรุปบทเรียนจากงานนี้ ประโยคดังที่สุดในเล่ม คนเรียกกันว่า Brooks’s law

“Adding manpower to a late software project makes it later.”

แปลว่า เพิ่มคนเข้าไปในโปรเจกต์ software ที่ล่าช้าอยู่แล้ว จะทำให้มันช้าลงอีก

เพราะคนใหม่ต้องมีคนสอน และยิ่งคนเยอะ ยิ่งต้องคุยกันเยอะ

ในหนังสือ เขายกตัวอย่างไว้ว่า การตั้งครรภ์ใช้เก้าเดือน ไม่ว่าจะให้ผู้หญิงกี่คนมาช่วยก็ตาม 555+

การประชุม NATO ปี 1968

เดือนตุลาคมปี 1968 NATO จัดประชุมที่เมือง Garmisch ประเทศเยอรมนี มีผู้เชี่ยวชาญราว 50 คน ทั้งจากบริษัทผลิตคอมพิวเตอร์ มหาวิทยาลัย และบริษัท software

หัวข้อการประชุมคือ software engineering (วิศวกรรมซอฟต์แวร์)

คนจัดเลือกคำนี้แบบตั้งใจให้คนสะดุด เพราะอยากบอกว่าการสร้าง software ควรมีหลักการแน่นหนาแบบงานวิศวกรรมสาขาอื่น ซึ่งตอนนั้นยังไม่มี

ในที่ประชุม คนพูดถึง software crisis (วิกฤต software) กันอย่างเปิดเผย คือระบบใหญ่ๆ ส่งช้า งบบาน และดูแลยาก

ที่น่าสนใจคือ รายงานการประชุมเองก็บอกว่า งานอย่างระบบเงินเดือนไม่ได้วิกฤต ที่วิกฤตคือระบบใหญ่ๆ

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

Waterfall มาจากไหน และ Royce พูดอะไรจริงๆ?#

คำตอบสั้นๆ คือ ภาพขั้นบันไดมาจากบทความของ Winston Royce ปี 1970 แต่ Royce ไม่ได้ใช้คำว่า Waterfall และเขาเตือนด้วยว่าการทำทีละขั้นตรงๆ แบบนั้นเสี่ยง

บทความชื่อ “Managing the Development of Large Software Systems”

ในนั้นมีภาพขั้นงานไล่ลงเป็นขั้นบันได คล้ายกับที่ผมเล่าไว้ในตอนที่ 1

คนรุ่นหลังเห็นภาพนี้ แล้วเรียกมันว่า Waterfall

แต่ประโยคถัดจากภาพนั้น Royce เขียนว่า

“I believe in this concept, but the implementation described above is risky and invites failure.”

แปลว่า เขาเชื่อในแนวคิดนี้ แต่ถ้าทำตามแบบที่เพิ่งวาดไว้ จะเสี่ยงและพังได้ง่าย

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

ส่วนที่เหลือของบทความ Royce เสนอสิ่งที่ต้องเพิ่มเข้าไปเพื่อลดความเสี่ยง หนึ่งในนั้นคือให้ลูกค้าเข้ามามีส่วนร่วมตลอดทาง

ก็คือเรื่องเดียวกับที่ทีมนกเจอเป๊ะ ลูกค้าเพิ่งได้เห็นของจริงตอนเดือนที่ 14

ผมว่าตลกร้ายดีครับ บทความที่เตือนว่าอย่าทำแบบนี้ กลับกลายเป็นต้นแบบของวิธีที่คนทำกันมาหลายสิบปี

สิ่งที่ผมได้จากยุคนี้#

ลองทำเอง

ตามนกมาทั้งเรื่อง ผมเห็นว่าปัญหาไม่ได้อยู่ที่คนไม่เก่ง

ทุกคนทำส่วนของตัวเองถูกหมด

แต่พังตรงรอยต่อ ระหว่างลูกค้ากับนักวิเคราะห์ ระหว่างโปรแกรมเมอร์สองคน ระหว่างคนเขียนกับคนเจาะบัตร

เก็บศัพท์

จดบันทึก

ตอนที่ 2 สอนว่า ยิ่งรู้ว่าผิดช้า ยิ่งเจ็บ

ตอนนี้สอนต่อว่า ยิ่งคนเยอะ รอยต่อยิ่งเยอะ และความผิดที่ซ่อนอยู่ตรงรอยต่อ จะไปโผล่เอาตอนท้ายสุด

คำถามที่พบบ่อย#

Waterfall คืออะไร?

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

ใครตั้งชื่อ Waterfall?

ไม่ใช่ Winston Royce ครับ บทความของเขาปี 1970 ไม่มีคำว่า Waterfall เลย คนรุ่นหลังเป็นคนเรียกภาพในบทความนั้นว่า Waterfall

คำว่า software engineering มาจากไหน?

ถูกใช้เป็นชื่อการประชุมที่ NATO จัดที่ Garmisch ประเทศเยอรมนี เมื่อเดือนตุลาคมปี 1968 คนจัดตั้งใจเลือกคำนี้ให้คนสะดุดคิด

Brooks’s law คืออะไร?

หลักที่ Fred Brooks เขียนไว้ในหนังสือ The Mythical Man-Month ปี 1975 ว่าเพิ่มคนเข้าไปในโปรเจกต์ software ที่ล่าช้า จะทำให้ช้าลงอีก

Next → ตอนที่ 4: ยุค Iterative ทำทีละรอบ ตอนหน้าเป็นยุค Iterative ราวปี 1980 ถ้าไม่รอให้ลูกค้าเห็นของจริงตอนเดือนที่ 14 แต่ให้ดูทีละส่วนตั้งแต่รอบแรกล่ะ จะเกิดอะไรขึ้น ผมจะลองดูครับ