Tại sao ngành CNTT không thể cung cấp các dự án lớn, không có lỗi một cách nhanh chóng như trong các ngành khác?

Sau khi xem loạt MegaSt cấu trúc của National Geographic , tôi đã ngạc nhiên khi các dự án lớn được hoàn thành nhanh như thế nào. Sau khi công việc sơ bộ (thiết kế, thông số kỹ thuật, v.v.) được thực hiện trên giấy, việc thực hiện các dự án lớn chỉ mất vài năm hoặc đôi khi vài tháng .

Ví dụ, Airbus A380 "chính thức ra mắt vào ngày 19 tháng 12 năm 2000" và "vào đầu tháng 3 năm 2005" , máy bay đã được thử nghiệm. Điều tương tự cũng xảy ra với tàu chở dầu khổng lồ, tòa nhà chọc trời, v.v.

So sánh điều này với sự chậm trễ trong ngành công nghiệp phần mềm, tôi không thể tự hỏi tại sao hầu hết các dự án CNTT lại quá chậm, hay chính xác hơn, tại sao chúng không thể nhanh và không có lỗi, ở cùng một quy mô, cho đủ người?

Các dự án như Airbus A380 có cả hai:

• Những rủi ro lớn không lường trước được: mặc dù đây không phải là máy bay đầu tiên được chế tạo, nó vẫn đẩy các giới hạn của công nghệ và những thứ hoạt động tốt cho các máy bay nhỏ hơn có thể không hoạt động cho loại lớn hơn do các ràng buộc vật lý; theo cách tương tự, các công nghệ mới được sử dụng chưa được sử dụng, vì ví dụ chúng không có sẵn vào năm 1969 khi Boeing 747 được thực hiện.

• Rủi ro liên quan đến nguồn nhân lực và quản lý nói chung: mọi người bỏ việc giữa dự án, không thể tiếp cận một người vì cô ấy đang đi nghỉ, lỗi người thường, v.v.

Với những rủi ro đó, mọi người vẫn đạt được các dự án như những chiếc máy bay lớn đó trong một khoảng thời gian rất ngắn và mặc dù sự chậm trễ giao hàng, những dự án đó vẫn cực kỳ thành công và có chất lượng cao.

Khi nói đến phát triển phần mềm, các dự án hầu như không lớn và phức tạp như một máy bay (cả về mặt kỹ thuật và quản lý), và có ít rủi ro không lường trước được từ thế giới thực.

Tuy nhiên, hầu hết các dự án CNTT đều chậm và muộn và việc thêm nhiều nhà phát triển vào dự án không phải là một giải pháp (từ một nhóm mười nhà phát triển đến hai nghìn đôi khi sẽ cho phép phân phối dự án nhanh hơn, đôi khi không và đôi khi sẽ chỉ gây hại cho dự án và tăng nguy cơ không hoàn thành nó).

Những chiếc vẫn được phân phối thường có thể chứa rất nhiều lỗi, yêu cầu các gói dịch vụ liên tục và cập nhật thường xuyên (hãy tưởng tượng "cài đặt bản cập nhật" trên mỗi chiếc Airbus A380 hai lần mỗi tuần để vá lỗi trong sản phẩm ban đầu và ngăn máy bay gặp sự cố).

Làm thế nào có thể giải thích sự khác biệt? Có phải do thực tế là ngành công nghiệp phát triển phần mềm còn quá trẻ để có thể quản lý hàng ngàn người trong một dự án để cung cấp các sản phẩm quy mô lớn, gần như không có lỗi rất nhanh?

Death March của Ed Yourdon chạm vào một số câu hỏi loại meta này.

Nói chung, ngành công nghiệp phần mềm thiếu rất nhiều thứ sau đây, điều này cản trở các dự án lớn.

• Tiêu chuẩn hóa và phân tích mục công việc.

  • Điều này chắc chắn đã trở nên tốt hơn, nhưng các cấu trúc thiết kế vẫn không có ở đó để phá vỡ một hệ thống lớn. Theo một số cách, phần mềm thậm chí không thể đồng ý về những gì cần thiết cho một dự án nhất định, ít có khả năng phân chia mọi thứ thành các thành phần.
  • Không gian vũ trụ, xây dựng công trình, ô tô, v.v., tất cả đều có kiến ​​trúc rất dựa trên thành phần với giao diện chặt chẽ hợp lý để cho phép phát triển song song hoàn toàn. Phần mềm vẫn cho phép quá nhiều chảy máu trong các khu vực tương ứng.

• Một cơ thể lớn của các dự án tương tự, thành công. A380 không phải là máy bay lớn đầu tiên mà Airbus chế tạo. Có rất nhiều ứng dụng phần mềm lớn ngoài kia, nhưng nhiều trong số chúng đã bị ảnh hưởng nghiêm trọng ở khía cạnh này hay khía cạnh khác và sẽ không đến gần được gọi là "thành công".

• Một cơ thể lớn của các nhà thiết kế và xây dựng đã làm việc trên một số dự án tương tự và thành công. Liên quan đến vấn đề dự án thành công, không có tài năng của con người đã ở đó, đã làm điều đó khiến mọi thứ trở nên rất khó khăn từ quan điểm lặp lại.

• "Không bao giờ" xây dựng điều tương tự hai lần. Theo nhiều cách, một chiếc máy bay cũng giống như bất kỳ chiếc máy bay nào khác. Nó có cánh, động cơ, ghế ngồi, vv .. Các dự án phần mềm lớn hiếm khi lặp lại. Mỗi nhân hệ điều hành là khác nhau đáng kể. Nhìn vào sự chênh lệch trong các hệ thống tập tin. Và đối với vấn đề đó, có bao nhiêu HĐH thực sự độc đáo? Một số lớn trở thành bản sao của một mục cơ sở tại một số điểm. AIX , Solaris , HP-UX , ... Herald trở lại AT & T System V . Windows đã có một lượng đáng kinh ngạc kéo về phía trước qua mỗi lần lặp. Các biến thể Linux nói chung đều quay trở lại cùng lõi mà Linus đã bắt đầu. Tôi đưa nó lên, bởi vì các biến thể có xu hướng lan truyền nhanh hơn các hệ điều hành độc quyền, độc quyền thực sự.

• Dự toán dự án thực sự xấu. Vì hệ số lặp lại rất thấp, thật khó để dự đoán nó sẽ lớn đến mức nào và sẽ mất bao lâu để xây dựng một cái gì đó. Cho rằng các nhà quản lý và quản lý dự án không thể đặt tay vào mã và thực sự xem những gì đang được thực hiện, những kỳ vọng không thực tế về thời gian được tạo ra.

• QA / QC không được nhấn mạnh nhiều như nó có thể hoặc nên dành cho các dự án lớn hơn. Điều này quay trở lại việc có các giao diện lỏng lẻo hơn giữa các thành phần và không có các thông số kỹ thuật cứng nhắc về cách các thành phần nên hoạt động. Sự lỏng lẻo đó cho phép những hậu quả không lường trước được và cho các con bọ chui vào.

• Trình độ chuyên môn có thể đo lường được. Nói chung, mọi người nói về số năm họ đã làm việc bằng ngôn ngữ X hoặc lập trình. Thời gian trong đang được sử dụng như là một thay thế cho tầm cỡ hoặc chất lượng kỹ năng. Như đã được đề cập nhiều lần trước đây, phỏng vấn và tìm kiếm tài năng lập trình tốt là khó. Một phần của vấn đề là định nghĩa "tốt" vẫn rất chủ quan.

Tôi không có nghĩa là tất cả tiêu cực, và tôi nghĩ rằng ngành công nghiệp phần mềm đã có những bước tiến đáng kể từ nơi chúng ta đã đến. Các diễn đàn như thế này và những người khác đã thực sự giúp thúc đẩy cuộc trò chuyện và thảo luận về các nguyên tắc thiết kế. Có những tổ chức làm việc để chuẩn hóa kiến ​​thức "cơ bản" cho các kỹ sư phần mềm. Chắc chắn có chỗ để cải thiện, nhưng tôi nghĩ ngành công nghiệp đã đi một chặng đường dài trong một khoảng thời gian hợp lý ngắn.

