Có biết sử dụng hợp lệ SLOC để đo năng suất?

Tôi đã có một cuộc trò chuyện ngắn, bất thường với một kiến ​​trúc sư rất cao cấp về các ngôn ngữ động và tĩnh. Ông nói rằng dữ liệu của công ty cho thấy có bằng chứng cho năng suất cao hơn khi sử dụng ngôn ngữ tĩnh. Lưu ý, đó là một công ty lớn có lịch sử lâu dài. Trước sự ngạc nhiên của tôi (và những người khác), số liệu anh ta sử dụng là các dòng mã được thêm vào.

Ông nhanh chóng bác bỏ những phản đối liên quan đến số liệu nói rằng trong cùng một công ty, với văn hóa, ngành nghề kinh doanh tương tự và với đủ dữ liệu, sự khác biệt (đối với các tình huống và khả năng duy nhất của các cá nhân) hòa trộn đủ để số liệu SLOC hữu ích để so sánh năng suất của công cụ và ngôn ngữ.

Mặc dù tôi không nghĩ rằng tuyên bố này được hỗ trợ bởi phân tích thống kê nghiêm ngặt, nhưng có một số bằng chứng trong ngành sẽ hỗ trợ cho lối suy nghĩ này?

Lập luận của kiến ​​trúc sư cao cấp có thể có nghĩa là hai điều.

1. Nó có thể có nghĩa là một nhà phát triển trung bình trong công ty tạo ra nhiều dòng mã hơn khi sử dụng ngôn ngữ tĩnh so với khi sử dụng ngôn ngữ động. Chẳng hạn, nếu mười lăm nhà phát triển làm việc với Java trong sáu tháng, họ sẽ viết 100 KLOC và nếu mười lăm nhà phát triển đó làm việc với Python trong sáu tháng, họ sẽ chỉ viết 50 KLOC.

   Không có mối tương quan giữa LỘC và năng suất ở đây. Điều gì xảy ra nếu Java phải mất gấp bốn lần dòng mã trong Java để tạo ra tính năng tương tự như trong Python? Nếu đó là sự thật, sử dụng Python sẽ mang lại năng suất gấp đôi, dựa trên các số liệu của KLOC ở trên.

2. Ông cũng có thể có nghĩa là một nhà phát triển trung bình trong công ty tạo ra ít dòng mã hơn khi sử dụng ngôn ngữ tĩnh so với khi sử dụng ngôn ngữ động: mười lăm nhà phát triển sẽ viết trong sáu tháng 100 KLOC bằng Java hoặc 200 KLOC bằng Python.

   Mặc dù ít dòng mã thường tốt hơn (ít mã hơn để viết, để đọc và duy trì), nhưng vẫn chưa rõ các nhà phát triển Java đã tạo ra bao nhiêu tính năng so với Python. Có lẽ họ đã viết một nửa dòng mã so với các nhà phát triển Python, nhưng cũng tạo ra một nửa số tính năng?

Trong cả hai trường hợp, LOC không phải là một số liệu có giá trị, bởi vì cùng một tính năng sẽ không dịch trong cùng một dòng mã trong các ngôn ngữ khác nhau . Một số ngôn ngữ có xu hướng dài dòng hơn; Những người khác gọn gàng hơn. Trong khi trong một số trường hợp, sự nhỏ gọn là có giá trị, không có quy tắc chung cho điều đó. Một ví dụ cực đoan sẽ là ngôn ngữ Brainfuck có độ gọn nhẹ cực cao, nhưng không phổ biến vì khả năng đọc của nó. So sánh các ngôn ngữ tương tự thậm chí có thể khó khăn: ví dụ, khi nói đến dấu ngoặc nhọn, Java theo kiểu K & R, trong khi ở C #, dấu ngoặc nhọn mở trong dòng của nó trong hầu hết các trường hợp khi theo kiểu chính thức, dẫn đến kiểu nhân tạo tăng LỘC cho C #. Và điều gì xảy ra khi người ta so sánh một ngôn ngữ thủ tục với một ngôn ngữ hướng đối tượng, hoặc với một ngôn ngữ chức năng?

