Frozen Caveman Antipattern

Antipattern คือสิ่งที่โปรแกรมเมอร์ Andrew Koenig นิยามว่าเป็นสิ่งที่ดูเหมือนเป็นไอเดียที่ดีตอนที่คุณเริ่มต้น แต่นำคุณไปสู่ปัญหา Frozen Caveman antipattern เป็น behavioral antipattern ที่พบเห็นได้บ่อยในโลกจริง มันอธิบายถึงสถาปนิกที่ย้อนกลับไปสู่ข้อกังวลไร้เหตุผลส่วนตัว ของตนในทุกๆ architecture ตัวอย่างเช่น เพื่อนร่วมงานคนหนึ่งของ Neal เคยทำงานในระบบที่มี centralized architecture ทุกครั้งที่พวกเขาส่งมอบ design ให้กับสถาปนิกฝ่ายลูกค้า คำถามที่ถามซ้ำๆ อยู่เสมอคือ “แต่ถ้าเราสูญเสียอิตาลีล่ะ” หลายปีก่อนหน้านั้น ปัญหาการสื่อสารประหลาดปัญหาหนึ่งเคยทำให้สำนักงานใหญ่ของลูกค้า สื่อสารกับสาขาในอิตาลีไม่ได้ ก่อให้เกิดความไม่สะดวกอย่างมาก แม้ว่าโอกาสที่เรื่องนี้จะเกิดซ้ำจะน้อยมาก แต่สถาปนิกกลุ่มนั้นกลับหมกมุ่นอยู่กับ architectural characteristic เฉพาะจุดนี้

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

สถาปนิกควรมุ่งเน้นไปที่ technical breadth เพื่อให้มีคลังธนูที่ใหญ่ขึ้นให้หยิบใช้ นักพัฒนาที่เปลี่ยนผ่าน สู่บทบาทสถาปนิกอาจต้องเปลี่ยนวิธีมองการสั่งสมความรู้ การสร้างสมดุลระหว่างความลึกและความกว้างของ portfolio ความรู้เป็นสิ่งที่นักพัฒนาทุกคนควรพิจารณาตลอดสายอาชีพของตน แต่สถาปนิกจะได้ technical breadth มาได้อย่างไร หัวข้อถัดไปให้เทคนิคบางอย่างที่จะช่วยให้คุณค้นพบ “สิ่งที่คุณไม่รู้ว่าคุณไม่รู้”

The 20-Minute Rule (กฎ 20 นาที)

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

เทคนิคหนึ่งที่เราใช้คือ กฎ 20 นาที ไอเดียคือการทุ่มเวลา อย่างน้อย 20 นาทีต่อวันเพื่อเรียนรู้สิ่งใหม่หรือเจาะลึกหัวข้อที่เจาะจง รูปที่ 2-6 แสดงสถานที่ดีๆ ที่จะใช้ 20 นาทีของคุณ เช่น InfoQ , DZone Refcardz และ Thoughtworks Technology Radar คุณสามารถเรียนรู้เกี่ยวกับคำศัพท์แสลงที่ไม่คุ้นเคยเพิ่มเติมได้ด้วยการค้นหาทางอินเทอร์เน็ต เลื่อนความรู้นั้นจาก “สิ่งที่คุณไม่รู้ว่าคุณไม่รู้” ไปเป็น “สิ่งที่คุณรู้ว่าคุณไม่รู้” คุณอาจใช้เวลานั้น อ่านหนังสือแบบเล่มนี้ก็ได้ ประเด็นคือการแบ่งเวลาบางส่วนออกจากวันที่ยุ่งวุ่นวายของคุณเพื่อมุ่งพัฒนา technical breadth และสายอาชีพของคุณ

Figure 2-6. The 20-minute rule

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

การทำตามกฎ 20 นาทีจะเพิ่ม technical breadth ของคุณ และช่วยให้คุณพัฒนาและรักษาความรู้ที่จะทำให้คุณเป็น software architect ที่มีประสิทธิภาพ

Developing a Personal Radar (การสร้าง Radar ส่วนตัว)

ตลอดช่วงยุค 90 และต้นยุค 2000 ผู้เขียนคนหนึ่งของเราเคยเป็น CTO ของบริษัทฝึกอบรมและที่ปรึกษาขนาดเล็กแห่งหนึ่ง ตอนที่เขาเริ่มทำงานที่นั่น แพลตฟอร์มหลักคือ Clipper ซึ่งเป็นเครื่องมือพัฒนาแอปพลิเคชันแบบรวดเร็วสำหรับสร้าง แอปพลิเคชัน DOS บนไฟล์ dBASE จนกระทั่งวันหนึ่งมันก็หายไป บริษัทเคยสังเกตเห็นการเติบโตของ Windows แต่ตลาดธุรกิจยังคงเป็น DOS อยู่…จนกระทั่งจู่ๆ มันก็ไม่ใช่อีกต่อไป เพื่อนร่วมงานคนหนึ่งบ่นว่าพวกเขาไม่สามารถนำ ความรู้ Clipper อันมหาศาลที่ตอนนี้ไร้ประโยชน์แล้วไปแทนที่ด้วยอะไรอื่นได้ เพื่อนร่วมงานสงสัยว่า มีกลุ่มคนไหนในประวัติศาสตร์บ้างที่เรียนรู้และทิ้งความรู้ที่ละเอียดมากขนาดนี้ไปภายในชั่วชีวิตของตัวเอง เหมือนกับที่นักพัฒนาซอฟต์แวร์ทำ ประสบการณ์นี้ทิ้งความประทับใจที่ยั่งยืนไว้ เพิกเฉยต่อการก้าวเดินของเทคโนโลยีด้วยความเสี่ยงของตัวคุณเอง

