- Slide tổng hợp 40 nguyên tắc thực tiễn áp dụng cho thiết kế tàu vũ trụ và các dự án kỹ thuật
- Nhấn mạnh phân tích dựa trên số liệu, thiết kế lặp, và thiết kế chấp nhận lỗi là các nguyên tắc cốt lõi
- Bao gồm cảnh báo thực tế rằng tiến độ chỉ đi theo một chiều, và các ước tính ban đầu luôn bị đánh giá thấp
- Không chỉ trong kỹ thuật vũ trụ mà còn có thể áp dụng nguyên vẹn cho phần mềm, hệ thống và thiết kế startup nói chung
- Checklist thực tế giúp ngăn ngừa các sai lầm lặp đi lặp lại trong phán đoán kỹ thuật
Quy luật 1 — Kỹ thuật phải được chứng minh bằng số liệu
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- Kỹ thuật được thực hiện bằng số liệu; phân tích không có số liệu chỉ là ý kiến
- Đây là lý do sinh viên kỹ thuật phải đầu tư rất nhiều thời gian để học toán
- Thành công về mặt kỹ thuật phải có thể định lượng được
- "Hệ thống của tôi nhanh hơn" → nhanh hơn bao nhiêu?
- "Hệ thống của tôi rẻ hơn" → chi phí là bao nhiêu?
- "Hệ thống của tôi đơn giản hơn" → đo độ đơn giản như thế nào?
Quy luật 2 — Thiết kế chấp nhận lỗi
- "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
- Để thiết kế một tàu vũ trụ cho đúng cần lượng nỗ lực vô hạn, vì vậy nên thiết kế để nó vẫn hoạt động khi một số thứ bị sai
- Không được thiết kế hệ thống đòi hỏi độ tin cậy 100%
- Ví dụ thất bại: Deep Water Horizon, Fukushima
- Ví dụ về kiểm tra logic ba lớp (3 way logic checking) trong hệ thống điều khiển máy bay
Quy luật 3 — Quy trình thiết kế lặp
- "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
- Thiết kế là một quá trình lặp; số vòng lặp cần thiết luôn nhiều hơn một so với số lần bạn đã làm đến thời điểm hiện tại
- Thiết kế tốt không bao giờ thực sự hoàn thành
Quy luật 4 — Đối phó với sự thất vọng
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- Những nỗ lực thiết kế tốt nhất của bạn rồi cũng có thể trở nên vô dụng trong thiết kế cuối cùng; hãy học cách sống chung với sự thất vọng đó
- Quy luật của Bhargava: chỉ 1 trong 10 dự án nghiên cứu được áp dụng vào thực tiễn công nghiệp
- Thành công thương mại lớn nhất không đồng nghĩa với thiết kế kỹ thuật tốt nhất
- Ví dụ: Nokia N95 so với iPhone thế hệ đầu
Quy luật 5 (Quy luật của Miller) — Ba điểm quyết định một đường cong
- "Three points determine a curve."
- Ba điểm quyết định một đường cong
- Trong một tập dữ liệu, con người luôn tìm ra một mẫu hình nào đó
- Cần xác nhận xem mẫu hình đó có thật sự đến từ hiện tượng đang được nghiên cứu, hay chỉ là nhiễu đo đạc
- Giới học thuật và nghiên cứu sinh đặc biệt có xu hướng bỏ qua quy tắc này
Quy luật 6 (Quy luật của Mar) — Cảnh giác với overfitting dữ liệu
- "Everything is linear if plotted log-log with a fat magic marker."
- Trên đồ thị log-log, nếu vẽ bằng bút dạ thật to thì cái gì trông cũng tuyến tính
- Quy luật của Bigg: "Đừng phải lòng công cụ toán học; nó sẽ không yêu lại bạn"
- Không được over-fit dữ liệu
Quy luật 7 — Lãnh đạo và tổ chức nhóm
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- Khi bắt đầu một dự án thiết kế, người muốn làm trưởng nhóm nhất thường lại là người ít có khả năng đảm nhiệm việc đó nhất
- Truyện tranh Dilbert được xây dựng từ trải nghiệm ở các công ty kỹ thuật ngoài đời, chỉ là được phóng đại đôi chút
- Một phần năng lực lãnh đạo là bẩm sinh, nhưng phần lớn là thứ phải học
- Có những quản lý không biết 'tôn trọng những điều cơ bản (respect the basics)'
- Hãy hỏi một kỹ sư công nghiệp xem họ nghĩ gì về MBA
Quy luật 8 — Điểm tối ưu nằm ở khoảng giữa
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- Trong tự nhiên, điểm tối ưu gần như luôn nằm đâu đó ở khoảng giữa; hãy nghi ngờ những khẳng định rằng điểm tối ưu nằm ở cực trị
- Ví dụ kinh điển: truyền công suất tối ưu (Optimal power transfer)
- Ví dụ thực hành: điện trở cảm biến tối ưu (optimal sensor resistance)
Quy luật 9 — Thiếu thông tin không phải cái cớ
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- Không có đủ mọi thông tin cần thiết không bao giờ là lý do thỏa đáng để không bắt đầu phân tích
- Bạn phải xác định cần những giá trị nào để có thể phân tích đầy đủ hơn
Quy luật 10 — Ước lượng và phỏng đoán
- "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
- Khi còn nghi ngờ thì hãy ước lượng; trong tình huống khẩn cấp thì cứ đoán; nhưng khi có số liệu thật, nhất định phải quay lại dọn dẹp mớ hỗn độn đó
- Bạn được đào tạo để trở thành kỹ sư, không phải thầy bói
- Trong nghề này, tư duy chất lượng quan trọng hơn suy nghĩ nhanh
Quy luật 11 — Bắt đầu lại từ đầu
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- Đôi khi, cách nhanh nhất để đi đến đích là vứt bỏ mọi thứ và làm lại từ đầu
- Để biết khi nào nên làm vậy cần rất nhiều thời gian để học
- Có nhiều trường hợp trong các ngành công nghiệp lẽ ra nên làm như vậy nhưng đã không làm
- Trạm vũ trụ do thám có người lái Almaz của Liên Xô: thiết kế kỹ thuật xuất sắc, nhưng sau khi phóng đã trở nên lỗi thời trước các vệ tinh do thám điều khiển bằng máy tính
- Những chiếc 'ô tô' thời kỳ đầu
Quy luật 12 — Không có một đáp án đúng duy nhất
- "There is never a single right solution. There are always multiple wrong ones, though."
- Không bao giờ chỉ có một lời giải đúng duy nhất; nhưng luôn có nhiều lời giải sai
- Giữ tư duy cởi mở
- Kỹ thuật không phải tôn giáo
- Từ bỏ giáo điều kỹ thuật (Technical apostasy) là điều hoàn toàn được chấp nhận
- Ví dụ: tính toán tự động bằng cơ khí
- Là phương pháp chủ đạo trong Thế chiến II
- Phải đến thập niên 1960 phần cứng số mới thống trị lĩnh vực này
Quy luật 13 — Thiết kế dựa trên yêu cầu
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- Thiết kế dựa trên yêu cầu; không có lý do chính đáng nào để thiết kế một thứ 'tốt hơn' dù chỉ một chút so với mức yêu cầu đặt ra
- Khách hàng không thích trả tiền cho những tính năng họ không cần
- Cần xác định mức độ tin cậy phù hợp với ứng dụng và thiết kế theo đúng mức đó
Quy luật 14 (Quy luật của Edison) — 'Tốt hơn' là kẻ thù của 'đủ tốt'
- "Tốt hơn" là kẻ thù của "đủ tốt".
- "Tốt hơn" là kẻ thù của "tốt"
- Thực ra đây là câu trích dẫn của Voltaire
- Cần nhận ra khi hệ thống đã đạt trạng thái đủ tốt (good enough)
- Vì sự hoàn hảo đòi hỏi nguồn lực vô hạn nên hệ thống luôn có thể được cải thiện hơn nữa
- Xem luật 13
Luật 15 (Luật của Shea) — Giao diện là cốt lõi
- "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
- Khả năng cải tiến thiết kế chủ yếu xuất hiện ở các giao diện, và đây cũng là nơi dễ làm hỏng nhất
- Có nhiều kỹ sư/kỹ thuật viên thực sự hiểu rõ một hệ thống
- Nhưng rất hiếm người thực sự hiểu rõ nhiều hệ thống khác nhau
- Ví dụ: các hệ thống có tương tác phần cứng và phần mềm phức tạp thường phát sinh vấn đề ở giao diện
Luật 16 — Đừng mù quáng tin vào các phân tích trước đây
- "The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours."
- Những người trước đây từng thực hiện phân tích tương tự không hề có đường truyền trực tiếp tới trí tuệ của muôn đời; vì vậy không có lý do gì để tin phân tích của họ hơn của bạn, và đặc biệt cũng không có lý do gì để trình bày phân tích của họ như thể là của bạn
Luật 17 — Độ chính xác của ấn phẩm
- "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
- Việc một phân tích được in thành ấn phẩm không liên quan gì đến khả năng nó là đúng
- Một quan điểm nổi tiếng từ thập niên 1970:
- "1200 baud có lẽ là tốc độ tối đa mà modem điện thoại có thể đạt tới"
- Được biết đến qua phát biểu "Coding is dead"
- Trellis coded modulation đã nâng tốc độ này lên 50kbps cho đến tận thập niên 1990
Luật 18 — Tính hai mặt của kinh nghiệm quá khứ
- "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
- Kinh nghiệm quá khứ rất hữu ích để kiểm tra tính thực tế, nhưng quá nhiều "tính thực tế" cũng có thể hủy hoại một thiết kế vốn dĩ đáng giá
Luật 19 — Tầm quan trọng của sự khiêm tốn
- "The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up."
- Khả năng bạn thông minh vượt trội hơn tất cả những người khác trong lĩnh vực này là cực thấp; nếu phân tích của bạn cho thấy vận tốc giới hạn của bạn gấp đôi tốc độ ánh sáng thì có thể bạn đã phát minh ra warp drive, nhưng khả năng cao hơn nhiều là bạn đã tính sai
Luật 20 — Tầm quan trọng của phần trình bày
- "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- Một thiết kế tệ với phần trình bày tốt thì sớm muộn cũng thất bại; một thiết kế tốt với phần trình bày tệ thì thất bại ngay lập tức
- Ví dụ: Avro C102 — máy bay chở khách phản lực thương mại thứ hai trên thế giới (chênh 13 ngày)
- Bị hủy để hỗ trợ phát triển Avro Arrow
Luật 21 — Bản chất của giáo dục
- "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
- Một nửa những gì bạn nghe trong lớp học là vô dụng; giáo dục là tìm ra nửa nào là nửa nào
- Không phải các giáo sư cố tình lãng phí 50% thời gian
- Mà là đang đoán xem kỹ năng nào sẽ cần thiết trong một lĩnh vực thay đổi và tiến hóa nhanh
- Ví dụ: điện toán lượng tử
- Có thể là kiến thức thiết yếu để làm kỹ sư trong 20 năm tới, hoặc cũng có thể chỉ là mối quan tâm học thuật cho đến tận thập niên 2030
Luật 22 — Tầm quan trọng của tài liệu hóa
- "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
- Khi còn nghi ngờ, hãy tài liệu hóa. (Yêu cầu về tài liệu sẽ đạt mức tối đa ngay sau khi một chương trình kết thúc.)
- Nếu không thể giải quyết vấn đề thì đừng che giấu sự thiếu hiểu biết
- Hãy ghi lại nguyên nhân của vấn đề
- Người khác có thể tìm ra cách giải quyết nó
Luật 23 — Tính hư cấu của lịch trình
- "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
- Lịch trình bạn lập ra sẽ trông như một tác phẩm hư cấu hoàn toàn cho tới lúc khách hàng sa thải bạn vì bạn không đáp ứng được nó
Luật 24 — Cấu trúc phân rã công việc
- "It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."
- Nó được gọi là 'Work Breakdown Structure' vì phần Work còn lại sẽ tăng lên cho tới khi bạn bị Breakdown, trừ khi bạn áp đặt một Structure nào đó lên nó
Luật 25 (Luật của Bowden) — Phân tích sau khi test thất bại
- "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
- Sau một lần test thất bại, luôn có thể tinh chỉnh phân tích để cho thấy rằng ngay từ đầu bạn đã có biên an toàn âm
- Ví dụ: báo cáo tai nạn của Ủy ban An toàn Điều tra Tai nạn Giao thông Canada và Cục Hàng không Liên bang Mỹ (FAA)
- Một số thất bại xảy ra do thiếu trí tưởng tượng (diễn ý từ Frank Borman)
- Kỹ sư có thể được tha thứ vì mắc lỗi, nhưng không được tha thứ nếu che giấu lỗi
Luật 26 (Luật của Montemerlo) — Đừng làm điều ngu ngốc
- "Don't do nuthin' dumb."
- Đây là một quy tắc đáng ngạc nhiên là rất khó tuân thủ trong thực tiễn kỹ thuật
- Đừng quên những điều cơ bản
- Hãy tự làm rõ các ưu tiên của mình
Luật 27 (Luật của Varsi) — Lịch trình chỉ đi theo một hướng
- "Schedules only move in one direction."
- Lịch trình chỉ dịch chuyển theo một hướng
- Hãy để dư địa cho các vấn đề và khó khăn
- Test thất bại
- Về sau là tình huống khẩn cấp trong gia đình
- Người khác có thể giao muộn sản phẩm cần thiết dù đó không phải lỗi của bạn
- Hãy luôn để khoảng đệm lịch trình cho bản thân và cả nhóm
Luật 28 (Luật của Ranger) — Không có vụ phóng miễn phí
- "There ain't no such thing as a free launch."
- Không tồn tại chuyện phóng miễn phí
Luật 29 (Luật quản lý chương trình của von Tiesenhausen) — Ước tính chi phí và thời gian
- "Để có được ước tính chính xác về các yêu cầu cuối cùng của chương trình, hãy nhân các ước tính thời gian ban đầu với pi, và dịch dấu thập phân của các ước tính chi phí sang phải một chữ số."
- Để có được ước tính chính xác về các yêu cầu cuối cùng của chương trình, hãy nhân các ước tính thời gian ban đầu với π và dịch dấu thập phân của các ước tính chi phí sang phải một chữ số
Luật 30 (định luật thiết kế kỹ thuật của von Tiesenhausen) — Ảnh hưởng của concept art
- "Nếu bạn muốn tạo ảnh hưởng tối đa lên thiết kế của một hệ thống kỹ thuật mới, hãy học vẽ. Các kỹ sư cuối cùng lúc nào cũng thiết kế phương tiện sao cho nó trông giống concept ban đầu của họa sĩ."
- Nếu muốn tác động tối đa đến thiết kế của một hệ thống kỹ thuật mới, hãy học vẽ; các kỹ sư rốt cuộc luôn thiết kế phương tiện để nó trông giống concept ban đầu của họa sĩ
Luật 31 (định luật phát triển tiến hóa của Mo) — Giới hạn căn bản của công nghệ
- "Bạn không thể lên mặt trăng bằng cách lần lượt trèo lên những cái cây ngày càng cao hơn."
- Không thể đến mặt trăng chỉ bằng cách trèo lên những cái cây ngày càng cao hơn
- Việc hiểu các giới hạn căn bản của công nghệ/cách tiếp cận là rất hữu ích
Luật 32 (định luật demo của Atkin) — Định luật Murphy
- "Khi phần cứng hoạt động hoàn hảo, những vị khách thực sự quan trọng lại không xuất hiện."
- Khi phần cứng hoạt động hoàn hảo, những vị khách thực sự quan trọng lại không xuất hiện
Luật 33 (định luật lập kế hoạch chương trình của Patton) — Tầm quan trọng của thực thi
- "Một kế hoạch tốt được thực thi quyết liệt ngay bây giờ còn tốt hơn một kế hoạch hoàn hảo vào tuần sau."
- Một kế hoạch tốt được thực thi quyết liệt ngay lúc này tốt hơn một kế hoạch hoàn hảo vào tuần sau
- Sai lầm trong ngành: chờ đợi công nghệ 'hoàn hảo'
- Trong lúc chờ đợi, đối thủ sẽ chiếm lĩnh thị trường
Luật 34 (định luật lập kế hoạch nhiệm vụ của Roosevelt) — Thực thi thực tế
- "Hãy làm điều bạn có thể, ở nơi bạn đang ở, với những gì bạn có."
- Hãy làm điều bạn có thể, ở nơi bạn đang ở, với những gì bạn có
- Trừ khi bạn là nhà văn SF, việc thiết kế cho một công nghệ chưa tồn tại là vô nghĩa
Luật 35 (định luật thiết kế của de Saint-Exupéry) — Thiết kế hoàn hảo
- "Một nhà thiết kế biết rằng mình đã đạt đến sự hoàn hảo không phải khi không còn gì để thêm vào, mà là khi không còn gì để bỏ đi."
- Nhà thiết kế biết mình đạt đến sự hoàn hảo không phải khi không còn gì để thêm vào, mà khi không còn gì để lược bỏ
Luật 36 — Tính thanh nhã, hiệu suất, hiệu quả
- "Bất kỳ kỹ sư tầm thường nào cũng có thể thiết kế thứ gì đó thanh nhã. Một kỹ sư giỏi thiết kế các hệ thống sao cho hiệu suất cao. Một kỹ sư vĩ đại thiết kế chúng để thực sự hiệu quả."
- Một kỹ sư bình thường có thể thiết kế thứ gì đó thanh nhã; một kỹ sư giỏi thiết kế các hệ thống hiệu suất cao; một kỹ sư vĩ đại thiết kế chúng để đạt hiệu quả thực sự
- Thiết kế thanh nhã (Elegant design): hệ thống cấp nước đô thị tiêu chuẩn
- Thiết kế hiệu suất cao (Efficient design): hệ thống cấp nước của New York
- Thiết kế hiệu quả (Effective design): hệ thống thủy lợi của các nền văn minh bản địa Bắc Mỹ/Nam Mỹ (một số vẫn hoạt động hơn 1000 năm)
Luật 37 (định luật của Henshaw) — Ranh giới trách nhiệm rõ ràng
- "Một chìa khóa dẫn đến thành công trong một nhiệm vụ là thiết lập các tuyến quy trách nhiệm rõ ràng."
- Một trong những chìa khóa để nhiệm vụ thành công là thiết lập ranh giới trách nhiệm rõ ràng
- Phải chịu trách nhiệm cho hành động và quyết định của chính mình
- Đừng tin tưởng những kỹ sư (hoặc bất kỳ ai khác) từ chối chịu trách nhiệm
Luật 38 — Năng lực dẫn dắt yêu cầu
- "Năng lực dẫn dắt các yêu cầu, bất kể sách giáo khoa kỹ thuật hệ thống nói gì."
- Dù sách giáo khoa kỹ thuật hệ thống nói gì đi nữa, năng lực vẫn là thứ dẫn dắt yêu cầu
- Điều cốt lõi là nhận ra những năng lực mới nào đang được phát triển:
- Thập niên 1950: transistor
- Thập niên 1960: mạch tích hợp
- Thập niên 1970: vi xử lý
- Thập niên 1980: máy tính gia đình
- Thập niên 1990: Internet
- Thập niên 2000: điện toán không dây/di động
Luật 39 — Cấm phát triển phương tiện phóng mới
- Ba chìa khóa để giữ một chương trình không gian có người lái mới ở mức chi phí thấp và đúng tiến độ:
- Không có phương tiện phóng mới
- Không có phương tiện phóng mới
- Dù có chuyện gì xảy ra cũng đừng quyết định phát triển phương tiện phóng mới
- Cần tránh cám dỗ tin rằng một sản phẩm hoàn toàn mới lúc nào cũng tốt hơn sự tiến hóa của sản phẩm hiện có
Luật 40 — Không gian không khoan dung
- "Không gian là một môi trường hoàn toàn không khoan dung. Nếu bạn làm hỏng phần kỹ thuật, ai đó sẽ chết (và không có điểm cộng từng phần chỉ vì phần lớn phân tích là đúng...)"
- Không gian là môi trường hoàn toàn không khoan dung; nếu bạn làm hỏng phần kỹ thuật, ai đó sẽ chết (và không có chuyện cho điểm từng phần chỉ vì phần lớn phân tích là đúng)
- Các thảm họa kiểm soát kỹ thuật quy mô lớn:
- Fukushima, Chernobyl
- De Havilland Comet (lý do cửa sổ trên máy bay chở khách thương mại có góc bo tròn)
- Eastern Airline Flight 401 (hệ thống lái tự động đã đưa máy bay thương mại vào Everglades)
- Therac-25 (thiết bị xạ trị của Canada)
- Phóng ý theo Richard Feynman: "Tự nhiên không thể bị đánh lừa (Nature cannot be fooled)"
1 bình luận
Ý kiến Hacker News
Nhận định rằng trong thập niên 1990 người ta đã nâng lên 50 kilobaud bằng Trellis coded modulation là hơi không chính xác
Dung lượng Shannon tính theo băng thông và đặc tính SNR của đường dây điện thoại vào khoảng 30kb/s, và modem V.34 đã tiến rất gần giới hạn đó, đạt tới 33.6kb/s
Tuy nhiên, từ sau thập niên 1980, mạng điện thoại ngoại trừ “last mile” thực ra đã được số hóa. Nếu modem phía ISP xuất trực tiếp audio số thì về mặt lý thuyết có thể lên tới 64kb/s, nhưng trên thực tế do giới hạn công suất của FCC nên chỉ khoảng 53kb/s
Khi đó tôi làm trong nhóm nghiên cứu điều chế modem, và các kỹ sư đã quen với tư duy analog mất khá nhiều thời gian mới nhận ra tiềm năng của kênh số
Sau đó họ chuyển sang cable modem và lại quay về thế giới analog
Nếu đoạn đường tới nhà vẫn là analog thì chẳng phải vẫn bị giới hạn bởi Shannon-Nyquist sao?
Nếu giữa modem ISP và modem tại nhà là dây đồng không có bộ lọc, chẳng phải có thể truyền vài Mbps bằng UART luôn hay sao?
Mong ai đó giải thích rõ hơn phần này
Nhờ nhiều kỹ thuật mã hóa và nén khác nhau, bao gồm cả mã Trellis, và ngay cả bây giờ bạn vẫn có thể mua modem 56k của US Robotics
Law 20 diễn tả rất chính xác thực tế startup ngày nay
Giống như câu “một thiết kế tốt gặp một bài thuyết trình tệ thì sẽ thất bại ngay lập tức”, tầm quan trọng của khả năng trình bày là tuyệt đối
Giải thích tốt cũng là bằng chứng rằng họ thực sự hiểu
Nó khiến tôi nhớ tới câu “không giải thích được cho một đứa trẻ 5 tuổi thì nghĩa là chính bạn cũng chưa hiểu”
Về câu “thành công thương mại lớn nhất không phải là thiết kế kỹ thuật tốt nhất”
So sánh giữa Nokia N95 và iPhone thế hệ đầu không thật sự phù hợp. Thay vào đó, tôi đề xuất Canyon’s Law of Design Optimization — chỉ số khách hàng muốn và chỉ số nhà phát triển tối ưu hóa là hai thứ khác nhau, và đừng cố thuyết phục khách hàng rằng họ sai
iPhone thế hệ đầu có hình thức và giao diện rất xuất sắc, nhưng tính năng lại thiếu. 3G, GPS, ứng dụng bên thứ ba và camera đều yếu
Phải đến khi iPhone 3G ra mắt thì nó mới đạt được thành công thương mại thực sự
Slide cuối đang bị thiếu
Câu then chốt là: “Hãy phớt lờ mọi lời khuyên ở trên và làm điều đúng đắn”
Giữa những lời khuyên mâu thuẫn lẫn nhau, giữ được sự cân bằng mới là kỹ thuật thực sự, và đó cũng là mục tiêu khó nhất cả về mặt kỹ thuật lẫn xã hội
Nội dung của nó là “phân tích trước đó không phải chân lý tuyệt đối, và hãy tin vào phán đoán của chính mình”
PDF này có vẻ mới, nhưng Akin’s Laws of Spacecraft Design đã tồn tại từ năm 2003
Có thể xác nhận điều đó qua liên kết Web Archive
Chỉ cần nhìn vào luật đầu tiên là đủ hiểu vì sao “engineering” trong phần mềm khó có thể được gọi là kỹ thuật thực sự
Tôi đã trích dẫn luật của von Tiesenhausen từ rất lâu
Câu đó nói rằng “cuối cùng các kỹ sư sẽ thiết kế theo đúng concept của nghệ sĩ ban đầu”, và tôi thấy điều này cũng đúng hệt trong các dự án web
Người viết tài liệu ban đầu, hoặc người để lại ghi chú trong cuộc họp, thường là người quyết định hướng đi của sản phẩm.
Dù gọi là ‘agile’, trên thực tế nó vẫn phụ thuộc vào lộ trình đã hình thành
Tôi từng học môn capstone về thiết kế tàu vũ trụ ở MIT vào năm 2003 nhưng chưa từng thấy danh sách này
Khi đó dự án tập trung vào vệ tinh, và có vẻ triết lý của Akin đã được thấm vào một cách ngầm định
Ngành hàng không vũ trụ có văn hóa thiết kế bảo thủ rất mạnh nên tốc độ phát triển chậm, và trước thời Elon Musk mọi thay đổi còn chậm hơn nữa
Đặc biệt, câu “không gian là môi trường không khoan nhượng, và thất bại kỹ thuật đồng nghĩa với mất mát sinh mạng” để lại ấn tượng rất mạnh
Nó cũng trùng với thời điểm thảm họa Columbia năm 2003
Có lẽ Law 31 (hiểu giới hạn của công nghệ hiện có) đã kích hoạt Law 11 (vứt bỏ tất cả và làm lại từ đầu), còn Law 16 (đừng mù quáng tin vào các phân tích trước đó) thì củng cố điều này
Tôi thích những hệ thống không cần bảo trì và dễ thay thế
Công nghệ phần mềm rồi cũng biến mất, vì vậy nó nên có cấu trúc có thể thay thế bất cứ lúc nào như phần cứng
Lời khuyên “hãy tránh cám dỗ tin rằng một sản phẩm hoàn toàn mới lúc nào cũng tốt hơn một phiên bản tiến hóa từ sản phẩm cũ” đặc biệt khiến tôi đồng cảm