Câu trả lời là đáng ngạc nhiên đơn giản: những 'ngành công nghiệp khác' làm có tỷ lệ thất bại cao. Chúng ta chỉ đang so sánh những điều sai trái. Phần mềm viết thường được gọi là 'xây dựng', và vì vậy chúng tôi so sánh nó với các giai đoạn sản xuất hoặc xây dựng trong các ngành công nghiệp khác. Nhưng nếu bạn nhìn vào nó, nó hoàn toàn không phải là thiết kế : đó là thiết kế . Thiết kế phần mềm được viết bằng mã và việc xây dựng được thực hiện bằng máy tính, cho dù bằng cách biên dịch phần mềm hoặc trực tiếp giải thích nó khi đang di chuyển.

Nhiều thiết kế trong các ngành công nghiệp khác hoặc mất nhiều thời gian hơn so với ước tính ban đầu, chi phí cao hơn hoặc đơn giản là không bao giờ thấy hoàn thành. Nghe có vẻ quen?

Vậy, chúng ta đang làm gì khi lên kế hoạch cho phần mềm? Vâng, chúng tôi vẫn đang thiết kế, nhưng ở giai đoạn sớm hơn.

Trong phần mềm, không có dây chuyền sản xuất lưu ý. Xây dựng thành phần cuối cùng là (tương đối) rẻ, và sao chép sản phẩm cuối cùng đó là hoàn hảo và miễn phí hiệu quả - bạn sao chép các tạo phẩm xây dựng.

Để chỉ ra một số số liệu:

1. Thay đổi yêu cầu sau khi thực hiện bắt đầu ; ví dụ khi chiếc Airbus A380 đầu tiên bắt đầu được tạo ra trong nhà máy, tôi không thể tin rằng nếu ai đó muốn có thêm 200 chỗ ngồi, những chiếc đó sẽ được đặt ở đó; nhưng trong một dự án phần mềm lớn ngay cả sau khi các lập trình viên bắt đầu phát triển, có thể thêm 5 loại người dùng khác.
2. Độ phức tạp - các dự án phần mềm lớn vô cùng phức tạp; có lẽ là những dự án phức tạp nhất do con người thiết kế và phát triển;
3. Không đủ tài nguyên được dành cho giai đoạn kiến ​​trúc và thiết kế ;
4. Lĩnh vực non nớt - công nghệ phần mềm là một ngành học tương đối trẻ so với các chị em kỹ thuật khác; điều này có hai hàm ý: a) Không có nhiều heuristic và thực hành tốt; b) Không có nhiều chuyên gia rất có kinh nghiệm;
5. Thiếu bằng chứng toán học - trong hầu hết các trường hợp, các phương pháp chính thức toán học không được sử dụng để chứng minh rằng một phần mềm hoạt động theo yêu cầu; thay vì kiểm tra được sử dụng. Điều này không đúng trong các lĩnh vực kỹ thuật khác phụ thuộc nhiều vào toán học; Lý do của điều này là phức tạp;
6. Rush - nhiều nhà quản lý có thời hạn không thể thực hiện được; vì vậy chất lượng mã được đặt thứ hai, vì thời hạn.

Trả lời đúng câu hỏi - Tôi có xu hướng tin rằng những người khác có kỳ vọng rất cao (đặc biệt là trong thời gian giao hàng) từ các lập trình viên và không hiểu chính xác mức độ khó của việc lập trình phần mềm lớn.

Tiền đề của câu hỏi là một chút thiếu sót. Cả A380 và Boeing 787 đều được giao hàng muộn.

Trong trường hợp A380, phần lớn sự chậm trễ là do các đơn vị Airbus của Pháp và Đức sử dụng các phiên bản phần mềm thiết kế CATIA khác nhau và hơi không tương thích . Điều này thể hiện rõ ràng là dây nịt không phù hợp với máy bay.

CATIA, đây là phần mềm thiết kế máy bay được sử dụng rộng rãi nhất, nhưng ai đó đã đánh rơi quả bóng cấu hình phần mềm.

Máy bay Boeing 787 cũng bị sự chậm trễ liên quan đến phần mềm, nhưng hầu hết các vấn đề của nó là các vấn đề máy bay mới truyền thống hơn như kiểm soát trọng lượng và cung cấp các bộ phận không đạt tiêu chuẩn của các nhà cung cấp.

Cả A380 và B787 đều phải sửa đổi thiết kế cánh sau khi máy bay ban đầu có vấn đề về cấu trúc.

Các dự án phức tạp lớn là khó khăn cho con người trong tất cả các lĩnh vực.

Anh chàng nhà chọc trời đây. Không chắc chắn nếu tôi có thể trả lời câu hỏi của bạn nhưng tôi chắc chắn có thể làm sáng tỏ một số mục khác nhau trong chuỗi. Các tòa nhà thực sự xảy ra rất nhanh. Một hạn chế lớn là miền địa phương (quy định). Nhưng nói chung phải mất từ ​​3 đến 10 năm cho một tòa nhà cao tầng từ đầu đến cuối.

Tôi nghĩ rằng so sánh một tòa nhà mới với một dự án phần mềm mới là không chính xác. Một tòa nhà mới gần với phiên bản mới của kernel hoặc HĐH. Về mặt này phát triển phần mềm nhanh hơn nhiều. Chúng tôi không bao giờ xây dựng từ số 0 vì đây sẽ là một nhiệm vụ rủi ro cao mà khách hàng sẽ không bao giờ đăng ký. Hầu hết thiết kế và phát triển trong các tòa nhà là phái sinh của các dự án đã được chứng minh và hoàn thành.

Từ kinh nghiệm cá nhân, chỉ một trong mười dự án được xây dựng. Quá trình này dựa trên sự phát triển chứ không phải do thiết kế, vì vậy thời điểm giá thép tăng lên, toàn bộ dự án nằm ngoài cửa sổ, hoặc được thiết kế, vì thiết kế là thành phần rẻ tiền của quy trình.

Thiết kế mất một tháng để lên ý tưởng, hai đến sáu tháng để thiết kế phát triển, sáu tháng nữa để chi tiết và tài liệu xây dựng của một nhóm kiến ​​trúc sư, tư vấn quy hoạch, kỹ sư kết cấu, kỹ sư gió, kỹ sư dịch vụ, tư vấn số lượng và chi phí, khảo sát, kỹ sư tiếp cận và danh sách tiếp tục ...

Đối số của ảo so với vật lý là không chính xác. Chúng tôi cũng làm việc chủ yếu với các công cụ ảo và hơn nữa, chúng tôi đều ở xa thời gian và quy mô từ sản phẩm cuối cùng của chúng tôi. Trong hầu hết các trường hợp, chúng tôi thậm chí không thể kiểm tra các khía cạnh của các tòa nhà ở quy mô mockup và chúng tôi sử dụng mô phỏng để thử dự đoán những gì có thể xảy ra.

Sự phức tạp-khôn ngoan có những khác biệt, nhưng nhìn chung nó có thể giống nhau. Chúng tôi không chỉ có các đơn vị liên quan và nhiều cấp độ trừu tượng và giao diện mà còn mọi người rất chuyên về các phần nhỏ của quy trình khiến việc giao tiếp trở nên rất khó khăn.

Đối với lập luận của thiết kế so với phát triển, tôi nghĩ cả hai quá trình đều được thiết kế xây dựng. Nghe có vẻ tốt về mặt học thuật để ngăn cách chúng nhưng không thể thiết kế nếu bạn không biết mọi thứ hoạt động như thế nào. Bạn chỉ cần tăng nguy cơ thất bại.

Nhìn chung, ước tính của tôi (có khả năng sai) theo câu hỏi của OP là lập trình là một nghệ thuật hơn là kỹ thuật. Tại sao mọi người sẽ có niềm vui và thậm chí làm điều đó miễn phí, tìm thấy biểu hiện và sự thanh lịch trong đó? Khoa học máy tính cũng là một môn khoa học hơn là kỹ thuật. Tại sao bạn lại cố gắng chứng minh các thuật toán thay vì chỉ vá các phần hiện có lại với nhau và làm việc để khiến mọi thứ chỉ hoạt động? Không chắc chắn nếu điều này có ý nghĩa gì; Tôi không phải là một người phần mềm.

