Hãy chọn công nghệ nhàm chán (2015)

• Việc tiết chế công nghệ mới và ưu tiên áp dụng công nghệ đã được kiểm chứng (boring technology) có lợi hơn cho thành công dài hạn của công ty
• Mọi công ty chỉ có khoảng 3 token đổi mới (innovation tokens), và mỗi lần chọn NodeJS, MongoDB hay một công cụ mới nổi thì sẽ tiêu tốn 1 token
• Công nghệ đã được kiểm chứng có tính năng và các kiểu lỗi (failure modes) đã được hiểu rõ, nên ít rủi ro từ các điều chưa biết mà ta thậm chí không biết mình không biết (unknown unknowns) hơn so với công nghệ mới nổi
• Việc chọn công nghệ ảnh hưởng đến cả đội ngũ và toàn tổ chức; do gánh nặng vận hành và tải nhận thức, một công cụ tạm ổn cho nhiều vấn đề thường có lợi hơn công cụ tốt nhất cho từng việc riêng lẻ
• Lựa chọn công nghệ một cách thận trọng mang lại cho kỹ sư sự tự do để tập trung vào những vấn đề lớn hơn, còn công nghệ chỉ vì bản thân công nghệ thì vô nghĩa

---

Chấp nhận sự nhàm chán (Embrace Boredom)

• Mọi công ty có khoảng 3 token đổi mới (innovation tokens) và nguồn cung này bị cố định trong một thời gian — khi đạt được độ ổn định và độ trưởng thành thì có thể tăng thêm chút ít, nhưng người ta thường đánh giá quá cao số token mình có
• Viết website bằng NodeJS, dùng MongoDB, hay áp dụng một công nghệ service discovery mới ra mắt chưa đến 1 năm đều tiêu tốn 1 token đổi mới; còn tự viết cơ sở dữ liệu thì là tự đẩy mình vào rắc rối lớn
  • Những lựa chọn này có thể hợp lý nếu bạn là công ty tư vấn javascript hoặc công ty cơ sở dữ liệu, nhưng đa số công ty đang theo đuổi những sứ mệnh lớn như tái định nghĩa thương mại toàn cầu hay tái phát minh thanh toán web — dồn sự chú ý hữu hạn vào những mảng như ssh là con đường ngắn nhất dẫn đến thất bại hoặc làm chậm thành công
• "Nhàm chán (boring)" không đồng nghĩa với "tệ (bad)", và cũng có những công nghệ vừa nhàm chán vừa tệ — những ví dụ nhàm chán nhưng đủ tốt gồm MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• Ưu điểm của công nghệ nhàm chán không chỉ nằm ở năng lực (capabilities) mà còn ở chỗ cả các kiểu lỗi (failure modes) của chúng cũng đã được hiểu rõ
• Trong việc chọn công nghệ luôn tồn tại cả known unknowns (ví dụ: không rõ cơ sở dữ liệu sẽ hành xử thế nào khi CPU chạm 100%) lẫn unknown unknowns (ví dụ: không biết rằng việc ghi thống kê lại gây ra GC pause), và công nghệ càng mới thì quy mô của unknown unknowns càng lớn hơn nhiều

Tối ưu ở phạm vi toàn cục (Optimize Globally)

• Ưa chuộng công nghệ nhàm chán là một thiên kiến tốt, nhưng không phải yếu tố duy nhất cần cân nhắc; lựa chọn công nghệ có phạm vi ảnh hưởng (scope) đến đội ngũ, tổ chức và toàn bộ hệ thống
• Việc thêm công nghệ luôn có chi phí — nếu đã dùng Ruby mà lại thêm Python thì độ phức tạp sẽ vượt quá lợi ích cận biên; nhưng trong các cuộc tranh luận như Python vs Scala hay MySQL vs Redis, người ta thường vứt bỏ ràng buộc và hô hào "công cụ tốt nhất cho công việc (best tool for the job)"
• Bản chất của công việc là ánh xạ bài toán kinh doanh vào không gian lời giải của các lựa chọn phần mềm; nếu việc lựa chọn không có chi phí thì ta có thể chọn công cụ tối ưu cục bộ cho từng bài toán, nhưng ngoài đời thực luôn có chi phí đó
  • Chi phí ấy là vận hành (operations) và ở mức độ thấp hơn là tải nhận thức (cognitive overhead) — kiến thức cần cho giám sát, kiểm thử đơn vị, sửa lỗi, các init script, v.v. tích tụ rất nhanh
• Vấn đề của tư duy "công cụ tốt nhất cho công việc" là nhìn "tốt nhất" và "công việc" một cách thiển cận — công việc thật sự là giúp công ty tiếp tục tồn tại, và công cụ "tốt nhất" là công cụ giữ vị trí tệ ít nhất (least worst) trên nhiều bài toán nhất có thể
• Chi phí dài hạn để giữ cho hệ thống vận hành ổn định sẽ lấn át sự bất tiện trong lúc xây dựng, và những nhà phát triển trưởng thành, làm việc hiệu quả đều hiểu điều đó