Thay vì sử dụng số liệu dễ bị lỗi, kiến ​​trúc sư cao cấp có thể dựa vào một nhóm số liệu đo lường năng suất khi được sử dụng cùng nhau: số lượng tính năng được phát triển mỗi tháng, số lỗi được giới thiệu trong cơ sở mã và thời gian giải quyết các lỗi đó , sự phát triển của nợ kỹ thuật, v.v ... Sự so sánh này có thể khó khăn ngay từ đầu, vì người ta phải tính đến sự không quen thuộc của đội với ngôn ngữ mới. Khi nhóm đã đủ quen thuộc với nó, sự lựa chọn nên dựa trên các số liệu ổn định, cũng như phần lớn dựa trên sở thích của chính các thành viên trong nhóm.

LỘC có một giá trị trong một số tình huống hẹp. Ví dụ, nó có thể đưa ra gợi ý về kích thước của dự án và các phần của dự án (và trung bình tương quan với các điểm chức năng, trong khi thường dễ đo hơn), hoặc nó có thể chỉ ra các phương thức và các lớp có thể cần chú ý hơn bởi vì kích thước lớn của chúng. Tuy nhiên, LỘC nên được sử dụng cẩn thận, vì nó bị lạm dụng quá thường xuyên bởi những người tưởng tượng ra một số mối tương quan giữa những thứ không liên quan. Việc sử dụng các LỘC thảm khốc nhất của con người là trong quá khứ cố gắng đo lường năng suất của một nhà phát triển cá nhân dựa trên các LỘC được viết mỗi tháng.

Về năng suất và SLOC

Vấn đề với SLOC

Vấn đề với số liệu SLOC là nó đo gần đúng số lượng mã được viết mà không tính đến:

• chất lượng của mã (nghĩa là nếu cứ 100 SLOC thì bạn phải thêm 90 SLOC khác vì lỗi, nhưng bạn không biết tại thời điểm mã của mình được gửi?)
• các mục tiêu đạt được với mã (tức là SLOC 10K có xử lý tất cả các trường hợp sử dụng dự kiến ​​hoặc câu chuyện người dùng không? hoặc chỉ một tập hợp nhỏ?)
• khả năng duy trì của mã (tức là bạn sẽ phải thêm 1% hoặc 50% mã nữa để điều chỉnh mã theo các yêu cầu phát triển dự kiến?).

Nói cách khác, việc sản xuất mã spaghetti dễ bị lỗi không thể nhầm lẫn với nhiều phần được sao chép sẽ được coi là hiệu quả hơn so với mã tái sử dụng được thiết kế cẩn thận.

Vì vậy, SLOC chắc chắn không phải là cách tốt nhất để đo năng suất.

Năng suất nào chúng ta đang xem xét?

Năng suất được đo lường cho một quá trình. Vì vậy, SLOC có thể là một chỉ số hoàn toàn hợp lệ cho riêng quá trình mã hóa.

Ví dụ, nếu bạn hiểu sai các yêu cầu kém, dành năm tháng để sản xuất phần mềm, hiển thị cho người dùng, phát hiện ra rằng nó hoàn toàn sai và mất thêm 5 tháng để viết lại cho tốt từ đầu, bạn sẽ có năng suất tương tự trong SLOC / tháng, ví dụ, một nhóm viết mã ngay lần đầu tiên, chẳng hạn vì họ đã sử dụng một quy trình nhanh để giảm hiểu lầm thông qua phản hồi thường xuyên. Năng suất tương đương rõ ràng này ẩn giấu những vấn đề lớn.