Một khía cạnh gây ấn tượng với tôi về thiết kế và phát triển phần mềm là về chính phương tiện. Máy tính làm cho con người làm việc trung tâm rất không tự nhiên. Tất cả mọi thứ là rất rõ ràng và có ít dung sai. Thật khó để làm việc theo cách của bạn xung quanh vấn đề này, và một số người thoát khỏi nó bằng cách vứt bỏ sự phức tạp bên trong. Nếu không có gì khác điều này có thể có liên quan đến nó?

Sau đó, thiết kế của những người đã mất bao lâu? Năm? Hai? Mười năm? Thiết kế là phần phức tạp nhất của việc xây dựng một cái gì đó, bản thân việc xây dựng là dễ dàng.

Dựa trên bài viết này , nó đang dần được hiểu, rằng phát triển phần mềm chủ yếu là quá trình thiết kế trong đó tài liệu thiết kế là chính mã nguồn. Và quy trình thiết kế hoàn toàn khác với quy trình sản xuất. Nó đòi hỏi những người có kinh nghiệm và không thể lập kế hoạch, bởi vì ngay cả những thay đổi yêu cầu nhỏ cũng có thể dẫn đến những thay đổi lớn trong kiến ​​trúc tổng thể của dự án. Sự hiểu biết này là cơ sở cho các phương pháp nhanh , tập trung vào việc cải thiện chất lượng mã làm tài liệu thiết kế cuối cùng và lấy thử nghiệm và gỡ lỗi như một phần của quy trình thiết kế, giống như họ thử nghiệm các mô hình máy bay trong các hầm gió.

Việc xây dựng được xử lý tự động bởi trình biên dịch. Và nhờ đó, chúng tôi có thể xây dựng toàn bộ sản phẩm trong vài phút.

Lý do tại sao các dự án phần mềm kết thúc với sự chậm trễ lớn và chi phí tăng cao là bởi vì các nhà quản lý vẫn nghĩ rằng họ có thể ước tính, dự đoán và lên kế hoạch cho một quy trình thiết kế như vậy. Điều này phản tác dụng thường xuyên hơn nó thực sự hợp lệ. Họ vẫn nghĩ rằng bằng cách buộc mọi người vào một quy trình xây dựng cứng nhắc, bằng cách nào đó họ có thể tăng chất lượng mặc dù kết quả cuối cùng là ngược lại với chi phí tăng và thời hạn bỏ lỡ.

Hãy tưởng tượng, ở giữa thiết kế của Airbus A380, một người nào đó đã lên kế hoạch cho một cuộc họp và nói, "Heh, có thể xây dựng nó như một bộ ba?" Những người khác tham gia nói, "Yeah, yeah. Một bộ ba. Nhiều cánh hơn là tốt hơn." Những năm tiếp theo được dành để biến thiết kế A380 thành một bộ ba. Trong một cuộc họp khác, một người nào đó nói, "Một bộ ba? Đó là cũ. Chúng tôi muốn một bộ ba. Chỉ cần loại bỏ một trong những đôi cánh."

Hoặc hãy tưởng tượng, ở giữa một dự án xây dựng cầu, có người nói: "Heh, chúng ta vừa thỏa thuận với một công ty vận tải. Họ cần cây cầu cao hơn 40 feet, vì tàu của họ cao hơn nhiều. . "

Đây chỉ là một số lý do tại sao các dự án phần mềm, lớn và nhỏ, kết thúc thất bại với tốc độ đáng báo động.

Là một người có nền tảng kỹ thuật cơ khí làm việc trong CNTT, tôi thường tự hỏi về lý do tỷ lệ thành công thấp trong CNTT.

Như những người khác trong chủ đề này, tôi cũng thường quy các thất bại cho sự non nớt của CNTT, thiếu các tiêu chuẩn chi tiết (vâng tôi nghiêm túc, bạn đã bao giờ kiểm tra bảng tiêu chuẩn của một bu lông đơn giản chưa?) Và thiếu tiêu chuẩn hóa các thành phần và mô-đun.

Các ngành công nghiệp khác, như xây dựng công trình hoặc đóng tàu cũng có nhiều "con đường bị đánh bại" hơn: kiến ​​thức và kinh nghiệm về một nguyên mẫu giải pháp cụ thể, ở dạng tùy chỉnh - được sử dụng lại nhiều lần. Đã bao giờ tự hỏi tại sao các tòa nhà, tàu hoặc máy bay có kích thước và mục đích khác nhau bằng cách nào đó trông rất giống nhau? (có ngoại lệ cho quy tắc tất nhiên ...)

Đó là bởi vì những nguyên mẫu này được nghiên cứu kỹ, hiểu rõ, thường được sử dụng và có một hồ sơ theo dõi đã được chứng minh. Không phải vì nó không thể được thực hiện theo bất kỳ cách nào khác. Trong tiêu chuẩn hóa CNTT hiếm khi xảy ra: các dự án (lớn) có xu hướng phát minh lại các thành phần, thực hiện nghiên cứu và phân phối cùng một lúc và với cùng một người!

Những điều này chắc chắn sẽ dẫn đến các sản phẩm một lần, tốn kém để phát triển và dịch vụ, dễ bị lỗi và thất bại theo những cách không thể đoán trước trong điều kiện không chắc chắn. Và vì điều này, tất nhiên, những sản phẩm này nhanh chóng lỗi thời hơn, được viết ra và thay thế với chi phí lớn không kém chỉ với những sản phẩm tốt hơn một chút. Những gì CNTT cần là tương đương với cuộc cách mạng công nghiệp, đã biến các nghệ nhân trung niên thành các nhà máy hiệu quả.

Điều đó nói rằng, có những yếu tố làm cho CNTT thực sự độc đáo tuy nhiên. Trái ngược với những ngành được đề cập khác, CNTT thực sự phổ biến: nó được sử dụng trong mọi khía cạnh của cuộc sống hiện đại của chúng ta. Vì vậy, đó là một phép màu nhỏ CNTT đạt được nhiều tiến bộ này và có khả năng mang lại kết quả như mong muốn.

Tôi sợ rằng tôi không đồng ý với tuyên bố của bạn.

Airbus và Boeing là hai ví dụ về các công ty chế tạo máy bay. Có bao nhiêu công ty chế tạo máy bay? Rất ít, nếu bạn so sánh nó với bao nhiêu công ty xây dựng phần mềm.

Nó cũng dễ dàng không kém để bắt vít một dự án máy bay cũng như làm hỏng một dự án phần mềm. Nếu chỉ có rào cản gia nhập quá thấp trong ngành chế tạo máy bay cũng như trong ngành công nghiệp phần mềm, bạn chắc chắn sẽ thấy nhiều dự án máy bay thất bại.

Nhìn vào xe ô tô; Có những nhà sản xuất chất lượng cao chế tạo những chiếc ô tô rất bền và cao cấp (nghĩ là Land Rover, Mercedes) và có những nhà sản xuất ô tô sẽ không tồn tại được một năm mà không phải sửa chữa chúng (nghĩ Kia hay Cherry). Đây là một ví dụ hoàn hảo về một ngành công nghiệp có rào cản gia nhập thấp hơn một chút, bạn bắt đầu có những người chơi yếu hơn.

Phần mềm cũng không khác. Mặt khác, bạn có rất nhiều sản phẩm lỗi, Windows, Office, Linux, Chrome hoặc Google Search là những dự án chất lượng cao được giao đúng thời hạn và có mức chất lượng tương đương máy bay.

Một điểm khác mà nhiều người bỏ lỡ là việc bảo trì một chiếc xe hơi, tàu chở dầu hoặc máy bay mà chúng ta coi là một thực tế của cuộc sống. Mỗi máy bay phải trải qua kiểm tra kỹ thuật trước khi cất cánh. Bạn phải kiểm tra-up xe của bạn mỗi k vài dặm và làm công cụ để bình thường như dầu thay đổi, lốp thay đổi.

Phần mềm cũng cần điều đó. Nếu chỉ những người dành nhiều thời gian cho chẩn đoán, phòng ngừa hoặc kiểm tra trạng thái và chất lượng của phần mềm như họ làm với các sản phẩm cơ học / vật lý, tôi sẽ mong đợi những tuyên bố như thế này ít hơn. Bạn có đọc nhật ký ứng dụng của mình mỗi lần trước khi khởi chạy không? Chà .. nếu đó là một chiếc máy bay bạn sẽ phải ;-)