มันยังสอนบทเรียนสำคัญเรื่อง technology bubble ให้เราด้วย เมื่อนักพัฒนา สถาปนิก และนักเทคโนโลยีอื่นๆ ทุ่มเทลงทุนอย่างหนักในเทคโนโลยีหนึ่งๆ เทงานและความคิดของเราลงไปในมัน เรามักจะอาศัยอยู่ใน memetic bubble ภายในฟองสบู่ ซึ่งทำหน้าที่เป็น echo chamber ด้วย ทุกคนรู้จักและใส่ใจเทคโนโลยีนั้นเหมือนกับที่เรารู้สึก เราอาจไม่เห็นการประเมินอย่างซื่อตรงจากภายนอกฟองสบู่เลยด้วยซ้ำ โดยเฉพาะถ้าฟองสบู่นั้นถูกสร้างขึ้นโดย vendor เทคโนโลยีตั้งแต่แรก และเมื่อฟองสบู่เริ่มแตก ก็จะไม่มีการเตือนล่วงหน้าจนกว่าจะสายเกินไป

สิ่งที่เราขาดในฟองสบู่ของเราคือ technology radar เอกสารที่มีชีวิตที่ช่วยเราประเมินความเสี่ยงและผลตอบแทนของเทคโนโลยีที่มีอยู่และเทคโนโลยีที่กำลังเกิดใหม่ แนวคิด radar นี้มาจาก Thoughtworks ที่ซึ่ง Neal ทำงานเป็น director และ software architect ในหัวข้อนี้ เราจะอธิบายว่าแนวคิดนี้เกิดขึ้นได้อย่างไร แล้วแสดงวิธีสร้าง radar ส่วนตัวให้คุณ

The Thoughtworks Technology Radar (Technology Radar ของ Thoughtworks)

Technology Advisory Board (TAB) คือกลุ่มผู้นำเทคโนโลยีระดับสูงภายใน Thoughtworks ที่ช่วย CTO ในการตัดสินใจเกี่ยวกับทิศทางและกลยุทธ์ด้านเทคโนโลยีสำหรับบริษัทและลูกค้าของบริษัท เพื่อให้ทันสมัยอยู่เสมอ กลุ่มนี้เริ่มผลิตสิ่งที่ตอนนี้กลายเป็น Technology Radar ที่ออกทุกครึ่งปี

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

Parts (ส่วนประกอบ)

Thoughtworks Radar ประกอบด้วยสี่ quadrant ที่พยายามครอบคลุมภูมิทัศน์ของการพัฒนาซอฟต์แวร์ส่วนใหญ่

Tools (เครื่องมือ)

ทุกอย่างตั้งแต่เครื่องมือพัฒนาอย่าง IDE ไปจนถึงเครื่องมือ integration ระดับ enterprise

Languages and frameworks (ภาษาและ Framework)

ภาษาคอมพิวเตอร์ library และ framework ซึ่งโดยทั่วไปเป็น open source

Techniques (เทคนิค)

practice ใดๆ ที่ช่วยการพัฒนาซอฟต์แวร์โดยรวม รวมถึง process, engineering practice และคำแนะนำ

Platforms (แพลตฟอร์ม)

แพลตฟอร์มเทคโนโลยี รวมถึง database, cloud vendor และระบบปฏิบัติการ ต่างๆ

Rings (วงแหวน)

Radar มีสี่วงแหวน เรียงจากวงนอกสุดไปวงในสุดดังนี้

Hold (ระงับ)

ความหมายเดิมของวงแหวน Hold คือ “ระงับไว้ก่อน” เพื่อแทนเทคโนโลยีที่ใหม่เกินกว่าจะประเมินได้อย่างสมเหตุสมผล ในตอนนั้น เทคโนโลยีที่ได้รับความสนใจอย่างมากแต่ยังพิสูจน์ตัวเองไม่ได้ วงแหวน Hold ได้พัฒนาไป และตอนนี้มีความหมายใกล้เคียงกับ “อย่าเริ่มอะไรใหม่ด้วยเทคโนโลยีนี้” มากกว่า ไม่มีอันตรายอะไรถ้าใช้มัน ในโปรเจกต์ที่มีอยู่แล้ว แต่ควรคิดให้รอบคอบก่อนใช้กับการพัฒนาใหม่

Assess (ประเมิน)

