ช่วงสองสามวันที่ผ่านมาอ่าน blog ของ Satoru Takabayashi คนที่เขียน Namazu. เหลือบเห็น icon ทางขวามือ Bad Knowhow เลยคลิ้กไปอ่าน. อ่านแล้วทำให้คิด, คิดแล้วก็เห็นว่าดีน่าเอามาเล่าสู่กันฟัง.

นาย Satoru เขียนไว้ว่า พอใช้คอมพิวเตอร์ไปก็ รู้สึกว่าทำไมมันต้องจำโน่นจำนี่เยอะแยะกว่าที่จะใช้ซอฟต์แวร์ให้คล่อง พวก knowhow แบบนี้มันเยอะเหลือเกิน. พวก knowhow พวกนี้ตอนแรกไม่ได้อยากจะรู้เลยและเขาเรียก knowhow พวกนี้ว่า Bad Knowhow. พวก Bad Knowhow เกิดมาจากข้อกำหนด (specification) ของซอฟต์แวร์ที่โยงใยมาจากอดีตจนถึงปัจจุบันแบบว่าแก้ไขลำบาก. ที่เห็นได้ชัดคือซอฟต์แวร์บน UNIX ต่างๆเช่น TeX, emacs, sendmail ฯลฯ. พวกนี้จะเป็นซอฟตแืวร์ที่มีประโยชน์มากแต่ในขณะเดียวกันก็มีความซับซ้อนอยู่ภายใย ใช้ลำบาก. นี่ก็เป็นสาเหตุที่ทำพวก Bad Knowhow ทั้งหลายมีเอกสารเกี่ยวกับการใช้ซอฟต์แวร์เหล่านี้ หรือข้อมูลบนเว็บเยอะ.

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

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

เรื่อง Bad Knowhow นี้เป็นเรื่องที่คุยกันเยอะมากแต่คงเฉพาะในญี่ปุ่นมั้ง ถึงขนาดมีการจัด Bad Knowhow conference ปีที่แล้วประมาณเดือนพฤษภาคม. หัวข้อก็คือทำอย่างไรให้พัฒนาการใช้คอมพิวเตอร์ให้ดีขึ้น. ก็มีนัยๆว่าทำอย่างไรให้ Bad Knowhow มันน้อยลงนี่แหละ.

ในสไลด์ก็มีภาพประกอบที่น่าสนใจอันหนึ่งคืออันนี้

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

• Universal knowhow เป็นพวกอัลกอริทึ่ม, data structure, object oriented ฯลฯ
• System knowhow เป็นพวก knowhow ที่เกี่ยวกับตัวระบบเช่น OS, compiler, specification ของภาษาคอมพิวเตอร์, network, computer architecture ฯลฯ
• Bad knowhow พวกที่อยู่ล่างสุดและมีเยอะ พวก API, เครื่องมือต่างๆ, การ configuration, ตัวเลือกบรรทัดคำสั่ง ฯลฯ

พูดง่ายๆคือพวกที่ 1 กับ 2 นี่ส่วนใหญ่จะเรียนกันในมหาวิทยาลัย. ส่วนที่ 3 คือ Bad Knowhow ไม่มีใครสอนต้องหาความรู้ใส่ตัวเอง เรียนรู้ได้จากการท่องเว็บไปวันๆ, ถามน้องเกิ้ลบ้าง. แล้วส่วนใหญ่ก็จะตายตรงช่วงที่ 3. ลองนึกดูว่ากกว่าจะพัฒนาโปรแกรมเองอะไรสักตัวต้องเรียนรู้อะไรไปบ้างเช่น editor ใช้ยังไง, เชลล์ใช้ยังไง, คอมไพล์อะไรทีมีตัวเลือกอะไรบ้าง สารพัด.

ก็มีอีกคนหนึ่งคือ Hiroshi Yuki ก็ให้ความเห็นโดยเขียนในเว็บไซด์ของเขาในหัวข้อ From Bad Knowhow to Good wrapper ไว้ว่า เวลาเจอโปรแกรมที่ใช้ยากๆดูเหมือนจะเป็น Bad Knowhow ก็อย่าไปว่ามันเลย มาสร้าง Good wrapper ดีกว่า. คือเขาก็บอก Bad Knowhow ก็จริงแต่ทำไมมีคนใช้? เช่น Emacs จำ key binding ไปได้ยังไงตั้งเยอะแยะ, ไฟล์ configuration ของ sendmail อ่านไม่รู้เรื่องแต่ก็มีคนใช้ค่อนโลก, TeX/LaTeX เขียนยากจะตายแต่ก็ไม่ตาย เป็นต้น. แสดงว่าพวกซอฟต์แวร์ที่เป็น Bad Knowhow เหล่านั้นมันให้ "ผลลัพธ์ที่ดี" เลยมีคนใช้. โปรแกรมพวกนี้อาจจะจัดเป็น Bad Knowhow ที่ดี. ส่วน Bad Knowhow ที่ไม่ดีคือพวกที่เรียนรู้แล้วไม่ได้ประโยชน์ ต่อยอดอะไรไม่ได้ เ่ช่น ระบบที่มีแต่ GUI อย่างเดียวคือ knowhow แบบกดปุ่มอย่างเดียว, "คน" ต้องมานั่งกดตามขั้นตอนจะให้ "เครื่องคอมฯ" ทำแทนไม่ได้.