Vì vậy, đo lường năng suất phát triển phần mềm cần phải tính đến toàn bộ quá trình, bao gồm phân tích các yêu cầu, thiết kế mã gì, mã hóa, kiểm tra, gỡ lỗi và xác minh rằng đáp ứng mong đợi của người dùng. Vì tất cả các hoạt động này rất khác nhau, điều tốt nhất là đo lường suy nghĩ duy nhất quan trọng: phần mềm làm việc, tức là phần mềm được sản xuất có ý nghĩa gì với người dùng .

Làm thế nào để đo lường phần mềm giao hàng?

Một số cách tiếp cận tồn tại:

• Cách tiếp cận điển hình trong công nghệ phần mềm cổ điển là Function Points (FP). Các điểm chức năng được đo lường dựa trên các yêu cầu cần thực hiện (ví dụ: số lượng biểu mẫu, số lượng trường trong mỗi biểu mẫu, v.v ...). Năng suất sau đó được đo bằng FP trên mỗi đơn vị thời gian và mỗi người. Một số công ty thậm chí có dữ liệu cho biết có bao nhiêu điểm chức năng mà nhà phát triển có thể tạo ra trên mỗi đơn vị thời gian trong một ngôn ngữ nhất định cho một miền nhất định. Vấn đề với FP là nó đòi hỏi các yêu cầu rất chi tiết trả trước và nó tốn thời gian.
• Một cách tiếp cận hiện đại và thực dụng hơn là điểm câu chuyện (SP). Chúng được sử dụng để đánh giá độ phức tạp của mã được tạo ra và được sử dụng thường xuyên để đánh giá vận tốc của các nhóm phát triển. Tuy nhiên, SP là thước đo ước tính cho công việc được thực hiện trước khi biết tất cả các chi tiết. Đây không phải là thước đo cuối cùng cho những gì thực sự đã xảy ra. Vì vậy, một số lưu ý phải được thực hiện khi sử dụng nó như một thước đo năng suất vì nó có thể phản tác dụng trong quá trình ước tính .

Về năng suất của kiểu gõ tĩnh so với động

Tôi phải thú nhận rằng cá nhân tôi là một fan hâm mộ của các ngôn ngữ được gõ tĩnh, bởi vì trong nội tâm của tôi, tôi biết rằng nó đáng tin cậy hơn (nhiều năm mã hóa đã chứng minh cho tôi điều đó).

Vì vậy, một điều mà tôi chắc chắn là ngôn ngữ gõ tĩnh có thể ngăn ngừa nhiều lỗi / lỗi hơn trong thời gian biên dịch (ví dụ: lỗi chính tả, không khớp trong các loại dự kiến, v.v ...) so với các ngôn ngữ không được gõ tĩnh. Nhưng trong tất cả các khách quan, tôi sẽ không dám khái quát hóa điều này như một năng suất cao hơn.

Là kiến ​​trúc sư của bạn phải không?

Co le không.

Nhưng các đối số của ông dường như không hợp lệ: mức tăng năng suất của ngôn ngữ gõ tĩnh xuất phát từ một số lỗi đáng kể được trình biên dịch bắt trước.

Do đó, không thể tìm ra mức tăng năng suất "cao hơn" này bằng cách chỉ nhìn vào SLOC mà không cần nhìn vào công việc cần thiết cho các ngôn ngữ được gõ động. Vì vậy, so sánh của anh ta không thể công bằng.

Đối số của hoàn cảnh so sánh cũng không giữ được. Một số ngôn ngữ được gõ động cho phép một số cấu trúc cấp cao hơn yêu cầu ít mã hơn so với thực hiện cùng một trong các ngôn ngữ được nhập tĩnh cổ điển. Vì vậy, bạn có thể cần ít thời gian hơn, viết ít mã hơn, nhưng thêm chi phí phân tích, kiểm tra và xác minh tương tự. Vì vậy, đo lường năng suất bằng SLOC sẽ làm loãng năng suất tăng năng suất, do đó tạo ra sự thiên vị đối với ngôn ngữ được gõ động.

