ท้องฟ้าไม่มีความหมาย ถ้าไม่มีใครแหงนมองฟ้าของคนอื่น

เพิ่งอ่านอีกส่วนหนึ่งของหนังสือของ Alistair Cockburn เขาพยายามแยกแยะว่าคำว่า "วิศวกรรม" เวลาที่เรากล่าวว่าทำซอฟต์แวร์โดยใช้กระบวนการทางวิศวกรรม หมายถึงอะไร

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

Cockburn กล่าวว่านั่นเป็นความสับสนระหว่าง "ผล" (outcome) ของงานวิศวกรรมกับ "การกระทำ" (act) งานวิศวกรรม

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

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

กิจกรรมทางวิศวกรรมดังกล่าวนั้น Cockburn เปรียบเปรยว่าเป็น cooperative game นั่นคือเกมที่ผู้เล่นช่วยกันเล่นเพื่อนำไปสู่เป้าหมายบางอย่างร่วมกัน

เขากล่าวว่าเราน่าจะกลับมามองว่าคำว่า "วิศวกรรม" ควรหมายถึงการคิดวิเคราะห์และการหาจุดแบ่ง (trade-off) มากกว่า และสรุปว่าถ้ามองเช่นนั้นคำว่าวิศวกรรมก็ไม่ได้บอกว่าจะจัดการกับโครงงานอย่างไร

หมายเหตุ:
1. Alistair Cockburn เป็นหนึ่งในกลุ่มผู้ลงชื่อและเขียน Agile Manifesto
2. เวลาผมอ่านต้องพยายามทำใจกับการที่ Cockburn นำศัพท์แสงทางทฤษฎีเกมมาใช้อธิบาย (เช่น บอกว่าเกมมีหลายแบบ เช่นแบบ finite, infinite) เหมือนกับว่ากำลังพิจารณาสิ่งต่าง ๆ ภายใต้ทฤษฎีเกมจริง ๆ โดยไม่ได้แยกให้ชัดเจนว่าคำว่า "เกม" ที่เขาใช้หมายถึงเกมที่เป็นกิจกรรม ไม่ใช่เกมที่วิเคราะห์ได้ชัดเจนเหมือนในทฤษฎีเกม

ขยายเพิ่มเติม (1 สค 22:00)  [เพื่อตอบ comment ของ คุณ Tux-Linux และคุณ Joe]  เอาตามที่ผมเข้าใจนะครับ อย่างแรกก็คือการบอกว่าศัพท์ที่เราใช้เรียกเนี่ยะมันมีปัญหานิดหน่อย เขาพยายามเปรียบเทียบให้เห็นว่าเวลาเรากล่าวว่าใช้หลักการวิศวกรรมในการ พัฒนาซอฟต์แวร์ เราไม่น่าจะหมายถึงส่วนที่เป็นสิ่งที่คุณ Joe เรียกว่างานบริหาร  การวัดและควบคุมกระบวนการนั้น Cockburn ไม่นับว่าเป็นกิจกรรมที่เป็นงานวิศวกรรม แต่เป็นผลของงานวิศวกรรมมากกว่า อย่างที่สองที่ผมเข้าใจเอาเอง ก็คือเขาพยายามจะบอกว่าส่วนที่ควรจะเป็นกิจกรรมทางวิศวกรรมน่าจะเป็นในส่วน ของการออกแบบแล้วก็จัดการทางเลือกต่าง ๆ มากกว่า ทีนี้ในส่วนนั้นเนี่ยะ ถ้าเราพิจารณาว่า "หลักทางวิศวกรรม" คือการคิดวิเคราะห์และหา trade-off การบอกว่าให้พัฒนาซอฟต์แวร์โดยใช้กระบวนการทางวิศวกรรมก็ไม่ได้บอกอะไรมากไป กว่าการบอกว่าให้พัฒนาซอฟต์แวร์โดยการคิดวิเคราะห์และหา trade-off นั่นเอง  ซึ่งการระบุแค่นี้ไม่ได้ช่วยอะไรเราเลย

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

ผมก็อ่านเอาตีความเอาตามเรื่องครับ ไม่รู้ว่าผิดถูกมากน้อยครับ ขอบคุณสำหรับความเห็นนะครับ