ก็ได้ความคิดที่ว่าไม่ต้องกลัว Bad Knowhow ของพวกระบบที่ซับซ้อน. ถ้ามันเป็น Bad Knowhow ก็สร้าง Good Wrapper ทับมันซะ. ตัวอย่างเช่น nmap คำสั่งสแกน IP มีตัวเลือกเยอะแยะเลือกไม่ถูก, ก็ใช้ nampfe เป็น GUI ช่วยทำให้ใช้ง่ายขึ้น. ทำให้ใช้ได้ทั้งแบบบรรทัดคำสั่งกับ GUI. apt-get เป็นบรรทัดคำสั่ง, ไม่อยากใช้หรือใช้ไม่คล่องก็ไปใช้ synaptic แทน.

หมายเหตุ: Picture from http://www.hyuki.com/techinfo/knowhow2.gif

ใน conference ก็มีการบรรยายของ Tatsuhiko Miyakawa ให้ข้อคิดไว้ดีทีเดียว ว่า Bad Knowhow เป็น "สิ่งที่ไม่ดีแต่จำเป็น" (ภาษาญี่ปุ่นใช้คำว่า 必要悪). แถมยังบอกว่า "ค่าของ engineer อยู่ที่จำนวนของ BK (Bad Knowhow) ที่เรียนรู้ไป" ! เขายังอธิบายต่อไปว่า BK หนึ่งๆ ที่ต้องเรียนรู้นั้น ใจความสำคัญไม่ได้อยู่ที่ Knowhow แต่อยู่ที่ "ขั้นตอนที่หา knowhow" ต่างหาก. ตัว BK จริงๆแล้วอาจจะไม่มีประโยชน์อะไรเลย. API, configuration file ที่เรียนไปวันนี้พรุ่งนี้อาจจะใช้ไม่ได้แล้ว (ตรงเผงเลย). แต่สิ่งที่สำคัญของคนที่สู้กับ BK แต่ละอันๆ คือมีประสบการณ์, จะมีสัญชาตญาณว่าควรจะปรับตัวอย่างไร ควรจะทำอย่างไรให้แก้ปัญหาให้ได้. นี่เองที่เขาบอกไว้ว่า "ค่าของ engineer อยู่ที่จำนวนของ BK (Bad Knowhow) ที่เรียนรู้ไป". ในสไลด์ของเขาน่าสนใจมาก แยกประเภทต่างๆของ Bad Knowhow และวิธีแก้ไขให้ด้วยว่าทำอย่างไร. สิ่งที่ช่วยแก้ Bad Knowhow คือเอกสารต่างๆ ไม่ว่าจะเป็น manual, mailing list, web site หรือ blog ที่เขียนๆกัน. คือทางที่ดีรู้คนเดียวไม่พอควรจะเขียนเป็นนิสัย (คนญี่ปุ่นมีแบบนี้เยอะ) ช่วยแก้ Bad Knowhow ได้แบบหนึ่ง (ทางแก้จริงๆอาจจะต้องไปแก้ที่สาเหตุตั้งแต่การออกแบบโปรแกรมดีๆตั้งแต่แรก). และมีทัศนะคติใหม่ต่อ Bad Knowhow ว่า "Let's face it, Bad Knowhow is fun!". คือคุณ Miyakawa เขาคิดแบบคนเป็นวิศวกร.

กลับมาคิดอีกที คนที่ "ชอบ" ใช้ลินุกซ์นี่เป็นพวกชอบ Bad Knowhow ? ผมว่าส่วนหนึ่งคงใช่ ดูแต่ละคนที่อยู่ใน LTN สิ. ชอบอ่าน ชอบค้นคว้าเอง. คีย์เวิร์ด (หรือ key phrase) มันก็มีอยู่บ้างเช่น "ทำอะไรด้วยตัวเอง", "ไม่ยอมแพ้ง่ายๆ", "ถ้าคนอื่นทำได้, ฉันก็ต้องทำได้", "ปัญหาที่เจอ คงมีคนเจอแล้วและอยู่ใน google" ฯลฯ

Bad Knowhow นี่แหละที่ผมว่าเป็นอุปสรรคสำหรับคนใช้ลินุกซ์หน้าใหม่ หรือที่เรียกว่า newbie. เมื่อวานไปอ่านเว็บ I am a newbie, I have a problem, so you must help me! ชี้ให้เห็นเหมือนกันว่า newbie แตกต่างกับพวกไม่ newbie อย่างไร และคนที่ไม่ใช่ newbie มัน (แน่นอนว่าต้องเคยเป็น newbie มาก่อน) มีคุณลักษณะอย่างไร. ลองอ่านดูครับ.

เนื้อหาที่เกี่ยข้อง:

• Knowhow ของ command line กับ GUI

Comments: blogger