Bất kỳ nghiên cứu để hỗ trợ yêu cầu đó?

Một số nghiên cứu học thuật gần đây tồn tại về chủ đề này. Mặc dù một số người trong số họ nhìn thấy một lợi thế của việc gõ tĩnh, nhưng nói chung, nó bị giới hạn trong một mục đích cụ thể (tài liệu, sử dụng lại mã hoặc tài liệu kém, v.v.). Từ ngữ thận trọng cũng được sử dụng vì IDE hiện đại đã giảm đáng kể các rủi ro liên quan đến gõ động:

• Một so sánh thực nghiệm về các hệ thống loại tĩnh và động về việc sử dụng API với sự có mặt của IDE: Java so với Groovy với nhật thực , 2014
• Xem xét hiệu quả năng suất của Tuyên bố loại rõ ràng , 2014, nhưng không kết luận
• Một nghiên cứu thực nghiệm về ảnh hưởng của các hệ thống loại tĩnh đối với khả năng sử dụng của phần mềm không có giấy tờ

Đây là một ví dụ cho kiến ​​trúc sư cao cấp của bạn: Giả sử tôi muốn viết một hệ thống phân cấp gồm ba lớp, hai trong số đó xuất phát từ lớp thứ ba, thực hiện một số hàm ảo mà lớp cơ sở định nghĩa.

Nếu tôi viết ba lớp này trong C ++, điều đó khá dễ dàng. Tôi khai báo các lớp, sử dụng ảo ở đúng nơi và được thực hiện.

Nếu tôi viết ba lớp này bằng C, tôi sẽ cần thêm khá nhiều mã: Tôi cần xác định structs cho các bảng v, tôi cần thêm một con trỏ bảng v vào lớp cơ sở, tôi cần thêm mã cho các hàm tạo để thực sự thiết lập các con trỏ bảng v, tôi cần thêm mã các hàm tạo để thực sự gọi hàm tạo của lớp cơ sở, tôi cần thêm mã để thực hiện cấp phát bộ nhớ một cách rõ ràng trước khi gọi một hàm tạo (mà C ++ newthực hiện trong một bước duy nhất ), tương tự như vậy, tôi cần tách sự phá hủy khỏi free()cuộc gọi tiếp theo , v.v.

Vấn đề là, tất cả những điều bổ sung này là khá vô trí. Tôi có thể làm chúng rất nhanh. Vì vậy, tôi sẽ không mất nhiều thời gian để viết phiên bản C hơn là tôi cần viết phiên bản C ++. Tuy nhiên, tôi đã tạo ra nhiều dòng mã C hơn mã C ++. Vì vậy, tôi dường như đã làm việc hiệu quả hơn trong C về SLOC.

Bất kỳ ngôn ngữ nào yêu cầu một số lượng mã soạn sẵn sẽ xuất hiện hiệu quả hơn về mặt SLOC so với ngôn ngữ không yêu cầu cùng số lượng mã soạn sẵn.

Bạn thấy đấy, đối số SLOC rất thiếu sót về cơ bản, đến nỗi tôi thực sự nhìn thấy nó theo cách khác: Tôi sẽ đưa ra tuyên bố "các lập trình viên có xu hướng tạo ra nhiều SLOC hơn trong các ngôn ngữ tĩnh" có nghĩa là: "ngôn ngữ tĩnh xuất hiện để yêu cầu nhiều hơn mã soạn sẵn, và do đó làm giảm năng suất ".

Tôi sẽ là người thay thế.