Các khối xây dựng kỹ thuật số có thể là 1 hoặc 0. Không có phần giữa.

Một thiết kế cơ học có một mức độ kéo. Tôi có thể đặt một đinh tán nhỏ hơn hoàn hảo vào một cây cầu và rất có thể nó sẽ không rơi xuống, tuy nhiên, trong mã dù chỉ một lần đặt 0 trong đó một số 1 có thể làm hỏng toàn bộ chương trình.

Do tính chất logic và tương tác của điện toán, bất kỳ thay đổi nào, thậm chí rất nhỏ, có thể dẫn đến thất bại nghiêm trọng.

Tôi thường tự hỏi điều tương tự. Nó chắc chắn cảm thấy (đôi khi) giống như chúng ta là một nhóm nghiệp dư không biết chúng ta đang làm gì. Tôi không thích những lời giải thích đổ lỗi cho các nhà quản lý hoặc các yếu tố bên ngoài khác - chúng tôi, các nhà phát triển phải chịu trách nhiệm cho những gì chúng tôi tạo ra.

Tôi nghĩ rằng chúng ta đang ở trong một doanh nghiệp mà lỗi là giá rẻ . Phần mềm vá là rẻ, so với việc xây dựng lại một tòa nhà chọc trời, hoặc thu hồi mỗi điện thoại di động được bán.

Điều này đã tạo ra một nền văn hóa nơi bọ là một phần của cuộc sống hàng ngày . Họ được chấp nhận với một cái nhún vai. Trong khi một số lỗi có lẽ là không thể tránh khỏi, chúng có nên chi phối công việc hàng ngày của chúng ta không? Tôi hoàn toàn hiểu những người quản lý không cảm thấy rằng QA đáng để gặp rắc rối, chính xác là vì dù sao họ cũng mong đợi lỗi. Tôi không hiểu các lập trình viên, những người không nỗ lực để tạo ra mã không có lỗi, bởi vì sửa lỗi rất nhàm chán.

Về bản chất tôi tin rằng đó là một vấn đề văn hóa, và tôi hy vọng nó sẽ thay đổi.

Các tiêu chuẩn và thực hành kỹ thuật rất khác nhau trong CNTT (như một ngành độc lập) so với hàng không vũ trụ . Điều này có lẽ dễ hiểu nhất bằng cách xem xét cách các chuyên gia CNTT phản ứng khi gặp các tài liệu tiêu chuẩn cho CNTT trong ngành hàng không vũ trụ . Ví dụ, các tiêu chuẩn chung của Strike Strike Fighter C ++ đã xuất hiện trên Internet trong thời gian gần đây.

Nhiều người từ chức tỏ ra bỉ ổi hoặc đăm chiêu (ước chúng ta có thể làm theo cách đó); và nhiều người phản ứng với sự chế giễu, cho rằng không có cách nào thiết thực để cung cấp sản phẩm tiêu dùng theo cách này. Điều này thậm chí có thể đúng, dựa trên sự mong đợi, không phải của người tiêu dùng, mà là của quản lý. Có rất nhiều sự ngờ vực đối với các lập trình viên, những người chỉ viết mã và viết mã trong vài tuần, không giới thiệu bất cứ điều gì. Chúa giúp các lập trình viên chỉ đơn thuần thiết kế một cái gì đó trong hai tuần. Không như vậy với máy bay.

Trong phần mềm, mọi người thực sự mong đợi có một cái gì đó ngay bây giờ. Chắc chắn, lý luận đi, sẽ mất một chút thời gian để có nó thực sự vững chắc; Nhưng chúng ta không thể có một số điều phức tạp được mô tả bằng các thuật ngữ đơn giản trong một tuần? Người ta cũng học được rằng những điều phức tạp được mô tả bằng thuật ngữ trung thực, phức tạp hiếm khi kích thích trí tưởng tượng; và do đó, nhiều kỹ sư cuối cùng trở nên đồng lõa trong một thế giới tưởng tượng về những điều thực sự đơn giản được kết hợp theo những cách sáng tạo (trái ngược với một thế giới của những điều khó khăn được thực hiện rất tốt).

Một số thứ từ tôi:

1- Tiêu chuẩn và các bộ phận: Họ là nhà sản xuất máy bay , không phải nhà phát triển. Tôi không hoàn toàn chắc chắn, nhưng tôi đoán là rất nhiều phần được thuê ngoài. Họ không tự chế tạo thiết bị điện tử / dụng cụ, họ có chỗ ngồi từ một số công ty, động cơ có thể được phát triển ở nơi khác, v.v.

Mặt khác, các dự án phần mềm, hầu như luôn bắt đầu lại từ đầu chỉ với một số khung / trợ giúp nhỏ được đưa ra.

2- Thời gian tung ra thị trường: Thời gian không phải là vấn đề quan trọng đối với máy bay. Tôi cá rằng thiết kế của Airbus đã được hoàn thiện nhiều năm trước khi nó được hoàn thành và họ đã chọn bỏ qua bất kỳ bước đột phá lớn nào có thể xảy ra trong thời gian đó. (Tương tự đối với các nhà sản xuất ô tô, ví dụ, công nghệ tiên tiến mà họ phát triển tại thời điểm này sẽ xuất hiện trên đường phố sau 5-10 năm nữa.)

Đối với phần mềm, bạn cần phải rất nhanh nhẹn, nếu tôi bắt đầu một dự án lớn ngay bây giờ và mất ba năm để phát triển nó mà không có bất kỳ thay đổi nào thì khả năng khá cao là tôi đang dựa vào công nghệ không còn nữa hoặc sản phẩm của tôi đã hoàn toàn lỗi thời. Điều này lần lượt cung cấp rất nhiều vấn đề.

3- Chu kỳ phát hành và các phiên bản. - Một mặt phẳng cần phải được hoàn thành khi nó được "phát hành". Không có phiên bản beta ổn định, bản dựng hàng đêm hoặc tương tự. Ngoài ra, một khi nó được thực hiện, nó chỉ có thể được sửa đổi theo một cách nhỏ. Bạn không thể thêm một cấp độ bổ sung với 100 chỗ ngồi cho một chuyến đi hiện có, điều đó là không thể.

Mặt khác, phần mềm có những thay đổi gia tăng thường chỉ là "xây dựng hoạt động", nhưng không nhất thiết là thành phẩm. Ngoài ra, trong CNTT, không có gì lạ khi nói "này, hãy thêm một khoang hành lý khác vào máy bay của chúng tôi chứa thêm 50 tấn".

Tôi nghĩ rằng câu trả lời khá đơn giản:

1) Xây dựng và thực hiện vật lý đã có từ lâu như mọi người - chúng tôi đã có hàng ngàn năm để phát triển các phương pháp và kỹ thuật để thực hiện các dự án vật lý. Phần mềm 'xây dựng', đòi hỏi một bộ kỹ năng hoàn toàn mới và khác biệt, không quá 50 năm - chúng tôi chưa có đủ thời gian để tìm ra tất cả.

2) Xây dựng ảo khó hơn - bạn phải 'nhìn thấy' những thứ trong tâm trí mà không có thực tế vật lý nào. Nó đòi hỏi bạn phải phân tích và trừu tượng rất nhiều thông tin trước khi bạn biết sản phẩm của mình trông như thế nào và các bước cần thực hiện để tạo ra nó. Không phải như vậy khi xây dựng một cây cầu hoặc một tòa nhà.

3) Việc tìm ra nguồn gốc của lỗi phần mềm hoặc lỗi thường khó hơn nhiều so với khi làm kỹ thuật vật lý. Nếu một cái dầm khóa, bạn thấy nó bị vênh ở đâu và bạn thấy các hỗ trợ đang giữ nó và bị lỗi, v.v. Việc tìm ra một lỗi phần mềm có thể đòi hỏi phải kiểm tra rất nhiều mã và các quá trình tương tác - khó khăn, tốn thời gian và không bị ràng buộc với định luật vật lý và toán học theo cách cấu trúc vật lý.