วงแหวน Assess บ่งบอกว่าเทคโนโลยีหนึ่งคุ้มค่าที่จะสำรวจ (เช่นผ่าน development spike, research project หรือ session ในงานประชุม) เพื่อดูว่ามันจะส่งผลต่อองค์กรอย่างไร ตัวอย่างเช่น เมื่อ mobile browser เริ่มโดดเด่นขึ้นมา บริษัทใหญ่หลายแห่งผ่านช่วงนี้อย่างเห็นได้ชัด ตอนกำหนดกลยุทธ์ mobile ของตน

Trial (ทดลอง)

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

Adopt (นำมาใช้)

Thoughtworks เชื่อมั่นอย่างยิ่งว่าอุตสาหกรรมควรนำรายการที่อยู่ในวงแหวน Adopt มาใช้

ในภาพตัวอย่างของ Radar ใน รูปที่ 2-7 แต่ละ “blip” แทนเทคโนโลยีหรือเทคนิคที่ต่างกัน แม้ Thoughtworks จะใช้ radar เพื่อกระจายความคิดเห็น โดยรวมของตนเกี่ยวกับโลกซอฟต์แวร์ แต่นักพัฒนาและสถาปนิกหลายคนก็ใช้มันเป็นวิธีจัดโครงสร้างกระบวนการ ประเมินเทคโนโลยีของตัวเองและจัดระเบียบความคิดว่าจะลงทุนเวลาในอะไร สำหรับการใช้งานส่วนตัว เราแนะนำให้เปลี่ยนความหมายของ quadrant เป็นดังนี้

Hold (ระงับ)

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

Assess (ประเมิน)

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

Trial (ทดลอง)

วงแหวน Trial บ่งบอกถึงการวิจัยและพัฒนาอย่างจริงจัง เช่นการทำ spike experiment ภายใน code base ขนาดใหญ่ นี่คือเทคโนโลยีที่คุ้มค่าที่จะใช้เวลาเข้าใจให้ลึกซึ้งยิ่งขึ้น เพื่อให้คุณสามารถนำมันมารวมไว้ใน trade-off analysis ได้อย่างมีประสิทธิภาพ

Adopt (นำมาใช้)

วงแหวน Adopt ส่วนตัวของคุณแทนสิ่งใหม่ๆ ที่คุณตื่นเต้นที่สุด และ best practice สำหรับการแก้ปัญหาเฉพาะเจาะจง

Figure 2-7. A sample Thoughtworks Technology Radar

นักเทคโนโลยีส่วนใหญ่เลือกเทคโนโลยีแบบ ad hoc มากกว่าน้อยกว่า โดยอิงจากสิ่งที่ดูเจ๋งหรือสิ่งที่ นายจ้างของตนใช้อยู่ แต่มันเป็นอันตรายต่อสายอาชีพของคุณที่จะมีทัศนคติแบบปล่อยตามยถากรรมต่อ technology portfolio ของตัวเอง การสร้าง technology radar ช่วยให้คุณจัดระเบียบความคิดเกี่ยวกับ เทคโนโลยีอย่างเป็นทางการและสร้างสมดุลระหว่างเกณฑ์การตัดสินใจที่ขัดแย้งกัน (ตัวอย่างเช่น มันอาจยากกว่า ที่จะได้งานใหม่ที่เน้นเทคโนโลยีที่ “เจ๋งกว่า” ในขณะที่เทคโนโลยีที่จัดตั้งมานานอาจมีตลาดงานใหญ่มาก แต่งานอาจน่าสนใจน้อยกว่า)

ปฏิบัติต่อ technology portfolio ของคุณเหมือนกับ financial portfolio นั่นคือกระจายความเสี่ยง! เลือกเทคโนโลยีและ/หรือทักษะบางอย่างที่เป็นที่ต้องการอย่างกว้างขวาง แล้วติดตามความต้องการนั้น แต่คุณอาจต้องการลองเสี่ยงกับเทคโนโลยีบางอย่างด้วย เช่น generative AI หรืออุปกรณ์ embedded IOT มีเรื่องเล่ามากมายเกี่ยวกับนักพัฒนาที่ปลดปล่อยตัวเองจากการเป็นทาสในห้องทำงานแคบๆ ด้วยการทำงาน ดึกๆ ในโปรเจกต์ open source ที่ในที่สุดก็ได้รับความนิยมและถูกซื้อไปในที่สุด นี่เป็นอีกเหตุผลหนึ่ง ที่ควรมุ่งเน้นความกว้างมากกว่าความลึก

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

แม้ส่วนสำคัญที่สุดของการสร้าง radar ส่วนตัวของคุณคือบทสนทนาที่มันก่อให้เกิดขึ้น มันยังให้ visualization ที่มีประโยชน์มากด้วย หลังจากมีความต้องการอย่างมากจากนักเทคโนโลยีที่สร้าง radar visualization ของตัวเอง Thoughtworks ได้ปล่อยเครื่องมือชื่อ Build Your Own Radar ด้วย Google spreadsheet เป็น input มันสร้าง radar visualization ที่แสดง radar ส่วนตัวของคุณ เราสนับสนุนให้นักเทคโนโลยีทุกคนใช้ มัน