Chúng tôi theo dõi SLoC trong công việc của mình (mặc dù chúng tôi không sử dụng nó trực tiếp trong các quyết định nhân sự) và tôi đã có người tranh luận về những gì hầu hết mọi người đang nói trong câu trả lời của họ. Trên thực tế, "LoC không thành vấn đề vì công nghệ X cho phép chúng tôi làm được nhiều hơn với ít mã hơn" hoặc "Nhà phát triển tốt hơn viết tốt hơn, mã ngắn hơn và vì vậy họ không viết nhiều hơn bất kỳ ai khác". Theo kinh nghiệm của tôi (mặc dù tôi không có bất kỳ con số khó khăn nào để sao lưu những thứ này), những phản đối này đơn giản là không chính xác. Trong thời gian của riêng tôi, tôi đã thấy một mối tương quan rõ ràng về cả tốc độ và chất lượng sản xuất mã cho các nhà phát triển của chúng tôi, khi so sánh với tất cả các phép đo có ý nghĩa khác về "năng lực" tổng thể của họ với tư cách là một kỹ sư. Để đưa ra một số ví dụ ngược với các loại lập luận được đưa ra ở trên:

1. Có, một số ngôn ngữ có thể làm nhiều hơn với ít mã hơn. Trên thực tế, chúng tôi đã có toàn bộ khuôn khổ mà chúng tôi đã xây dựng để "tự động hóa" các phần lớn của sự phát triển cho các vấn đề kinh doanh cụ thể của chúng tôi (chỉ hỗ trợ). Kết quả của tất cả những điều này không phải là mọi người viết ít mã hơn, mà đơn giản là chúng ta có nhiều thời gian hơn để viết mã. Kết quả là, trong công ty của chúng tôi, tỷ lệ viết mã chung là không đổi giữa các công nghệ và phụ thuộc chủ yếu vào mức độ năng lực của kỹ sư.
2. Ý tưởng rằng một nhà phát triển tốt hơn sẽ tạo ra ít mã hơn bởi vì họ đang viết thông minh hơn chắc chắn là không đúng. Có, một chương trình được thiết kế tốt hơn có thể chiếm ít dòng mã hơn. Tuy nhiên, cá nhân tôi đã phát hiện ra rằng các nhà phát triển "tốt hơn" viết mã hiệu quả hơn sẽ không mất nhiều thời gian để lên kế hoạch hơn là một nhà phát triển cơ sở hơn đang viết công cụ theo cách lâu dài. Kết quả là, nhà phát triển cao cấp hơn sẽ hoàn thành công việc mã hóa của họ nhanh hơn và chuyển sang viết mã khác nhau với cùng tốc độ cao.

Phần lat đó là tóm tắt chung của tôi, BTW. Những gì tôi đã tìm thấy là bất kể ngăn xếp công nghệ hay loại dự án, hầu hết các nhà phát triển đều có tốc độ của riêng họ, đó là tốc độ mà họ vận hành. Nếu một ngôn ngữ có nhiều tính năng giúp mã nhà phát triển hiệu quả hơn, thì đó là một lợi ích lớn cho doanh nghiệp, nhưng điều đó không có nghĩa là họ sẽ viết ít mã hơn. Thay vào đó, họ nhận được các tính năng được thực hiện nhanh hơn và nhanh chóng chuyển sang mã mới. Một lần nữa, kết quả cuối cùng là họ đánh giá mã mà họ phụ thuộc chủ yếu vào kỹ năng của họ và ít hơn vào ngăn xếp công nghệ của họ. Trên thực tế, vì điều này, tôi thường hy vọng rằng ngăn xếp công nghệ sẽ tạo ra nhiều sự khác biệt về tốc độ phát triển vé và tính năng so với tốc độ mà mọi người viết mã.

Điều đó đang được nói, không phải tỷ lệ viết mã hay tỷ lệ đóng vé là một thước đo hoàn hảo về năng suất, đó là lý do tại sao chúng tôi không trực tiếp đưa ra quyết định nhân sự trên cơ sở SLoC. Thay vào đó, nó là một phần của quy trình và việc đánh giá nhân viên được thực hiện bằng cách sử dụng càng nhiều điểm dữ liệu càng tốt. Tôi sẽ nói mặc dù Kiến trúc sư của bạn chắc chắn không điên.

Một ngoại lệ