Tôi sẽ thử trả lời bằng một bản sao nguyên văn của một bài báo từ nàng thơ nhúng của Jack Ganssle. Trong khi điều này nói firmware ở khắp mọi nơi, chỉ cần thay thế nó bằng phần mềm.

So với cái gì?

Phần sụn là thứ đắt nhất trong vũ trụ. Trong cuốn sách tuyệt vời "Luật của Augustine", Norman Augustine, cựu CEO của Lockheed Martin, kể một câu chuyện tiết lộ về một vấn đề mà cộng đồng quốc phòng gặp phải. Một máy bay chiến đấu hiệu suất cao là một sự cân bằng tinh tế của các nhu cầu xung đột: phạm vi nhiên liệu so với hiệu suất. Tốc độ so với trọng lượng. Có vẻ như vào cuối những năm 70, các máy bay chiến đấu đã nặng gần như họ từng có. Các nhà thầu, luôn theo đuổi lợi nhuận lớn hơn, đã tìm kiếm một cách vô ích cho những thứ họ có thể thêm vào đó có giá rất cao, nhưng không có gì nặng.

Câu trả lời: phần sụn. Chi phí vô hạn, khối lượng bằng không. Hệ thống điện tử hiện chiếm hơn một nửa chi phí của máy bay chiến đấu. Đó là một phần của sự thay đổi khi bạn xem xét máy bay chiến đấu mới nhất của Mỹ, F-22, có giá một phần ba tỷ đô la. Augustine thực tế vui đùa với niềm vui sướng khi anh kể câu chuyện này.

Nhưng tại sao phần mềm lại đắt như vậy? Tom DeMarco đã từng trả lời câu hỏi này bằng ba từ sau: so với cái gì? Anh ấy tiếp tục thảo luận về các trường hợp kinh doanh tương đối nhàm chán, nhưng câu trả lời đó đã vang dội trong tâm trí tôi trong nhiều năm. So với cái gì? Với phần mềm, chúng tôi thường xuyên tạo ra các hành vi sản phẩm phức tạp chưa từng thấy. Chắc chắn, mã đắt tiền. Nhưng chưa bao giờ trong lịch sử văn minh có ai xây dựng bất cứ thứ gì phức tạp đến thế.

Hãy xem xét các loại bong bóng sau đây, được nâng lên một cách đáng xấu hổ từ Wikipedia và không được kiểm tra độ chính xác:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Đó chỉ là 110 nhân vật ngoài không gian, có lẽ đã được tung ra trong một hoặc hai giờ. Giả sử chúng tôi không có phần mềm và phải thực hiện một loại sử dụng một số chiến lược khác. Nó sẽ có giá bao nhiêu?