Đôi khi hãy chọn công nghệ mới (Choose New Technology, Sometimes)

• Nếu đẩy lập luận trên đến cực đoan thì bạn sẽ xây cả website chỉ bằng Java, điều này không thực tế — cần có cách để bổ sung công cụ mới vào hộp đồ nghề
• Rốt cuộc công nghệ mới cũng tạo ảnh hưởng trên toàn công ty, nên việc thêm vào là quyết định cần mức độ hiển thị trên toàn công ty (company-wide visibility) — cần đặt ra kỳ vọng văn hóa rằng "đây là việc tất cả chúng ta cùng thảo luận"
• Thói quen đáng khuyến nghị nhất là tự hỏi liệu có thể giải quyết vấn đề trước mắt mà không thêm công nghệ mới hay không — điều này giúp nhận ra những trường hợp mà cái gọi là "vấn đề" thực chất chỉ là ai đó muốn dùng công nghệ ấy, và khi đó nên dừng lại ngay
  • Chỉ với một số ít lựa chọn công nghệ cũng có thể đi rất xa; câu trả lời thực tế hiếm khi là "không làm được" mà thường là "làm được nhưng quá khó" — nếu bạn cảm thấy không thể đạt mục tiêu với nguồn lực hiện tại thì có thể là bạn chưa suy nghĩ đủ sáng tạo
• Sẽ rất hữu ích nếu ghi lại rõ ràng vì sao việc giải bài toán đó trong stack hiện tại lại đắt đỏ và khó khăn một cách quá mức
• Việc chọn công nghệ mới có thể là bổ sung thuần túy (ví dụ: chưa có caching nên thêm memcached), hoặc có thể chồng lấp hay thay thế thứ đang có — nếu là thay thế thì cần đặt kỳ vọng rõ ràng về việc di chuyển các chức năng hiện có, và chính sách thường là "cam kết migration" kèm lịch trình được đề xuất
  • Mục đích là giữ đống tàn tích ở mức có thể quản lý và ngăn việc các lời giải tối ưu cục bộ mọc lên tràn lan
• Quy trình này không hề nặng nề: chỉ là vài câu hỏi cần điền như một đầu việc và một cuộc họp để thảo luận; nếu một công nghệ hay dịch vụ mới vượt qua cửa ải này một cách suôn sẻ thì việc thêm nó là hợp lý

Cứ phát hành đi (Just Ship)

• Lập trình đa ngôn ngữ (polyglot programming) được quảng bá như một lời hứa rằng nếu cho lập trình viên toàn quyền chọn công cụ thì họ sẽ giải quyết vấn đề hiệu quả hơn, nhưng đó cùng lắm là một cách định nghĩa vấn đề ngây thơ, hoặc tệ hơn là kiểu suy luận tự đồng bộ hóa — toil trong vận hành hằng ngày sẽ đè nặng lên lập trình viên
• Chính việc lựa chọn công nghệ một cách cẩn trọng mới trao cho kỹ sư tự do để suy nghĩ về những câu hỏi lớn hơn, còn công nghệ chỉ vì công nghệ là dầu rắn

Trường hợp của Etsy (chú thích)

• Etsy đã khổ sở rất nhiều vì vấn đề này ở giai đoạn đầu — sau khi tuyển nhiều lập trình viên Python, họ đi tìm việc cho họ làm rồi tạo ra một tầng trung gian vô nghĩa, và mất nhiều năm để gỡ bỏ nó / đồng thời độ trễ tìm kiếm ở bách phân vị 90 vào khoảng 2 phút — Etsy không thất bại, nhưng việc không phát hành được gì trong nhiều năm đã làm thành công đến chậm hơn
• Phần giao nhau giữa công nghệ nhàm chán và công nghệ tệ thường được gọi là "enterprise software", nhưng cách gọi này có thể không chính xác
• Trường hợp activity feeds của Etsy - được triển khai trong giai đoạn phần lớn hệ thống được thống nhất bằng PHP, MySQL, Memcached và Gearman / việc triển khai phức tạp hơn nhiều so với dùng công cụ như Redis, nhưng với stack đó vẫn hoàn toàn xây được
  • Trong những năm sau, khi sự chú ý chuyển sang nơi khác, mức sử dụng activity feeds tăng 20 lần, nhưng nhờ nền tảng dùng chung mà nó vẫn hoạt động bình thường mà không cần thay đổi riêng nào — lợi ích dài hạn của sự tiết chế trong lựa chọn công nghệ
  • Tuy vậy đây không phải chủ nghĩa tuyệt đối — activity feeds dựa trên memcached được xem là thực dụng, nhưng Etsy sẽ không vì thế mà triển khai tìm kiếm chuyên sâu có tìm kiếm phân diện hoàn toàn bằng PHP, nên họ đã dùng Solr