Một ngoại lệ tôi đồng ý là khả năng của mã nồi hơi. Nếu có rất nhiều bản sao và dán đang diễn ra từ một lớp (hoặc bất cứ thứ gì) sang một lớp khác để có được nó và chạy, thì đó rõ ràng là sẽ làm lệch các số liệu. Điều này cũng đúng nếu bạn có công cụ có thể tự động tạo ra số lượng lớn mã cho bạn. Tuy nhiên, tôi nghĩ rằng những điều này thường sẽ là ngoại lệ chứ không phải là quy tắc. Nếu các nhà phát triển của bạn dành bất kỳ khoảng thời gian nào để sao chép xung quanh mã nồi hơi để bắt đầu, thì bạn đang sử dụng bộ công nghệ sai. Nếu họ thực sự đang viết mã, ngay cả khi nó khá lặp đi lặp lại, thì tôi hy vọng điều này sẽ làm lệch bất kỳ phép đo nào chỉ một lượng nhỏ: khi viết mã, phần lớn chúng ta bị giới hạn bởi cách chúng ta có thể nghĩ nhanh hơn về vấn đề hơn là chúng ta có thể gõ nhanh như thế nào. Ngay cả khi viết mã tương đối lặp đi lặp lại,

Rõ ràng, mọi thứ ở trên đều dựa trên kinh nghiệm cá nhân của tôi. Số dặm của bạn có thể thay đổi, và rõ ràng tôi thuộc thiểu số. Hãy đồng ý. Tóm lại:

Tôi thấy rằng tốc độ mã hóa phụ thuộc nhiều hơn vào tốc độ bạn có thể nghĩ thông qua các vấn đề của mình sau đó bất cứ điều gì khác. Kết quả là, tôi đã thấy rằng tốc độ mã hóa là một thước đo tốt về năng suất, thậm chí trên các bộ công nghệ, chỉ có một vài ngoại lệ có thể xảy ra.

Mặc dù tôi đang nhảy vào bandwagon. Tôi nghĩ rằng tác động lên hành vi của các lập trình viên cần phải được làm nổi bật.

Sử dụng SLOC làm thước đo cho năng suất có ảnh hưởng độc hại đến tinh thần lập trình viên. Khoảnh khắc bất kỳ kỹ sư nào trong nhóm / công ty của bạn nhận ra họ được đo trên SLOC, một số điều xảy ra:

1. Họ bắt đầu viết mã dài hơn nhiều để làm cùng chức năng
2. họ sẽ quan tâm ít hơn về chất lượng mã của họ
3. họ sẽ ngừng làm những việc khác giúp nhóm của bạn (tuyển dụng, gỡ lỗi, giúp đỡ đàn em)
4. họ sẽ ghét công việc của họ và có khả năng rời đi

Tôi không thể nhấn mạnh đủ đến mức độ ăn mòn của kỹ sư như thế nào khi tôi thấy điều đó xảy ra hai lần tại 2 công ty khác nhau. Bất kể trường hợp sử dụng nào có vẻ hợp lệ mà bạn có cho nó, tôi lập luận rằng nó không có khả năng ảnh hưởng đến nhóm / công ty của bạn ngay cả khi chỉ có một cơ hội nhỏ là việc sử dụng nó sẽ được phát hiện. Mặc dù trong một số trường hợp có thể có mối tương quan giữa số dòng được viết và số lượng tính năng hữu ích, nó khuyến khích tất cả các hành vi sai trong lập trình viên của bạn và gửi thông điệp, chất lượng không quan trọng.

Nó thường không được coi là một cách hợp lệ để đo lường năng suất. Mã nhỏ hơn thường tốt hơn mã lớn hơn, vì vậy một nhà phát triển năng suất cao hơn thường tạo ra ít mã hơn. Năng suất đạt được thành công lớn nhất trong việc gỡ lỗi; nhà phát triển hiệu quả dành ít thời gian để gỡ lỗi.

