The following content is excerpted from the internet.：《魏略》蜀军大将魏延认为，长安守将夏侯楙年少，娇生惯养、怯而无谋。今日假若我魏延领精兵五千，背负粮草五千，直由山道深入，寻秦岭而向东，到达子午再往北行。不过十日就能抵达长安。夏侯楙见我军突然出现，必然乘船而逃。如此一来，长安城内只剩下御史、京兆太守而已。长安北门有散民之谷，足以供应我军粮食。而由东方相会合，需要二十日，届时丞相您在由斜谷赶来，必定可以在此与我会师，这么一来，可以一举平定咸阳以西。
Musings on the Ziwu Valley Strategy
When I first heard about Wei Yan’s “Ziwu Valley Strategy” as a teenager, I couldn’t help but lament that Zhuge Liang did not adopt it. However, after years of experience, especially as I’ve listened to game designers and developers argue about project requirements in the office, I gradually came to understand why Zhuge Liang rejected this plan 1,800 years ago.
Warfare in ancient times was a brutal affair. Ordinary people, conscripted by the government, had to abandon their farm work, receive minimal training, and were then thrust into battle as soldiers. Every soldier conscripted meant one less farmer, leading to potential food shortages if too many were taken from the fields. Without enough farmers to sustain agriculture, food scarcity would ensue, forcing armies to plunder resources elsewhere, leading to campaigns of “eastward conquests and westward expeditions.” The saying, “For every general’s success, a thousand bones lie dry,” aptly describes this cycle. After capturing a city, commanders often allowed their soldiers to loot, leading to what history coldly records as a “massacre.”
However, Liu Bei and Zhuge Liang’s faction in the Three Kingdoms era had no records of massacres. Objectively speaking, Liu Bei’s true rise began after he secured Zhuge Liang from Jingzhou. The plains of Jingzhou and Yizhou were vast, free from constant warfare, and blessed with abundant food supplies. Liu Bei’s forces did not need to massacre to obtain enough grain. Subjectively, Liu Bei might have genuinely adhered to his ideals or felt a responsibility as a member of the Han royal family to genuinely “cherish the people like his own children.” During the late Shu-Han period, Zhuge Liang, in his six campaigns against the state of Wei, chose not to wage endless wars but allowed his soldiers to farm and stockpile grain. Despite the treacherous Shu roads being as difficult to traverse as ascending the heavens, the broad Chengdu plains ensured the local people lived comfortably. Chengdu was known for producing the beautiful Shu brocade, which was exported far and wide. Life in Chengdu was far better than for the northern populace in the early 200s. Though Zhuge Liang’s kindness is not explicitly written in historical records, it resonates across 1,800 years to touch the hearts of all who love the history of the Three Kingdoms.
Would such a compassionate commander really be willing to risk the lives of 5,000 soldiers? Those soldiers, once they removed their armor, were merely mountain farmers. Perhaps behind those 5,000 soldiers were 5,000 pairs of parents, 5,000 wives, and countless children. Would such a risky decision be irresponsible toward those left behind?
From Wei Yan’s perspective, however, after the Five Tiger Generals and before Jiang Wei (whom he had yet to meet), there was no one more powerful or prestigious than him. For a soldier, wartime is the golden opportunity to make a name for oneself. If he could capture Chang’an in one bold stroke, he would become the top military officer of Shu-Han. Driven by such ambition, proposing such a risky strategy is understandable.
As I grew older and came to grasp the brutal realities of war and the unpredictability of human nature, I realized that Wei Yan’s so-called “brilliant plan” was nothing more than a wild gamble, risking 5,000 lives for a slim chance at historical fame. It is no wonder Zhuge Liang dismissed it. Even if Chang’an were captured, what then? The state of Wei controlled almost all of the northern territories and had many seasoned generals who had fought alongside Cao Cao. Could Wei Yan really hold onto the city? The answer is obvious.
So, why do people still discuss the “what ifs” in the 21st century? I believe it’s partly because many people genuinely regret the repeated failures of Zhuge Liang and Jiang Wei’s campaigns, and partly because Wei Yan’s strategy did have a sliver of potential—perhaps it could have given Shu-Han an edge. But they never fully consider what the next step would have been if they succeeded, or the massive losses if they failed.
Software Engineering as the Art of War in the Software Industry
Almost all stable software in operation today is supported by a maintenance team. This team typically does two things: develop new features and fix bugs. How to iterate versions steadily, how to maintain the usability of developed features, how to ensure that new features do not affect old ones, and how to minimize users’ learning costs for new features—all fall within the realm of software engineering. If we liken software development to a battle, then designing software is akin to formulating tactics, developing software is like recruiting troops, launching and releasing software is like marching to war, and facing users is the front line of the battlefield. If there is an emergency on the front line, commanders must promptly allocate resources and resolve issues.
To smoothly navigate the development, release, and maintenance processes, software engineering offers various development models, such as the waterfall model, rapid prototyping, incremental model, and agile model. When first learning these models, one might find them convoluted and difficult to grasp. But simply put, they describe how to allocate manpower to complete a series of processes: requirement analysis, software design, software development, software release, and software maintenance. In the past, when using the waterfall model, clients couldn’t see the expected results during the software development process and only encountered the final product after its completion. If the client was dissatisfied, the whole process had to be redone. Later, people proposed first designing a prototype for the client to review, drafting a glossary to ensure that the discussions were aligned with the goals (this is also the concept behind Domain-Driven Design, DDD). Another approach is to break down the requirements, complete one, and release it—this is the incremental model. Or, increase the number of deliveries, use the agile model, and take a specific time length as the output cycle, providing weekly feedback (not necessarily completing the entire function, but at least part of it). These optimized development models aim to allow the client to observe the software development process as early as possible.
However, in the current software industry, both domestically and internationally, most teams do not strictly follow these development models. Many complex factors are behind this. Clients, as the demanding party, might not clearly define what they want; developers, as the service providers, might exaggerate their capabilities to win contracts; and programmers might misunderstand the requirements slightly differently than their leaders. Not to mention technical selection, performance indicators, and other aspects that require time-consuming analysis. Fully adhering to advanced development models requires that the client, developer, and entire development team be above a certain competency level (though what constitutes a “competent” level is hard to define) and engage in effective, thorough communication.
Now, let’s talk about requirement changes. Requirement changes are almost unavoidable in the software industry. In fact, there’s hardly any demand in the world that remains unchanged. However, the cost of requirement changes in the software industry is often difficult to estimate accurately. Software is intangible data that we merely view through monitors. Different people will always have different interpretations of the requirements and the effort needed to adapt to changes. Leaders may not always accept the front-line developers’ time estimates for requirement changes, influenced by various factors such as client demands or discrepancies in understanding between leaders and developers. Requirement changes invariably bring about significant, hard-to-assess costs, which is one reason the agile model was proposed: to allow for flexible adjustments when requirements change.
When it comes to time estimation, trusting programmers’ assessments of development time is the most reasonable approach, provided there is mutual trust. However, due to a lack of trust or a desire to see more content developed in a shorter time, some leaders might force programmers to compress development timelines. This might allow the functionality to go live quickly and seemingly work well, but the long-term risks remain known only to the development team. In this industry, every developer is glued to their monitor, typing in code, and leaders cannot immediately judge if the programmers are slacking off. As a result, when leaders encounter a few unprofessional programmers, they might develop a bias against the entire field.
From this perspective, open-source software naturally accepts everyone’s code reviews. Even if the main repository does not merge changes, anyone can fork and create a new repository for development, ensuring that hidden risks are eventually uncovered. This is why programmers tend to prefer projects with a high number of stars and a strong, reputable community behind them.
Wei Yan Wouldn’t Make a Good “Development Manager”
Returning to the Ziwu Valley Strategy, from a software engineering perspective, it’s evident that Wei Yan wanted to change the requirements mid-process (after the army had already been deployed), disregarding development costs (the 5,000 soldiers), and this change could have led to the software crashing (triggering the full wrath of Wei and the fall of Shu). The online discussions surrounding the Ziwu Valley Strategy often stop at “what if it succeeded.” Perhaps this is why, in software development, leaders always propose “unreasonable” requirements.
Of course, we’re discussing why, from a software engineering perspective, it’s crucial to avoid risky decisions when facing significant and challenging requirement changes. But this isn’t absolute. During the Three Kingdoms period, Zhang Liao led his troops to wreak havoc in Sun Quan’s camp. In the first two decades of the 21st century, companies that rushed to launch software often made fortunes. From this perspective, what is considered reasonable in software engineering might not be reasonable in real-world scenarios. The team’s ability, the expectations and needs of both parties, the timing of success, and luck are all unpredictable factors. Strictly adhering to software engineering principles might only lead to a downfall like Ma Su losing Jie Ting.
Perhaps we’ve just found a reason for overtime? (Laughs)