Một kỹ sư cơ khí có thể tự hào rằng nghề nghiệp của mình chế tạo máy phân loại từ lâu trước máy tính. Hãy xem xét trình sắp xếp thẻ mô hình 82 thời đại 1949 của IBM ( http://www.columbia.edu/acis/history/sorter.html ) với thông lượng 650 thẻ mỗi phút, thay vì đoạn mã của chúng tôi có thể quản lý ngay cả trên 4 MHz Z80. Mô hình 82, tất nhiên, chỉ sắp xếp một cột của thẻ tại một thời điểm; để sắp xếp hoàn toàn một bộ bài có thể mất hàng chục đường chuyền.

Mất bao lâu để thiết kế và xây dựng con thú này? Năm, không còn nghi ngờ gì nữa. Và chức năng của nó mờ nhạt so với mã của chúng tôi nhanh hơn rất nhiều và có thể xử lý các bộ dữ liệu khổng lồ. Nhưng đó là năm 1949. Sẽ mất bao lâu để xây dựng một loại bong bóng từ các thành phần điện tử - không có đồ họa và VHDL, hay CPU?

Trong một giờ, tôi đã quản lý một sơ đồ khối thô, một sơ đồ ở trên mức chip (các khối có các tên như "bộ cộng", "chốt 16 bit" và tương tự). Nhưng logic trình tự rõ ràng là khá lộn xộn, vì vậy tôi mới đưa vào PLD, giả sử đến một lúc nào đó sẽ không quá khó để viết các phương trình thích hợp. Và, vâng, có lẽ phá vỡ quy tắc logic không lập trình được, nhưng để thiết kế và gỡ lỗi tất cả logic đó bằng cách sử dụng cổng trong bất kỳ khoảng thời gian hợp lý nào cũng khó xảy ra như khí buck-a-gallon.

Giả sử 16 từ và địa chỉ, mạch sẽ cần khoảng một chục chốt 16 bit, bộ cộng và những thứ tương tự. Bộ nhớ cộng. Và tôi không biết làm thế nào dữ liệu chưa được sắp xếp vào RAM hoặc làm thế nào kết quả được xuất. Đó là những yêu cầu thiết kế không xác định. Giải pháp chỉ dành cho phần mềm tự nhiên giải quyết các yêu cầu này chỉ bằng hành động viết nguyên mẫu hàm.

Dịch sơ đồ khối thô sang sơ đồ có thể mất một ngày. Sau đó, đã đến lúc thiết kế và sản xuất PCB, đặt hàng và tải các bộ phận (và thay đổi thiết kế để giải quyết các vấn đề cuối đời bất ngờ nhưng không thể tránh khỏi), và sau đó tất nhiên làm cho mạch hoạt động. Chúng tôi có thể nói nhiều tuần nỗ lực và rất nhiều tiền cho hội đồng quản trị, các bộ phận và thiết bị kiểm tra phù hợp.

Tất cả điều này để thay thế 7 dòng mã nhỏ. Rất ít chương trình nhúng thực sự ít hơn 10.000; nhiều hơn một triệu Bao nhiêu phần cứng và bao nhiêu kỹ thuật sẽ cần thiết để thay thế một chương trình máy tính siêu lớn thực sự?

Hãy xem xét một chương trình thực sự như một bảng tính. Cần bao nhiêu mạch để tạo ra một bộ không có bộ xử lý? Nó có thể là kích thước của một thành phố.

Phần sụn là thứ đắt nhất trong vũ trụ, nhưng chỉ vì sự phức tạp không thể tưởng tượng được của những vấn đề mà nó giải quyết. Nhưng nó rẻ hơn rất nhiều so với bất kỳ sự thay thế nào. Vì vậy, khi sếp của bạn cáu kỉnh hỏi tại sao phần mềm mất quá nhiều thời gian, bạn sẽ biết phải nói gì. So với cái gì?

Vì vậy, có! Phần mềm / phần sụn có độ phức tạp vô song.

Kỹ thuật và quản lý phần mềm khác về cơ bản so với nhiều lĩnh vực kỹ thuật khác. Các sản phẩm không thể cung cấp, và quy trình sản xuất là quy trình thiết kế và phát triển. Tạo một bản sao khác của một phần mềm về cơ bản có chi phí cận biên bằng không; tất cả các chi phí được tìm thấy trong việc phát triển bản sao đầu tiên.

Bởi vì tuổi trẻ tương đối của công nghệ và quản lý phần mềm là một ngành học, có một số thông tin sai lệch và sai lệch vẫn được coi là sự thật ( xem tài liệu tham khảo này ) gây cản trở cho toàn bộ sự phát triển và kỹ thuật phần mềm.

Không phải tất cả các nhà phát triển được tạo ra như nhau. Một số là tốt, những người khác là tốt, không.

Hãy thử đọc mã của người khác mọi lúc để cảm nhận những gì tôi đang nói. Quá nhiều báo cáo logic bổ sung có thể thêm rủi ro. Những rủi ro này có thể dẫn đến hành vi xấu hoặc lỗi. Không đủ câu lệnh logic và bây giờ bạn có tài liệu tham khảo null. Lập trình viên giỏi hiểu điều này và biết khi nào nên làm gì và ở đâu. Nhưng không ai là hoàn hảo. Mọi thứ rất phức tạp. Thêm công việc kém suy nghĩ của người khác và thật dễ dàng để thấy các dự án chạy trốn như thế nào.

Cathedrals từng mất tới 100 năm để xây dựng.

Một số máy bay Airbus cần 1 triệu dòng mã để hoạt động.

Bạn càng có nhiều thời gian để cải thiện một thứ gì đó, bạn càng nhận được nhiều cải tiến hơn, vì vậy hãy tạo cho ngành công nghiệp phần mềm một vài thế kỷ thử nghiệm để cải thiện và chúng ta sẽ thấy cần bao nhiêu để phát triển một dự án lớn vững chắc mà không gặp lỗi hoặc sai sót.

Các dự án lớn thường xảy ra trong các tổ chức lớn. Nếu bạn chưa từng làm việc trong một tổ chức lớn, có một thứ được đảm bảo để giết chết hiệu suất và năng suất: quan liêu.

Đáng ngạc nhiên, nhiều người không biết quan liêu là gì (nó thường bị nhầm lẫn với chính trị), hoặc thậm chí nếu / khi họ có vấn đề quan liêu.

Gần đây chúng tôi đã kết thúc một dự án để thực hiện xác thực thẻ thông minh. Nó ban đầu được ước tính là ba tháng. Mất 15 tháng. Không có bất kỳ chi phí, ngân sách, phạm vi hoặc lý do kỹ thuật cho sự chậm trễ. Phạm vi thực sự khá hẹp - chỉ dành cho các tài khoản có đặc quyền nâng cao (tài khoản quản trị viên), khoảng 1.200 tổng tài khoản.

Một yếu tố quan trọng khác là các đối tác kinh doanh của bạn. Điều này sẽ bao gồm các nhà cung cấp. Nếu các đối tác của bạn có vấn đề gây ra sự chậm trễ trong dự án của bạn, sẽ không có nhiều tùy chọn thực sự sẽ khắc phục vấn đề trì hoãn. Họ không làm việc trực tiếp cho bạn và bạn có thể không sa thải người đó vào đối tác có thể là nguyên nhân. Đối tác có thể bị sa thải, hoặc có thể bị phạt tài chính hoặc không đồng ý, nhưng điều đó không thay đổi thực tế rằng dự án đã phát sinh sự chậm trễ. Đây chính xác là những gì đã xảy ra với Boeing khi họ thực hiện chiến lược tìm nguồn cung ứng voi ma mút với Boeing 787 Dreamliner .

Tôi có một phiên bản ngắn hơn cho bạn:

Bất cứ điều gì dễ làm, hoặc sắp xếp hợp lý, chúng tôi viết một chương trình để làm điều đó thay vì chúng tôi.

Và sau đó chiến đấu với quá trình meta thay thế.

Điều đó không đúng lắm, mỗi ngày, nhưng mỗi ngày có hàng ngàn blog được thiết lập, thay vì viết các công cụ blog. Mỗi ngày làm việc, hàng ngàn macro Excel được viết, thay vì viết các ứng dụng cơ sở dữ liệu được thiết kế đặc biệt cho các ứng dụng này.

Có rất nhiều yếu tố khác - một số trong số chúng được đề cập ở đây - nhưng tôi muốn thêm điểm này vào cuộc thảo luận.

Thiếu trách nhiệm ... Mọi người bị kiện khi máy bay gặp sự cố. Công nghiệp phần mềm từ chối mọi trách nhiệm trong bất kỳ lỗi phần mềm nào, do đó tạo ra sự thiếu động lực để tạo ra một sản phẩm mạnh mẽ và an toàn.

Hầu hết các dự án lớn có mức độ phân tách cao của các dự án con, nơi bạn có thể xác định một số lượng nhỏ các ràng buộc thiết kế; toàn bộ dự án sẽ hoạt động khi mỗi dự án con được hoàn thành. Nếu có sự cố xảy ra trong một dự án phụ, toàn bộ nỗ lực không bị ném vào câu hỏi; bạn chỉ cần tìm cách thay thế để hoàn thành dự án phụ (ví dụ: sử dụng một công cụ khác).

Điều này là có thể nhưng khó khăn, cả thực tế và như một vấn đề thuộc về bản chất con người, trong các dự án phần mềm.

Một phần, các ngành công nghiệp khác đã học được một cách khó khăn rằng loại phân tách này là một điều tốt. Ví dụ: nếu bạn sẽ sử dụng động cơ máy bay Rolls Royce, bạn không cần sử dụng bu lông Rolls Royce đặc biệt và các điểm đính kèm chỉ hoạt động với cánh có thiết kế cụ thể, sau đó nếu bạn cố gắng chuyển sang Pratt và Whitney, bạn phải thiết kế lại toàn bộ cánh của mình từ dưới lên (do đó, đòi hỏi phải thiết kế lại hoàn toàn thân máy bay, do đó yêu cầu bạn phải mua các ghế khác nhau, do đó yêu cầu bạn phải mua một hệ thống giải trí trên chuyến bay khác, mà ...). Có thể có một vài mối liên kết - bạn không thể trao đổi động cơ mà không cần quan tâm - nhưng các dự án lớn thường hoạt động tốt hơn khi những thứ đó được giảm thiểu.

Tôi cho rằng các dự án phần mềm lớn được thiết kế như một cụm các dự án phần mềm nhỏ với giao diện sạch sẽ không bị thất bại thường xuyên, miễn là dự án lớn thực sự được giải quyết bằng cụm các dự án nhỏ. (Có thể phạm sai lầm về vấn đề này.)

Xây dựng hệ thống phần mềm rất khác với xây dựng cấu trúc vật lý. Đó là, việc thực hiện là rất nhiều khác nhau. Trong khi ví dụ xây dựng một tàu chở dầu khổng lồ, bạn thực hiện rất nhiều nhiệm vụ tương đối đơn giản (không dễ!), Chẳng hạn như hàn các bộ phận với nhau bằng robot hoặc bằng tay, siết chặt tất cả các đai ốc và bu lông, vẽ tranh, trang trí bằng cách mang theo tất cả các thiết bị và đồ nội thất và như vậy. Tất cả điều này là những thứ rất đơn giản để làm, thực sự.

Tuy nhiên, khi nói đến phần mềm, nó phức tạp hơn nhiều . Ví dụ: làm thế nào chính xác để bạn thực hiện phần lưu trữ thông tin đăng nhập và thông tin người dùng an toàn của sản phẩm? Những thư viện và công cụ nào bạn có thể sử dụng? Với những thư viện và công cụ nào bạn quen thuộc? Làm thế nào chính xác để bạn đi về việc viết hàm băm + muối và làm thế nào để bạn đảm bảo nó an toàn? Bạn có thể làm điều này theo nhiều cách mà không thể đặt bất kỳ mẫu thiết kế thực tế thực tế nào cho những thứ này. Vâng, các mẫu thiết kế nói gì tồn tại trên một quy mô nhỏ hơn là "thực hành tốt nhất", nhưng mỗi hệ thống phần mềm duy nhất là rất khác nhau từ những người khác, và những tiến bộ hiện trường và thay đổi theo tốc độ quá nhanh đến nỗi nó về cơ bản không thể theo kịp.

Khi xây dựng một ngôi nhà, bạn không thực sự gặp phải những vấn đề như vậy khi bạn nhận ra rằng các bức tường hỗ trợ chính dường như không đủ và cần phải thay thế, đòi hỏi bạn phải phá hủy tiến độ cho đến nay và bắt đầu từ căn cứ bằng cách làm lại các bức tường hỗ trợ . Bạn giải quyết các vấn đề như vậy ở giai đoạn thiết kế , bởi vì việc dự đoán loại tường hỗ trợ mà tòa nhà của bạn cần là tương đối đơn giản.

Đó không phải là trường hợp với phần mềm mặc dù. Bạn thực sự không thể thiết kế toàn bộ sản phẩm như một thực thể duy nhất và sau đó triển khai nó. Quá trình thiết kế phần mềm thường lặp đi lặp lại, và các mục tiêu và yêu cầu thay đổi khi sản phẩm đang được thực hiện và thử nghiệm. Phát triển phần mềm nói chung là một quá trình lặp đi lặp lại trong đó mọi thứ thường thay đổi khi ít được mong đợi nhất và nhiều lần thay đổi như vậy đặt ra những thách thức đòi hỏi nhiều công việc hơn, phức tạp hơn và không may là cuối cùng phải tốn nhiều tiền, thời gian và công sức hơn.

Vì vậy, về bản chất, lý do tại sao khó có thể cung cấp các dự án lớn và ước tính thời gian và lộ trình dự án là vì phát triển phần mềm và đặc biệt là thiết kế làm việc là những lĩnh vực rất phức tạp . Sự phức tạp là vấn đề gốc rễ.

Định nghĩa của "dự án lớn" bị sai lệch.

Một dự án lớn, về mặt kỹ thuật, có thể được giao đúng hạn và hoàn hảo, với điều kiện đó là thứ được xây dựng nhiều lần trong nhiều năm.

• Một bản sao Pac-Man.
• Một máy tính
• Một trình soạn thảo văn bản

Tôi chắc rằng bạn đang nghĩ ... "nhưng đó là những dự án nhỏ ! Một trình soạn thảo văn bản rất đơn giản ." Tôi sẽ không đồng ý với bạn. Máy tính rất phức tạp. Đôi khi chỉ cần cài đặt và thiết lập người dùng trên một hệ điều hành và bạn thậm chí không viết được HĐH hoặc xây dựng phần cứng.

Các dự án bạn đang nói đến là những dự án lớn , giống như khám phá không gian. Làm thế nào để bạn biết phải mất bao lâu để phát triển du lịch giữa các thiên hà? Chúng ta dựa trên mô hình nào? Bạn có những điều đã biết, những điều đã biết, những điều chưa biết, và cuối cùng, những điều chưa biết chưa biết, xảy ra rất nhiều trong việc phát triển phần mềm.

Tôi nghĩ rằng vấn đề là một trong những kỳ vọng. Chỉ vì công nghệ không có nghĩa là sử dụng nó sẽ thành công (hoặc khôn ngoan khi sử dụng) trong một thời gian. Nếu các ngành công nghiệp khác hoạt động như các ngành công nghiệp phần mềm đã làm, chúng ta sẽ có máy hút bụi chạy bằng lỗ đen để bán vào cuối thập kỷ này. Hoặc một số "người có tầm nhìn" sẽ có đủ nguồn lực để xây dựng căn cứ mặt trăng và quyết định rằng Starbucks sẽ thực sự "làm tròn" trải nghiệm cho du khách. Tôi không nghĩ vấn đề là ngành công nghiệp phần mềm, nhưng kỳ vọng đặt vào nó.

Mặc dù đó hầu như không phải là điều duy nhất có thể được đề cập, tôi nghĩ một điều cơ bản là đáng để chỉ ra. Hầu hết các sản phẩm được dự định để phù hợp với hành vi hiện có. Ngay cả một sản phẩm là một bước đột phá triệt để (ví dụ, xe hơi) thường được chế tạo để phù hợp với hành vi hiện có, và chỉ cần làm cho nó đơn giản hơn / dễ dàng hơn / rẻ hơn / bất cứ điều gì để làm điều đó. Có, thường có một số tác dụng phụ đối với hành vi hiện có (ví dụ, lấy nhiên liệu cho xe thay vì thức ăn cho ngựa), nhưng hầu hết các trường hợp sau có xu hướng là tác dụng phụ khá nhỏ.

Ngược lại, hầu như bất kỳ phần mềm nào không thay đổi hành vi của người dùng (ví dụ: để họ thực hiện công việc của họ dễ dàng hơn đáng kể) về cơ bản được đảm bảo là một thất bại hoàn toàn kể từ ngày 1. Tệ hơn, các dự án phần mềm lớn không chỉ liên quan đến hành vi của người dùng ở cấp độ cá nhân, nhưng hành vi của các nhóm lớn - thường là toàn bộ tổ chức.

Nói tóm lại, tự thiết kế phần mềm thường là phần dễ nhất trong công việc. Phần khó là thiết kế lại công việc của mọi người cho họ. Điều đó thật khó để bắt đầu; thực hiện nó theo cách không chỉ có hiệu quả mà còn được chấp nhận còn khó khăn hơn nhiều.

Airbus A380 không phải là một dự án thành công như bạn đã đề cập. Tôi tình cờ làm việc trong một công ty CAD / CAM và tôi được thông báo rằng nó (chúng tôi cũng có dự đoán Airbus) đã bị trì hoãn vài năm, bởi vì họ đang sử dụng phiên bản phần mềm khác nhau trong các công ty khác nhau. Đó là, các phần khác nhau đã được thiết kế ở các phần khác nhau của thế giới. Và trong khi tích hợp, họ biết rằng tất cả các thiết kế không được tích hợp, vì vậy họ phải thiết kế lại nó trong một phiên bản. Vì vậy, nhìn vào nó tôi không nghĩ rằng nó đã thành công. Nếu nó đến 2-3 năm trước, nó sẽ là người thay đổi cuộc chơi cho Airbus.

Cũng liên quan đến phần mềm mạnh mẽ, bạn nhìn vào bất kỳ máy bay, ô tô nào (ABS, EPS, kiểm soát khí hậu, v.v.) hoặc tàu con thoi họ có hơn 50% phần mềm đang chạy chúng và tin tôi rằng chúng rất mạnh mẽ. Chỉ là chúng ta gần gũi hơn với phần mềm và có nhiều chương trình phần mềm hơn, vì vậy chúng ta thấy nhiều lỗi hơn trong đó.

Truy cập: http://www.globalprojectstrargety.com/lessons/case.php?id=23 và xem Airbus A380 đã thành công như thế nào.

Kỹ sư phần mềm ở đây, với một nền tảng kỹ thuật, và một người vợ làm việc trong ngành xây dựng. Chúng tôi đã có những cuộc thảo luận dài (và tranh luận) về sự khác biệt trong công việc của chúng tôi.

Kỹ thuật phần mềm là về thiết kế những thứ mới . Hầu hết mọi thứ cơ bản đã được thực hiện trong một thư viện nguồn mở ở đâu đó. Trong hầu hết mọi công việc mà một kỹ sư phần mềm được thuê, cô ấy phải thiết kế một cái gì đó không tồn tại.

Trong một cái gì đó như xây dựng và hầu hết các hình thức kỹ thuật, những thứ khác có trong 'thư viện' trong phần mềm đã được thiết kế đầy đủ. Bạn muốn xây dựng một tòa tháp? Chỉ cần sao chép và dán các kế hoạch từ một cấu trúc hiện có, với một vài sửa đổi.

Trên thực tế, một trong những lý do chính khiến tôi quyết định không trở thành kỹ sư là bạn dành phần lớn thời gian để thiết kế cải tiến 10% cho một phát minh hiện có, khi đó có thể được sử dụng để lập trình một thứ gì đó rõ ràng hơn, như mạng xã hội .

Không có nhiều thiết kế mới trong kỹ thuật; một kỹ sư cực kỳ lành nghề là người có thể điều khiển một thiết kế hiện có thành một cái gì đó mới hoặc cải tiến nó. Nhưng hầu như mọi lập trình viên đều mong muốn sửa đổi thiết kế, hack chúng hoặc tạo ra một cái gì đó mới.

Nhìn lại xem các tiêu chuẩn đã thay đổi hoàn toàn như thế nào, từ lắp ráp thành C sang C ++ sang Java, JavaScript, C #, PHP, v.v. Không có nhiều mã có thể được tái chế từ 10 hoặc 20 năm trước. Điều này rất khác khi nói ... ngành công nghiệp ô tô hoặc hàng không khi bạn có thể tiếp tục cải tiến các thiết kế từ nhiều thập kỷ trước.

Quản lý dự án nổi tiếng là khó khăn trong phần mềm . Ước tính thời gian được thực hiện tốt nhất bởi những người thực hiện công việc , nhưng khi họ bận rộn thực hiện ước tính, họ không viết mã . Điều này cám dỗ mọi người để tránh bất kỳ quản lý dự án nào cả.

Thông thường, rất nhiều mã phụ thuộc vào những người cụ thể và nếu những người này trễ hoặc không thể thực hiện, mã sẽ không đi trước. Ngược lại, nếu bạn muốn chế tạo một chiếc xe hơi, bạn chỉ cần thuê những người khác nhau để lắp ráp lốp xe, khung xe, pin, động cơ, v.v. Các khung công tác hướng đối tượng và hiện có làm cho điều này trở nên khả thi, nhưng nó có thể không thực tế khi bạn thiết kế mọi thứ từ đầu.

Thất bại có thể được cho phép trong phần mềm . Kiểm tra có thể tốn kém. Trong phần mềm, sẽ rất hấp dẫn khi bỏ qua tất cả các thử nghiệm đó, khi bạn chỉ có thể khắc phục sự cố. Trong hầu hết các hình thức kỹ thuật, một 'vụ tai nạn' có thể gây tử vong.

Bạn có các phương pháp lập trình sử dụng thử nghiệm rộng rãi, như lập trình cực đoan (thực sự được sử dụng trên các cụm từ phần mềm). Nhưng với thời hạn chặt chẽ (có thể được thực hiện chặt chẽ hơn về mục đích), thật tuyệt vời khi bỏ qua tất cả các chương trình và khởi chạy với lỗi. Các Joel Spolsky phong cách "luôn luôn sửa chữa tất cả các lỗi" sẽ tiết kiệm được nhiều thời gian hơn trong dài hạn, nhưng vô kỷ luật sẽ bỏ qua điều này và thất bại.

Dự án nhỏ là tốt hơn . Vợ tôi từng yêu cầu tôi có được một công việc trong một công ty lớn. Kết cục là một cuộc tranh luận rằng các công ty lớn là những công ty tồi ... với cô, một công ty lớn có rất nhiều nguồn lực, kinh nghiệm, quản lý dự án chức năng và các quy trình đúng đắn. Đối với tôi, một công ty lớn là một con khủng long, nơi phần lớn thời gian của bạn dành cho việc sửa mã, kiểm tra nó và tài liệu.

Tôi đã thấy các dự án CNTT trị giá hàng triệu đô la hoạt động trên dưới 10 người. Nhiều người sẽ làm chậm dự án và thêm quan liêu không cần thiết. WhatsApp là một ví dụ về một dự án 'nhỏ' trị giá hàng tỷ đô la. Không phải là các dự án lớn không thể thực hiện được, nhưng đơn giản là bạn không cần hàng ngàn người để sản xuất phần mềm trị giá hàng tỷ đô la.

Một lý do chưa thực sự được đề cập trong các câu hỏi khác là lĩnh vực phần mềm đổi mới với tốc độ hiếm khi xảy ra trong thế giới dựa trên vật liệu.

Một lý do cho điều này là sự phát triển phần mềm là một chu kỳ phản hồi tích cực vì phần mềm (ngôn ngữ lập trình, công cụ xây dựng, IDE) được sử dụng để xây dựng phần mềm. Đó là ví dụ rõ ràng nhất cho luật tăng tốc lợi nhuận của Ray Kurzweil , dẫn đến tiến bộ với tốc độ tăng theo cấp số nhân. Khi bạn đã thành thạo một khung công tác, ngôn ngữ lập trình, giao thức giao tiếp, đây là lúc để chuyển sang khung tiếp theo.

Nếu máy bay được chế tạo giống như phần mềm, chúng tôi sẽ thay đổi vật liệu với mọi mô hình khác, tăng gấp đôi công suất và tốc độ sau mỗi 18 tháng, thay thế công nghệ động cơ cho từng mô hình mới bằng thứ gì đó vừa được phát minh, đồng thời thêm khả năng bơi và tìm kiếm ngoài trái đất đời sống.

Ồ, và lý tưởng là nó nghe lệnh bằng giọng nói và tăng gấp đôi như một rạp chiếu phim đầy đắm chìm, đấu trường paintball và câu lạc bộ đêm với phòng tối khi chuyến đi công tác của bạn kết thúc. Giống nhau cả thôi! (Công ty chế tạo máy bay vừa đưa bạn từ A đến B trở nên đáng tin cậy sau một năm kể từ khi công ty có rạp chiếu phim, paintball và hộp đêm xuất hiện.)

Đối với tôi, vấn đề chính mà kỹ thuật phần mềm phải đối mặt là trường hợp sử dụng, người dùng và nền tảng chéo.

Trường hợp sử dụng

Máy bay có bao nhiêu trường hợp sử dụng? Hầu hết chỉ là bay từ nơi này sang nơi khác. Có thể có nhiều hơn như radar, điều khiển giao thông, v.v., nhưng trường hợp sử dụng rõ ràng và không nhiều. Trong công nghệ phần mềm, chúng tôi phải đối mặt với những yêu cầu không rõ ràng và người dùng không biết họ muốn gì. Người dùng khác nhau cần cấu hình / lưu lượng khác nhau, máy bay có thể được tùy chỉnh theo ý muốn của người dùng không (tôi muốn có tivi và tủ lạnh!)?

Người dùng

Ai điều khiển máy bay? Một phi công, một phi công phụ, một số tiếp viên (nếu được tính) và những người điều hành tháp. Họ đều là ưu và có mô tả công việc rõ ràng. Phần mềm được sử dụng bởi noobs và dummies, chưa kể các tin tặc và cracker độc ác, trong khi vẫn cần phải được tích hợp với các mô-đun khác (như OpenID hoặc Google AdSense ). Nếu một chiếc máy bay có thể được vận hành bởi người giả trong khi vẫn sống sót sau tên lửa hoặc tên cướp ninja, thì bạn có thể nói rằng chiếc máy bay này có cùng chất lượng với phần mềm.

Nền tảng chéo

Một chiếc máy bay chỉ bay trên bầu trời trái đất. Tôi không chắc về cách họ xử lý khí hậu sương mù hay gió hoặc nóng, lạnh và ẩm, nhưng một chiếc máy bay không được thiết kế để bay ở các mức độ hấp dẫn khác nhau (tôi sẽ ngạc nhiên nếu nó có thể bay lên sao Hỏa ). Đôi khi, một ứng dụng phải tồn tại các nền tảng khác nhau, chẳng hạn như Internet Explorer, Google Chrome , Firefox và Safari cho trình duyệt (xin lỗi Opera ) hoặc Windows XP / 7/8 hoặc Linux cho cấp độ hệ điều hành. Chưa kể các thiết bị di động và độ phân giải và định hướng khác nhau.

Nếu bạn nghĩ rằng các ngành công nghiệp khác hoàn thành các dự án mà không có sự cố, bạn nên đọc câu chuyện về tòa nhà Trung tâm Citigroup được xây dựng vào năm 1977. Ngay cả sau gần 7 năm lập kế hoạch và xây dựng, tòa nhà đã được hoàn thành với một lỗ hổng thiết kế nghiêm trọng có thể gây ra sự sụp đổ từ một sự kiện bão dự kiến ​​cứ sau 16 năm.

Nói cách khác, cứ mỗi năm Trung tâm Citicorp đang đứng, có khoảng 1 trong 16 khả năng nó sẽ sụp đổ.

Các nhà thiết kế ban đầu không biết về các vấn đề, nhưng may mắn là nó đã bị bắt bởi một sinh viên đang nghiên cứu tòa nhà.

Mọi thứ dường như vẫn ổn cho đến khi LeMessurier nói, anh nhận được một cuộc điện thoại. Theo LeMessurier, vào năm 1978, một sinh viên kiến ​​trúc đại học đã liên lạc với anh ta với một tuyên bố táo bạo về tòa nhà của LeMessurier: rằng Trung tâm Citicorp có thể bị gió thổi bay.

Việc sửa chữa được thực hiện theo nghĩa đen trong màn đêm liên quan đến số lượng người ít nhất để duy trì sự bí mật của lỗ hổng thiết kế.

Một kế hoạch sơ tán khẩn cấp đã được chuẩn bị cho bán kính 10 khối bao quanh tòa nhà.

Họ hàn suốt đêm và nghỉ việc vào ban ngày, giống như những người ở trong tòa nhà trở lại làm việc.

Câu chuyện vẫn là một bí mật cho đến khi nhà văn Joe Morgenstern tình cờ nghe được nó được kể trong một bữa tiệc, và phỏng vấn LeMessurier. Morgenstern đã phá vỡ câu chuyện trong The New Yorker năm 1995.

Điều này đặt ra câu hỏi; có bao nhiêu lỗi thiết kế chết người khác trong các dự án đã được bí mật sửa chữa hoặc bỏ qua mà không có sự thừa nhận của công chúng.

• Lỗ hổng thiết kế gần như đã xóa sổ một tòa nhà chọc trời NYC (slate.com)
• Trung tâm Citigroup (wikipedia.com)