Các ngôn ngữ được nhập tĩnh có năng suất cao hơn (nếu bạn kiểm soát tất cả các khác biệt khác giữa các ngôn ngữ), vì khi được sử dụng một cách khôn ngoan, chúng sẽ giảm thời gian gỡ lỗi, bắt lỗi trong giai đoạn biên dịch, nơi chúng nhanh hơn để sửa.

Số liệu duy nhất mà bạn có thể sử dụng để so sánh năng suất cho các nhà phát triển giữa các ngôn ngữ là một số liệu không so sánh mã giữa các ngôn ngữ. Một số ngôn ngữ nổi tiếng là dài dòng (COBOL cho chiến thắng kế thừa) và những ngôn ngữ khác yêu cầu một số bước để làm điều gì đó bạn có thể làm trong một dòng mã (lắp ráp so với mọi thứ khác). Ngay cả khi bạn chỉ so sánh các dòng mã đang hoạt động (nghĩa là không đếm các khai báo và chỉ đếm các mã có một số hành động liên quan), bạn vẫn có thể làm sai lệch kết quả của mình.

Bạn có thể đưa ra một lập luận cho tỷ lệ thay đổi. Tức là các dòng mã được thêm vào, so sánh độ dốc của năng suất trong cùng khoảng thời gian. Tuy nhiên, điều đó không giải thích cho những thay đổi tiêu cực trong dòng mã. Ví dụ, bạn kế thừa một dự án có sao chép và dán mã ở mọi nơi. Bạn thực hiện một số phép tái cấu trúc nhanh chóng và dễ dàng để giảm số khối mã lặp đi lặp lại - theo định nghĩa bạn có độ dốc âm.

Nói một cách nghiêm túc, việc so sánh năng suất của các nhóm / ngôn ngữ là vô nghĩa vì có rất nhiều yếu tố bổ sung ảnh hưởng đến năng suất của nhóm, bạn không thể rút ra kết luận có ý nghĩa từ nó.

Tôi đã làm việc trong một dự án nơi cơ sở hạ tầng rất mong manh và các công cụ đã lỗi thời. Dự án được xây dựng trên Java với Ứng dụng một trang được đặt trên đó, nhưng được lưu trữ trong một thùng chứa portlet không mang lại lợi ích rõ ràng. Thời gian để thực hiện ngay cả những thay đổi đơn giản là rất dài. Nếu bạn dựa trên tất cả các kết luận của bạn về dự án cụ thể đó, bạn có thể kết luận rằng Java là xấu hoặc Ứng dụng trang đơn là xấu. Không phải là sự thật. Hệ thống mà dự án xấu xí được cho là sẽ thay thế được xây dựng trên C # và WebForms. Khi chúng tôi thực hiện trường hợp kinh doanh để mở rộng ứng dụng hiện có để đáp ứng nhu cầu của khách hàng, năng suất của chúng tôi tăng vọt. Điều đó có nghĩa là một ứng dụng WebForms kết hợp chặt chẽ là tốt hơn? Bạn chỉ có thể đưa ra kết luận cho trường hợp cụ thể nàyvà nó không mở rộng ra thế giới nói chung. Và nó chỉ có ý nghĩa bởi vì đã có một ứng dụng hiện có đủ độ chín để mở rộng.

Ngay cả việc so sánh tỷ lệ giải quyết các mục trong hệ thống theo dõi vấn đề cũng thiếu sót theo nghĩa là bạn đang so sánh các cơ sở hạ tầng dự án hoàn chỉnh với nhau. Các thư viện và khung được sử dụng có thể tăng tốc hoặc làm chậm tiến độ. Bạn có thể đang trong giai đoạn khởi động với rất ít quán tính cần khắc phục, trong đó dự án bạn "tốt hơn" đang trong giai đoạn bảo trì trong đó số lượng vé mới tương đối thấp. Nó không bao giờ là một trường hợp so sánh như mọi thứ.