[Học tiếng Anh] The Prisoner's Dilemma in Software Development

Recommended for you

Bài dịch sau đây là một Case Study điển hình trong giao dịch ký kết hợp đồng phát triển phần mềm với khách hàng. Bài viết có thể nhiều thuật ngữ và cách viết rất khó có thể dịch chuẩn sang tiếng Việt. Tác giả sẽ trình bày cả bản gốc và bản dịch đẻ độc giá dễ dàng nắm vững nội dung ở góc độ logic nhất có thể.

Prisoner's Dilemma (tiến thế lưỡng nan của người tù) là học thuyết kinh điển trong kinh tế và áp dụng trong mọi lĩnh vực xã hội, khoa học.... Tình huống này nhằm tìm kiếm một giải pháp cân bằng cho cả 2. Nếu cùng hợp tác (cooperate, remain silent) thì rủi ro của cả 2 đều giảm (số năm tù sẽ giảm), nhưng nếu cùng phản bội nhau (defection, confess), chống lại nhau thì cả 2 đều chịu rủi ro ngang nhau (không lớn, cũng không nhỏ). Nếu một người hợp tác, người còn lại phản bội thì người hợp tác sẽ chịu rủi ro thấp hơn.

Sau đây Tuệ Linh xin dịch bài "tình thế lưỡng nan của người tù trong giao dịch xây dựng phần mềm" (The Prisoner's Dilemma in Software Development)

Mọi mối quan hệ phát triển phần mềm đều là tình thế tiến thoái lưỡng nan của người tù (prisoner's dilemma) và hầu hết (nếu liên quan đến nhiều giai đoạn) đều là tình huống lặp lại của câu chuyện này.	Every software development relationship is a prisoner's dilemma, and most (if they involve multiple phases) are iterated prisoner's dilemmas.
Bạn, một nhà phát triển phần mềm, có ý định đổi "code" lấy tiền với khách hàng của mình. Nếu bạn giao thứ gì đó không hiệu quả và khách hàng trả tiền cho nó, bạn đã nhận được tất cả lợi ích của giao dịch và khách hàng là kẻ "khờ dại". Nếu bạn cung cấp phần mềm và khách hàng đã nhận nhưng không trả tiền, tình thế sẽ đảo ngược và bạn là kẻ "khờ dại".	You, the developer, intend to exchange code for money with your client. If you deliver something that does not work, and the client pays for it, you have received all the benefit of the transaction and the client has gotten the sucker's payoff. If you deliver functional software, and the client keeps it but fails to pay, the tables are turned and you have received the sucker's payoff.
Nếu cả hai bạn cùng thực hiện một cách hợp tác-- bạn cung cấp phần mềm chạy được và khách hàng trả tiền--cả hai bạn đều được hưởng lợi, nhưng cũng có thể sẽ giảm thiểu thiệt hại nếu một trong hai người lợi dụng người kia (thí dụ có thể là bạn làm việc vất vả hơn so với mức bàn giao sản phẩm tối thiểu, source code vẫn không chạy và khách hàng sẽ mất số tiền mà lẽ ra họ có thể giữ lại.) Nếu cả hai bạn đều sai, cả hai bạn đều thua nhưng ít nhất khách hàng đã giữ được tiền và bạn vẫn giữ lại code của mình.	If you both perform cooperatively-- you deliver working software and the client pays--you both benefit, but arguably less than if one of you had taken advantage of the other (you have worked harder, presumably, than if you had delivered minimal, nonfunctional code, and the client is out the money it could have kept.) If you both defect, you both lose out but at least the client has kept its money and you retained your code.
Trong một thế giới hoàn hảo, khách hàng sẽ trả cho bạn toàn bộ chi phí ngay từ đầu dự án phát triển phần mềm và bạn sẽ liên tục bàn giao các đoạn code chạy được ngay. Thực tế không phải hoàn hảo, nên mô hình hợp đồng phát triển phần mềm nghiệm thu nhiều giai đoạn đã dần hình thành, với các khoản thanh toán theo các mốc quan trọng đã hoàn thành. Kiểu hợp đồng này biến những gì có thể là trò chơi một lượt (từ đầu đến cuối), không có bóng dáng của tương lai, thành một cuộc giao tranh nhiều vòng; mỗi giai đoạn của hợp đồng trên thực tế là một vòng quay riêng biệt trong thế tiến thoái lưỡng nan của tù nhân.	In a perfect world, the client would pay you the whole price at the outset of the software development project, and you would always deliver working code. Since this is not a perfect world, the multi-phased software development contract has evolved, with payments made against successfully completed milestones. This style of contract turns what might have been a one-turn game, with no shadow of the future, into a multi-round engagement; each phase of the contract is in effect a separate round of the prisoner's dilemma.
Hợp đồng phát triển phần mềm theo cách điển hình là, với cơ chế đảm bảo và chấp nhận, thay đổi trình tự các lượt để khách hàng, trong mỗi vòng, có thể xác định xem bạn có hợp tác hay không (bằng cách kiểm tra "code" của bạn để xem liệu có đáp ứng thông số kỹ thuật và có hoạt động không) trước khi quyết định nước cờ của mình.	The classic software development contract, with its guarantee and its acceptance machinery, shifts the sequence of turns so that the client, on each round, may determine whether you have cooperated (by examining your code to see if it meets the spec and is functional) before determining its own move.
Tuy nhiên, hợp đồng, nếu được soạn thảo kỹ và công bằng, sẽ bảo vệ bạn (đơn vị phát triển) bằng cách xác định chặt chẽ những kỳ vọng của khách hàng và hạn chế khả năng khách hàng từ chối chấp nhận nghiệm thu. Nếu không có thỏa thuận như vậy (thể hiện sự thỏa thuận tạm ứng của các bên để "chơi bài" hợp tác trong mỗi vòng chơi), việc khách hàng từ chối thanh toán ở vòng cuối cùng là điều quá phổ biến, để buộc bạn phải đưa vào các yêu cầu bổ sung không có trước đây, thậm chí cũng không bao giờ nghĩ đến.	However, the contract, if well-drafted and fair, also protects you, the developer, by tightly defining the client's expectations and by restricting the client's ability to defect by withholding acceptance. Without such an agreement (which represents an advance compact by the parties to play the cooperation card on each round), it is all too common a spectacle to see a client withhold payment on the last round, to force the inclusion of additional requirements not previously thought of.
Đối với một hợp đồng, vấn đề phát sinh yêu cầu vẫn có thể xảy ra; "vì thế tiến thoái lưỡng nan của tù nhân" lặp đi lặp lại cho một số vòng đã biết, cho nên khách hàng - không mong muốn giao dịch với đơn vị phát triển lần nữa - có thể bỏ cuộc ở vòng cuối cùng, chỉ đơn giản là hy vọng giữ được số dư tiền của họ. Nhưng một hợp đồng được soạn thảo kỹ ít nhất sẽ hạn chế khả năng "bùng" ở phút chót.	Even with a contract, this may happen; since the iterated prisoner's dilemma is for a known number of rounds, the client, not expecting to deal with you again, may defect on the last round, simply hoping to keep the balance of its money. But a well-drafted contract will at least limit its ability to get away with such a defection.
Ngược lại, hầu hết các trường hợp rút lui của các đơn vị phát triển đều là kết quả của sự sơ suất chứ không phải do mục đích xấu. "Bóng tối của tương lai" đè nặng lên các nhà phát triển, những người mong muốn tiếp tục duy trì kinh doanh và mong nhận được những đề xuất tốt từ khách hàng, trong khi hầu hết khách hàng không làm trong ngành máy tính, không quan tâm đến các dịch vụ tiếp theo trước mắt và không lường trước các vấn đề sẽ phải tìm kiếm các đơn vị phát triển phần mềm sẵn sàng đáp ứng ngay cả khi họ đã chặt đứt đường lui.	By contrast, most defections by developers are the result of negligence, not malicious intent. The shadow of the future lies more heavily on developers, who wish to remain in the business and obtain good recommendations from clients, while most clients are not themselves in the computer industry, don't expect to need further services immediately and do not anticipate any problems finding software developers eager to serve them even if they have burned one or two.
Việc khách hàng từ bỏ có thể có các nguyên nhân khác ngoài việc giữ lại tiền. Có thể liên quan đến việc giải thích ác ý về một yêu cầu không rõ ràng, bao gồm chức năng mà nhà phát triển không thể xây dựng với mức giá đã thỏa thuận mà vẫn đảm bảo có lợi nhuận. Hoặc khách hàng có thể đổ lỗi cho nhà phát triển về những thiếu sót hay không có khả năng đáp ứng các cam kết, khiến bạn trở thành "vật tế thần" cho một cuộc đấu tranh chính trị nội bộ trong tổ chức của khách hàng.	Defection by the client may take other forms than the withholding of money. It might involve a malicious interpretation of an ambiguous requirement, to include functionality that the developer cannot possibly deliver for the agreed price and still make a profit. Or the client may blame you for its own shortcomings or inability to meet its commitments, making you the scapegoat for an internal political struggle.
Các thí nghiệm của Axelrod đã xác định rằng chiến lược hiệu quả nhất nhưng đơn giản nhất trong tình huống tiến thoái lưỡng nan của tù nhân lặp đi lặp lại là "Ăn miếng trả miếng", trong đó bạn bắt đầu bằng sự hợp tác ở bước đầu tiên nhưng sau đó lặp lại bất cứ điều gì đối tác của bạn đã làm ở bước cuối cùng. Thực tế, điều này có nghĩa là sự hợp tác luôn được đền đáp bằng sự hợp tác khác, trong khi hành động quay lưng sẽ bị trừng phạt ngay lập tức bằng hành động tương tự (quay lưng).	Axelrod's experiments determined that the most effective, yet simplest strategy in an iterated prisoner's dilemma is "Tit for Tat", in which you begin with cooperation on the first move but then echo whatever your partner did on the last move. Effectively, what this means is that cooperation is always rewarded with cooperation, while defection is immediately punished with defection.
Điều đáng ngạc nhiên là hầu hết các nhà phát triển phần mềm đều không thể áp dụng chiến lược này cho khách hàng của họ vì nhiều lý do. Các nhà quản lý dự án có thể bị các đồng nghiệp Sale hoặc giám đốc khối lấn át, những người luôn cho rằng mềm mỏng với khách hàng là chính sách dài hạn tốt nhất. Đôi khi cảm giác tội lỗi "bạn có thực sự làm đủ tốt ở sản phẩm đầu tiên không?" sẽ xen vào trí óc. Trong bất kỳ trường hợp nào, bất cứ khi nào chúng ta nghe về một hợp đồng phát triển phần mềm trong đó nhà phát triển đã bắt đầu Giai đoạn II mặc dù Giai đoạn I chưa được chấp nhận và thanh toán, chúng ta biết rằng nhà phát triển đang chơi trò "Cùng hợp tác", một chiến lược chắc chắn sẽ thúc đẩy khách hàng chơi "Tất cả đều quay lưng", vì không còn gì để mất. Và nhà phát triển bây giờ sẽ nhận được phần thưởng của kẻ thua cuộc ở mỗi vòng chơi như vậy.	Surprisingly, most software developers are constitutionally unable to apply this strategy to their clients, for a variety of reasons. Project managers may be overruled by salespeople or account managers, who think that being soft on the client is the best long term policy. Sometimes a sense of guilt--did you really do a good enough job on the first deliverable?--intervenes. In any event, whenever I hear of a software development contract in which the developer has commenced Phase II even though Phase I has not been accepted and paid for, I know the developer is playing "All Cooperate", a strategy which will certainly motivate the client to play "All Defect", as it has nothing to lose. And the developer will now receive the sucker's payoff on every round.
Bài học là: nhà phát triển phần mềm để tự bảo vệ mình trong một thế giới phi đạo đức, phải sẵn sàng dừng hoạt động trong cuộc chơi sau khi khách hàng quay lưng. Tất nhiên, trước khi quyết định làm như vậy, nhà phát triển phải tiến hành đánh giá khách quan, tốt nhất là có sự tham gia của những người ngang hàng không tham gia vào dự án, để xác định trách nhiệm của chính mình - cũng có thể khách hàng từ chối nghiệm thu một cách chính đáng vì chính nhà phát triển mới là người quay lưng mà không hề biết! Tuy nhiên, giả sử rằng bạn đã bàn giao source code đang chạy và khách hàng không thanh toán, thì việc tiếp tục triển khai và hy vọng rằng cuối cùng sẽ thành công là một hành động sai lầm.	The moral is that the developer, to protect itself in an unethical world, must be ready to stop performance on the round following a defection by the client. Of course, before deciding to do so, the developer must conduct an objective review, preferably involving peers not involved in the project, to determine its own responsibility--perhaps the client justifiably withheld acceptance because the developer defected on the last round, and does not know it! But, assuming that you delivered working code and the client has failed to pay, going forward and hoping that all will come out right in the end is a sucker's move.
Một hợp đồng phát triển phần mềm hầu như luôn triển khai cho một số giai đoạn đã xác định rõ (và do đó "tình thế tiến thoái lưỡng nan của tù nhân" là về một số lần lặp đã xác định), do vậy việc ngăn chặn khách hàng của bạn quay lưng ở vòng chơi cuối có thể đoán trước được là một nút thắt.	Since a software development contract is almost always for a known number of phases (and therefore the associated prisoner's dilemma is for a known number of iterations) preventing your client's predictable defection on the last round is a knottier problem.
Đến lúc này, "bóng tối của tương lai" có thể đã mờ dần; khách hàng có một sản phẩm vừa ý, nhưng họ có thể phát hiện ra một số lỗi nhỏ, thay vì chuyển sang giai đoạn bảo hành/ bảo trì, họ có thể dựa vào đó như một cái cớ để giữ lại khoản thanh toán cuối cùng.	By now, the shadow of the future may be relatively slight; the client has a satisfactory product, but can certainly spot some minor bugs, which, instead of submitting to maintenance, it can pleasantly rely on as an excuse to withhold the last payment.
Lợi ích của khoản thanh toán chấp nhận nghiệm thu (UAT) được giữ lại túi dường như lớn hơn nhiều so với lợi ích khi biết bạn hài lòng và sẵn sàng hợp tác lần nữa. Dưới đây là một số chiến lược mà các nhà phát triển sử dụng để đảm bảo sự hợp tác ở vòng cuối cùng:	The benefit of the acceptance payment retained in its pocket may seem far greater than the benefit of knowing you are happy and available to do business with it again. Here are some strategies developers use to assure cooperation on the last round:
Dưới đây là một số chiến lược mà các doanh nghiệp phần mềm sử dụng để đảm bảo sự hợp tác ở vòng cuối cùng:	Here are some strategies developers use to assure cooperation on the last round:
Bao gồm mã khóa phần mềm (software key) phải được chuyển giao để sản phẩm hoạt động sau ngày dự kiến chấp nhận kết quả nghiệm thu. Những thỏa thuận như vậy phải được công khai trước một cách rõ ràng và thậm chí việc đó chỉ được thực hiện khi có lời khuyên của luật sư. Sự sắp xếp như vậy càng giống một quả bom hẹn giờ không được tiết lộ thì nó càng có thể bất hợp pháp.	Include a software key that must be turned over for the product to work after the date by which acceptance was scheduled to occur. Such arrangements must be clearly disclosed in advance, and even then should only be done with advice of counsel. The more such an arrangement looks like an undisclosed time bomb, the more illegal it may be.
Nêu rõ trong hợp đồng của bạn rằng bạn sở hữu mã nguồn cho đến khi khoản thanh toán cuối cùng được thực hiện.	State in your contract that you own the code until the finbal payment has been made.
Giữ lại thứ gì đó để "nắm đằng chuôi" khi nghiệm thu, chẳng hạn như mã nguồn hoặc thư viện lớp bên trong (lớp lõi) không liên quan đến nghiệm thu nhưng rất quan trọng cho việc sử dụng sản phẩm sau này.	Withhold something pending acceptance, such as source code or a class library irrelevant to acceptance testing but crucial for later use of the product.
Định nghĩa quá trình chấp nhận nghiệm thu theo phạm vi hẹp hơn trong hợp đồng đến mức khách hàng biết đó là một sự "chắc chắn ảo" rằng, nếu họ giữ lại khoản thanh toán cuối cùng, bạn (nhà thầu) sẽ thắng kiện.	Define acceptance so narrowly in the contract that the client knows it is a virtual certainty that, if it withholds the last payment, you will sue and win.
Làm việc trong một lĩnh vực chuyên môn "ngách" mà bạn là người chơi duy nhất hoặc được công nhận là giỏi nhất--điều này sẽ làm tăng thêm "bóng mờ của tương lai", vì rất có thể khách hàng sẽ lại cần đến bạn.	Work in a niche specialty in which you are the only player or are recognized to be the best--this will increase the shadow of the future, as it is much more likely the client will need you again.

Perhaps repeated interactions can solve the prisoner’s dilemma… (Có lẽ các tương tác lặp đi lặp lại có thể giải quyết tình huống lưỡng nan của tủ nhân)

Một số cụm từ cần nhớ:

One-turn game: Trò chơi một lượt (từ đầu đến cuối)
Shadow of the future: Bóng mờ của tương lai, một hình thức trói buộc vào các lợi ích trong tương lai. Thường sử dụng trong chính trị và luật pháp quốc tế.
Defection: Phản bội, từ bỏ, quay lưng, quay xe.
Malicious interpretation: Sự diễn giải ác ý
Scapegoat: Vật tế thần
Tit for Tat: Ăn miếng trả miếng
Account Manager: Giám đốc khối
Justifiably: Một cách chính đáng
Sucker: Người dại dột
Come out right in the end: Rốt cuột sẽ ổn
Knottier problem: Vấn đề nút thắt
Virtual certainty: Sự chắc chắn ảo.

The Shadow of the Future

Conflict is the only solution to one-shot prisoner’s dilemma play (Xung đột là giải pháp duy nhất cho trò chơi tiến thoái lưỡng nan của người tù một phát)
If states play repeatedly but the end of the interaction is known ahead of time, the inevitability of future conflict sabotages cooperation in the present (Trong bàn cờ chính trị, nếu các quốc gia chơi trò chơi lặp đi lặp lại nhưng sự kết thúc của sự tương tác được biết trước, thì khả năng xảy ra xung đột trong tương lai sẽ phá hoại sự hợp tác hiện tại..)
If repeated play solves the prisoner’s dilemma, it must be that states do not know when their interaction will end (Nếu trò chơi lặp đi lặp lại giải quyết được tình thế tiến thoái lưỡng nan của tù nhân thì chắc hẳn các quốc gia không biết khi nào sự tương tác của họ sẽ kết thúc).

Tóm tắt các điểm chính (Key Points' Summary)

Các mối quan hệ phát triển phần mềm lặp đi lặp lại những tình huống lưỡng nan của người tù, trong đó hình thành mối quan hệ trao đổi: các nhà phát triển trao mã chương trình để nhận thù lao từ khách hàng.	Software development relationships are iterated prisoner's dilemmas, where developers exchange code for money with clients.
Nhà phát triển phần mềm sẽ nhận được tất cả lợi ích của giao dịch nếu khách hàng trả tiền cho sản phẩm, trong khi khách hàng sẽ nhận được giá trị của "ngu ngốc" nếu họ nhận được sản phẩm không chạy được.	The developer receives all the benefits of the transaction if the client pays for functional software, while the client gets the sucker's payoff if they deliver nonfunctional code.
Nếu cả hai bên hợp tác thì cả hai đều có lợi, nhưng lợi ịch sẽ ít hơn nếu một bên lợi dụng bên kia.	If both parties cooperate, both benefit, but less than if one takes advantage of the other.
Nếu cả hai bên phản bội, cả hai sẽ đều thua cuộc, nhưng khách hàng vẫn giữ được tiền và nhà phát triển vẫn giữ được sản phẩm (bao gồm mã nguồn).	If both parties defect, both lose out, but the client retains the money and the developer retains the code.
Trong phát triển phần mềm, "Khách hàng luôn đúng" là một khẩu hiệu nguy hiểm, vì nó khuyến khích khách hàng không ngừng từ bỏ. Một phương châm tốt hơn sẽ là: “Khách hàng luôn đúng, cho đến khi khách hàng mắc sai lầm”.	In software development, the "Customer is Always Right" is a dangerous slogan, as it encourages the client's endless defection. A better motto would be: "The customer is always right, until it defects."
Sự phát triển của hợp đồng phát triển phần mềm nhiều giai đoạn (nghiệm thu và thanh toán) đã biến trò chơi thành một cuộc giao tranh nhiều vòng, trong đó mỗi giai đoạn đóng vai trò là một vòng tách biệt trong thế tiến thoái lưỡng nan của người tù.	The evolution of the multi-phased software development contract has turned the game into a multi-round engagement, with each phase acting as a separate round of the prisoner's dilemma.
Hợp đồng phát triển phần mềm cổ điển thay đổi trình tự các lượt (chơi), giúp khách hàng xác định xem nhà phát triển có thực sự hợp tác hay không trước khi đưa ra quyết định cuối cùng.	The classic software development contract shifts the sequence of turns, allowing the client to determine whether the developer cooperated before deciding its own move.
Một hợp đồng được soạn thảo tốt sẽ bảo vệ nhà phát triển bằng cách xác định những kỳ vọng của khách hàng và hạn chế khả năng khách hàng từ chối chấp nhận.	A well-drafted contract protects the developer by defining the client's expectations and restricting the client's ability to defect by withholding acceptance.
Hợp đồng phần mềm nên bao gồm giai đoạn bảo trì, sau khi được nghiệm thu chấp nhận. Nếu khách hàng mong đợi cần bảo trì thì khả năng xảy ra sai sót sẽ ít hơn.	Include a maintenance phase in the software contract, following acceptance. If the client expects to need you for maintenance it is less likely to defect.
Hầu hết các trường hợp "quay lưng" của nhà phát triển là do sơ suất chứ không phải do mục đích xấu.	Most defections by developers are due to negligence, not malicious intent.
Sự "quay lưng" của khách hàng có thể liên quan đến việc diễn giải ác ý về một yêu cầu không rõ ràng hoặc khách hàng đổ lỗi cho nhà phát triển về những thiếu sót nào đó (ví dụ cho rằng phần mềm quá nhiều lỗi, nhưng không có hoặc không đủ căn cứ vào số liệu cụ thể về tiêu chí đánh giá chất lượng)	Defection by the client may involve malicious interpretation of an ambiguous requirement, or the client blaming the developer for its shortcomings.
Các thí nghiệm của Axelrod cho thấy chiến lược hiệu quả nhất trong sự lặp đi lặp lại các tình huống khó xử của tù nhân là "Ăn miếng trả miếng", trong đó sự hợp tác bắt đầu bằng sự hợp tác từ phía khách hàng.	Axelrod's experiments found that the most effective strategy in an iterated prisoner's dilemma is "Tit for Tat", where cooperation begins with cooperation on the part of the client.