by

Premature Optimization

เวลาเราทำ software เพื่อทำอะไรบางอย่าง บางทีเราเสียเวลาไปกับการ research หาเครื่องมือที่ดีที่สุด, หา tools ที่ใช้งานง่ายที่สุด, พยายาม optimize code ให้ทำงานได้เร็วที่สุด หรืออะไรทำก็ตามที่ทำแล้วคิดว่ามันเจ๋งจนลืมคิดไปว่าที่ใช้เวลาทำสิ่งพวกนั้นมันไม่ได้สร้างความเปลี่ยนอะไรให้ product เลย บางครั้งมันทำให้ product เสร็จช้าลง, deliver product ออกไปถึงมือผู้ใช้ช้าลงด้วยซ้ำ

เวลาเราทำ feature ออกมาชิ้นหนึ่ง เราไม่รู้หรอกว่า feature นี้มันเป็นสิ่งที่ผู้ใช้ต้องการจริงๆ หรือไม่ จะดีกว่ามั๊ยถ้าเรารีบๆ ทำ แล้วรีบๆ ปล่อยออกไปให้ผู้ใช้ได้ลอง แล้วเราก็เรียนรู้จาก feedback ของผู้ใช้ให้เร็วที่สุด ถ้ามันเจ๋ง เราค่อยมา optimize, ถ้ามันเจ๊ง เราก็แค่เอามันออกไป loop จบสั้นๆ ไวๆ

ลองคิดเป็น animation นะ สมมติบริษัท A กับบริษัท B เป็นคู่แข่งกันทั้งคู่บังเอิญคิด feature เด็ดออกมาได้ เป็น feature ที่ให้ผู้ใช้ follow กันได้ ทั้งสองบริษัทเชื่อมั่นว่า feature นี้เป็นทีเด็ดของ product เลย

บริษัท A เริ่มต้นโดยการแบ่งคนออกไป research หาว่าถ้าจะทำ feature นี้ต้องใช้ database ตัวไหน ก็จัดการให้ developer 3 คนไปทำ benchmark database เทียบกัน 3 ตัวกินเวลา 1 สัปดาห์แล้วตัดสินใจว่า เอาล่ะเราจะใช้ Neo4j กัน ถึงแม้จะไม่เคยมีใครใช้ตัวนี้มาก่อนเราก็เลือกตัวนี้เพราะมี performance ดีที่สุด ในอนาคตเราสามารถต่อยอดไปทำอะไรแปลกๆ จาก graph ของการ follow กันของผู้ใช้ได้ แล้วก็ใช้เวลาศึกษาและพัฒนา feature นี้ไปอีก 2 สัปดาห์ เจอปัญหาก็แก้ไปตามทางเพราะบริษัท A ไม่มีผู้เชี่ยวชาญ Neo4j เลย

บริษัท B สนใจแค่ว่า เราจะทำยังไงให้เรา ship feature นี้ได้เร็วที่สุด จึงตัดสินใจเลือก MySQL เพราะ developer ของบริษัทถนัดตัวนี้มากที่สุด ใช้เวลา 1 สัปดาห์ก็พัฒนาเสร็จพร้อม deliver ให้ผู้ใช้ได้ใช้

เมื่อบริษัท B release ก่อน ก็ได้เรียนรู้จากผู้ใช้ก่อน พยายามปรับปรุง feature ในอีก 1 สัปดาห์ถัดมาก็ release รุ่นแก้ไขไป

เวลาผ่านไปบริษัท B พบว่าผู้ใช้ไม่ได้ต้องการที่จะ follow กันเลย จึงตัดสินใจเปลี่ยนไปทำ feature อื่นแทน ในขณะที่บริษัท A ยังทำ feature follow ไม่เสร็จเลย

ในเคสที่ feature ที่เลือกมาทำนั้นมันไม่ work ระหว่างเส้นทางนี้บริษัท A ใช้ dev 3 คนในการ research, อาจจะใช้ dev 2 คนช่วยกันทำเพราะเป็นของใหม่เลยคิดว่าสองหัวน่าจะดีกว่าหัวเดียว ในขณะที่บริษัท B ใช้ dev คนเดียวก็ทำเสร็จเพราะเชี่ยวชาญอยู่แล้ว

บริษัท B release ก่อนบริษัท A, บริษัท B เรียนรู้ว่า fail ไปแล้ว, เปลี่ยนไปทำ feature อื่นแล้วในขณะที่ทีม operation ของบริษัท A อาจจะกำลังติดปัญหาเกี่ยวกับการ deploy Neo4j ใน production environment อยู่ก็เป็นได้

ถ้าหากว่า feature นี้มันเป็น feature เด็ดจริงๆ ล่ะ ? เกิดผู้ใช้แห่กัน follow จน MySQL ของบริษัท B รองรับไม่ไหวล่ะ ? อันนี้ก็เป็นไปได้นะ แต่อยากให้ลองคิดดูว่าเวลาเราทำ product เนี่ย ท่ามกลาง feature มากมาย มันมีจำนวน feature ที่เจ๊งมากกว่า feature ที่เจ๋ง ใช่มั๊ย ? เราควรจะ bet โดยการทุ่มกำลังคนและเวลาไปทำทุกสิ่งทุกอย่างให้ perfect ตั้งแต่แรกเลยหรือไม่ ?

ส่วนตัวผมมองว่าการทำ software มันไม่เหมือนกับการทำหนัง ถ้าเราเป็นผู้กำกับหนังมันต้องจัดเต็ม เพราะหนังฉายรอบเดียว มันไม่มีหนังเรื่องไหนจะมาฉายภาค alpha, beta, release candidate นะ software มันทำได้ไง เราพัฒนาไปเรื่อยๆ ช่วงแรกมันจะยังไม่ perfect ก็เรื่องปกติ แต่ต่อไปเมื่อได้เรียนรู้ เราก็จะพัฒนามันให้ดีขึ้นไปเรื่อยๆ เราผ่านยุคทำ software pack กล่องขายแล้วนะ

Twitter ไม่ได้เริ่มต้นด้วย Java กับ Cassandra นะ เค้าเริ่มด้วย Ruby กับ MySQL, Facebook ก็ไม่ได้เริ่มต้นด้วย HBase นะ เค้าเริ่มด้วย PHP กับ MySQL

ปัญหาไม่ได้อยู่ที่การทำให้ perfect นะ ปัญหาอยู่ที่ถ้าหากว่าเรามี resource จำกัดมากๆ เราควรใช้ resource ไปกับการสิ่งที่ยังไม่จำเป็นมากแค่ไหน

Comments

comments

Page 1 of 11