[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2024.]
[编者注：在我们休息并准备迎接新的一年的同时，我们会重新发布今年的十大热门文章。请欣赏我们今年最喜欢的作品，我们将在2024年再会。]
With all the articles about just how amazing all the developments in AI have been, there’s plenty of hand wringing around the possibility that we, as software developers, could soon be out of a job, replaced by artificial intelligence. They imagine all the business execs and product researchers will bypass most or all of their software developers and asking AI directly to build exactly what they think they want or need. As someone who’s spent 15 years creating software from the specs these folks create, I find it hard to take all the worrying seriously.
随着各种报道对人工智能的惊人发展进行大肆宣传，有很多人开始担忧，我们这些软件开发者可能很快就会失业，被人工智能取代。他们设想所有的企业高管和产品研究员将绕过大部分或所有的软件开发者，直接让 AI 构建他们认为需要的产品。作为一个用这些人提供的规格创建软件 15 年的人，我发现很难把所有的疑虑当回事。
Coding can be a challenge, but I’ve never had spent more than two weeks trying to figure out what is wrong with the code. Once you get the hang of the syntax, logic, and techniques, it’s a pretty straightforward process—most of the time. The real problems are usually centered around what the software is supposed to do. The hardest part about creating software is not writing code—it’s creating the requirements, and those software requirements are still defined by humans.
编码可能是个挑战，但我从未花过超过两周的时间去找出代码的问题。一旦你掌握了语法、逻辑和技术，大部分时候这是个相当直接的过程。真正的问题通常都集中在软件应该做什么上。
This article will talk about the relationship between requirements and software, as well as what an AI needs to produce good results.
这篇文章将讨论需求与软件之间的关系，以及一个 AI 需要什么来产生好的结果。
It’s not a bug, it’s feature…no wait, it’s a bug
这不是一个 bug，这是一个特性…等等，这是一个 bug。
Early in my software career, I was placed on a project midstream in order to help increase the velocity of the team. The main purpose of the software was to configure custom products on ecommerce sites.
在我软件职业生涯的早期，我被安排参与一个正在进行的项目，以提升团队的工作速度。该软件的主要目的是在电商网站上配置定制产品。
I was tasked with generating dynamic terms and conditions. There was conditional verbiage that depended on the type of product being purchased, as well as which US state the customer was located in due to legal requirements.
我的任务是生成动态的条款和条件。根据购买的产品类型以及客户所在的美国州份（因为有法律要求），有条件的措辞是不同的。
At some point, I thought I found a potential defect. A user would pick one product type, which would generate the appropriate terms and conditions, but further along the workflow it would allow the user to pick a different product type and predefined terms and conditions. It would violate one of the features explicitly agreed on in the business requirement that had the client’s signature.
在某一时刻，我以为我发现了一个潜在的缺陷。用户会选择一种产品类型，这将生成适当的条款和条件，但在工作流程的更深处，它允许用户选择另一种产品类型和预定义的条款和条件。这将违反业务需求中明确同意的特性，而这个需求得到了客户的签名确认。
I naively asked the client, “Should I remove the input that allowed a user to override the right terms and conditions?” The response I got has been seared inside my brain ever since. His exact words were spoken with complete and total confidence;
我天真地问客户，“我应该移除允许用户覆盖正确条款和条件的输入吗？”我从此就记住了他的回答，他完全自信地说：
“That will never happen” “那永远不会发生”
This was a senior executive who had been at the company for years, knew the company’s business processes, and was chosen to oversee the software for a reason. The ability to override the default terms and conditions was explicitly requested by the same person. Who the heck was I to question anyone, much less a senior executive of a company that was paying us money to build this product? I shrugged it off and promptly forgot about it.
这是一位在公司工作多年的高级主管，他了解公司的业务流程，并因此被选为监督软件的人。由这个人明确提出需要覆盖默认的条款和条件的功能。我是谁，凭什么质疑任何人，更别说一个正在支付我们开发这个产品的公司的高级主管?我一笑而过，很快就忘记了它。
Months later, just a few weeks before the software was to go live, a tester on the client side had found a defect, and it was assigned to me. When I saw the details of the defect, I laughed out loud.
几个月后，就在软件即将上线的几周前，客户端的一个测试员发现了一个缺陷，并分配给了我。当我看到这个缺陷的细节时，我笑出了声。
That concern I had about overriding default terms and conditions, the thing I was told would never happen? Guess what was happening? Guess who was blamed for it, and who was asked to fix it?
记得我对覆盖默认条款和条件的担忧吗，那件我被告知永远不会发生的事？猜猜现在发生了什么？猜猜谁被责怪，谁被要求修复？
The fix was relatively easy, and the consequences of the bug were low, but this experience has been a recurring theme in my career building software. I’ve talked to enough fellow software engineers to know I’m not alone. The problems have become bigger, harder to fix, and more costly, but the source of the problem is usually the same: the requirements were unclear, inconsistent, or wrong.
这个补丁相对容易，这个 bug 的影响较小，但是这种经历在我构建软件的职业生涯中一直是一个常见的主题。我和足够多的同行软件工程师交谈，知道我不是唯一的。问题变得越来越大，越来越难解决，代价也越来越高，但问题的源头通常相同：需求不清晰，不一致或错误。
AI right now: Chess versus self-driving cars
当前的 AI : 棋盘游戏 对比 自动驾驶汽车
The concept of artificial intelligence has been around for quite some time, although the high profile advances have raised concerns in the media as well as Congress. Artificial intelligence has already been very successful in certain areas. The first one that comes to mind is chess.
人工智能的概念已经存在很长时间，虽然高调的进步在媒体和国会引发了关注。人工智能在某些领域已经取得了极大的成功。首先让人想到的就是国际象棋。
AI has been applied to chess as far back as the 1980s. It is widely accepted that AI has exceeded human’s ability to win at chess. It’s also not surprising, as the parameters of chess are FINITE (but the game has not yet been solved).
人工智能在 1980 年代就应用于国际象棋。公认的是，人工智能已经超越了人类在国际象棋上的胜利能力。这也不令人惊讶，因为象棋的参数是有限的（但是这个游戏尚未被解决）。
Chess always starts with 32 pieces on 64 squares, has well documented officially agreed upon rules, and most importantly has a clearly defined objective. In each turn, there are a finite number of possible moves. Playing chess is just following a rules engine. AI systems can calculate the repercussions of every move to select the move most likely outcome to capture an opponent's piece or gain position, and ultimately win.
棋总是从 64 个方格上的 32 个棋子开始，有详细记录的官方公认规则，最重要的是有明确定义的目标。每一轮，都有有限的可能走法。下棋就是遵循规则引擎。AI 系统可以计算每一步的影响，以选择最可能捕获对手棋子或占据位置，最终赢得比赛的走法。
There has been another front where AI has been very active - self driving cars. Manufacturers have been promising self-driving cars for quite some time. Some have the capacity to self-drive, but there are caveats. In many situations the car requires active supervision; the driver may need to keep their hands on the wheel, the self-driving feature is not autonomous.
人工智能在另一方面也非常活跃 - 自驾车。制造商们承诺的自驾车已经有一段时间了。有些车具有自驾的能力，但是有附带条件。在许多情况下，车辆需要主动监控；驾驶员可能需要把手放在方向盘上，自驾功能并不是自主的。
Like chess-playing AI programs, self-driving cars largely use rules-based engines to make decisions. Unlike the chess programs, the rules on how to navigate every possible situation are not clearly defined. There are thousands of little judgments drivers make in a given trip avoiding pedestrians, navigating around double-parked cars, and turning in busy intersections. Getting those judgments right means the difference between arriving at the mall safely or arriving at the hospital.
就像下棋的 AI 程序一样，自动驾驶汽车在大多数情况下也使用基于规则的引擎来做出决策。但与棋类程序不同，如何在可能的每一个情况中导航的规则并未明确定义。在一次旅行中，驾驶员需要做出成千上万的小判断，例如避开行人，绕过双停的汽车，和在繁忙的十字路口转弯。做出正确的判断意味着安全到达商场或是到达医院的区别。
In technology, the standard is five or even six 9s for availability—a website or service is available 99.999% (or 99.9999%) of the time. The cost to achieve the first 99% isn’t that high. It means that your website or service can be down for more than three days—87.6 hours—a year. However for each 9 you add at the end, the cost to get there grows exponentially. By the time you reach 99.9999%, you can only allow for 31.5 seconds of downtime a year. It requires significantly more planning and effort and of course is more expensive. Getting the first 99% may not be easy, but proportionally it’s a lot easier and cheaper than that last tiny fraction.
在技术领域，标准的在线时间通常为五九或六九的规定——一个网站或服务的在线时间为 99.999%（或 99.9999%）。达到首个 99%的成本并不高。这意味着你的网站或服务一年中可以超过三天——87.6 小时——的时间不在线。然而，每增添一个 9，达到这个标准的成本就会呈现指数级增长。到达 99.9999%可用性时，你一年只能容忍 31.5 秒的停机时间。这需要更多的规划和努力，当然，也更加昂贵。获得第一个 99%可能并不简单，但相对来说比获得最后那一小部分可用性更为容易和更为经济。
365 X 24 X 60 minutes = 525,600 minutes a year
365 X 24 X 60 分钟 = 525,600 分钟一年
99% availability -> down for 5256 minutes, 87.6 hours 99.9% availability -> down 526 minutes, 8.76 hours 99.99% -> 52 minutes, less than 1 hour 99.999% -> 5.2 minutes 99.9999% -> 0.52 minutes, roughly 31.5 seconds
99% 可用性 -> 不可用的时间为 5256 分钟，87.6 小时 99.9% 可用性-> 不可用的时间为 526 分钟，8.76 小时 99.99% 可用性-> 不可用的时间为 52 分钟，1 小时内 99.999% 可用性-> 不可用的时间为 5.2 分钟 99.9999% 可用性-> 不可用的时间为 0.52 分钟，约为 31.5 秒。
No matter how close AI gets to being good enough, there’s always the risk of accidents and fatalities. Those risks and consequences happen every day with humans behind the wheel. I don’t know what rate of accidents and fatalities will be acceptable by governments, but you have to think it needs to be at least as good as human beings.
无论 AI 的性能接近完美到何种程度，总会存在事故和致命伤害的风险。这些风险和后果，每天都在人类驾驶的情况下发生。我不知道政府会接受什么样的事故和致命伤害率，但是你必须认为它需要至少和人类驾驶的情况一样安全。
The reason it’s so difficult to get that acceptable level of safety is because driving a car entails significantly more variables than chess, and those variables are NOT FINITE. The first 95% or 99% might be predictable and easy to account for. However, there are so many edge cases after that first 99%, and each one may share some traits but each one is unique; other vehicles on the road driven by other human beings, road closures, construction, accidents, weather events, How many times have you driven after a road has been paved over but the paint for the dividing lines on the road has not been applied. It’s significantly harder to get your AI model to be able to account for and recognize those anomalies and edge cases, and more importantly how to respond appropriately without getting into an accident. Each edge case may share some traits, but rarely are they identical, which makes it harder for AI identify the appropriate way to respond.
没有关系，即使 AI 达到足够好的程度，仍然存在事故和死亡的风险。这些风险和后果每天都在发生，而驾驶员都是人类。我不知道政府会接受何种程度的事故和死亡率，但你必须认为它至少要达到和人类一样的程度。
AI can’t create software, only code
"AI 不能创建软件，只能编码"
Creating and maintaining software has a lot more in common with driving than playing chess. There are far more variables involved and the rules are based on judgment calls. You may have a desired outcome when you are building software, but it’s unlikely that it's as singular as chess. Software is rarely done; features get added and bugs are fixed; it’s an ongoing exercise. Unlike software, once a chess game is won or lost it's over.
创建和维护软件与开车比起来更像下棋。涉及的变量更多，规则基于判断。当你构建软件时，你可能有一个期望的结果，但很不可能像棋局那样单一。软件很少是一劳永逸的；功能得到添加，错误得到修复；这是一个持续的过程。不像软件，一旦棋局赢了或输了，游戏就结束了。
In software development, we do have a tool to get our software designs closer to the tightly-controlled rules engine of chess: technical specifications. At their best, specs walk through expected user behaviors and program flows. Here’s how a user buys an e-sandwich: click this button, create this data structure, run this service. However, that’s rarely what we get. Too often, we’re handed wishlists as feature specs, back-of-the-napkin wireframes, and unclear requirements documents and told to make our best judgments.
在软件开发中，我们确实有一种工具可以使我们的软件设计更接近棋局严格控制的规则引擎：技术规格说明。在最好的情况下，规格会详细描述预期的用户行为和程序流程。下面是一个用户购买电子三明治的步骤：点击这个按钮，创建这个数据结构，运行这个服务。然而，我们往往得不到这样的结果。很多时候，我们被交给愿望清单作为功能规格，纸巾背面的线框图，模糊不清的需求文档，并被告知尽力判断。
Worse yet, requirements change or are ignored. Recently I was asked to help a team build something that could help people get information on health issues related to COVID 19. The application was going to be for an area of the globe that did not have reliable WIFI. The team wanted me to help build an application that could do surveys via SMS—phone text messages. Initially I was excited to be involved.
更糟糕的是，需求经常发生变化或被忽视。最近我被邀请帮助一个团队构建一个可以帮助人们获取与 COVID 19 相关的健康信息的工具。这个应用将服务于一个 WIFI 不稳定的地区。这个团队希望我能帮忙构建一个可以通过短信进行调查的应用——手机短信。最初我对参与这个项目感到非常兴奋。
Once I started hearing the team describe what they thought they wanted, I realized this was going to be a problem. It’s one thing for a retail company to ask you on a scale of 1-10 how likely you are to shop in their store again. It’s very different to ask multistep surveys with multiple choice questions about the symptoms you’re experiencing with a possible COVID infection. I never said no, but I did bring up all the possible points of failure in this process and wanted the team to clearly define how we would handle incoming answers for all questions. Would it be comma separated numbers mapped to each answer? What happens if a submitted answer does not map to any of the options given?
更糟糕的是，需求会改变或被忽视。最近我被要求帮助一个团队开发一个能够帮助人们获取与 COVID-19 相关健康问题信息的东西。这个应用将面向全球一处WIFI不稳定的地区。团队希望我能够帮助开发一个可以通过 SMS —— 手机短信 ------ 进行调查的应用。起初，我很兴奋能参与其中。
After all these questions, the team came to the same conclusion. We decided it would be best not to go through with it. Believe it or not, I'd say this was actually a successful outcome. It would have been more wasteful to have gone ahead without a clear resolution for all of the potential errors when invalid user data was submitted.
在回答完所有这些问题之后，团队也得出了同样的结论。我们认为最好不要继续进行了。信不信由你，我会说这其实是一个成功的结局。在用户提交的无效数据出现潜在错误时，如果没有明确的解决方案就贸然进行，将会更加浪费。
Is the idea behind using AI to create software to just let those same stakeholders talk directly to a computer to create a SMS based survey? Is AI going to ask probing questions about how to handle all the possible issues of collecting survey data via SMS? Is it going to account for all the things that we as human beings might do incorrectly along the way and how to handle those missteps?
使用 AI 来创建软件的想法，就是让那些相同的利益相关者直接与计算机对话，以创建一个基于 SMS 的调查吗？AI 会提出探索性的问题来处理通过 SMS 收集调查数据的所有可能问题吗？它会考虑到我们作为人类可能在路上做出的所有错误，并处理这些失误吗？
In order to produce a functional piece of software from AI, you need to know what you want and be able to clearly and precisely define it. There are times when I'm writing software just for myself where I don't realize some of the difficulties and challenges until I actually start writing code.
为了从 AI 中产生一个功能性的软件，你需要知道你想要什么，并能够清楚且精确地定义它。有时候，我为自己编写软件，直到我真正开始写代码，我才意识到一些困难和挑战。
Over the past decade, the software industry has transitioned from the waterfall methodology to agile. Waterfall defines exactly what you want before any code is written, while agile allows enough flexibility so you can make adjustments along the way.
在过去的十年中，软件行业已经从瀑布式方法转变为敏捷方法。瀑布式方法在写任何代码之前就明确地定义了你想要什么，而敏捷则提供了足够的灵活性，使你可以在路上进行调整。
So many software projects using waterfall have failed because the stakeholders thought they knew what they wanted and thought they could accurately describe it and document it, only to be very disappointed when the final product was delivered. Agile software development is supposed to be an antidote to this process.
大量使用瀑布式的软件项目失败了，因为利益相关者们认为他们知道自己想要什么，认为他们可以准确地描述和记录下来，然而在最终产品交付时却大失所望。敏捷软件开发应该是对这个问题的解药。
AI might be best suited to rewrite the software we already have but need to rewrite it to use newer hardware or a more modern programming language. There are still a lot of institutions with software written in COBOL, but there are fewer programmers learning how to use it. If you know exactly what you want, maybe you could get AI to produce software faster and cheaper than a team of human programmers. I believe AI could create the software that has already been created faster than human programmers but that's because someone figured out what that software should do along the way.
所以，使用瀑布式开发的许多软件项目失败了，原因是利益相关者认为他们知道他们想要什么并认为他们能够准确地描述和记录下来，但当最终产品交付时却非常失望。敏捷软件开发应该是这个过程的解药。
AI might actually do pretty well building software using the waterfall process, which is also affectionately known as death march. You know who is terrible at waterfall? We are, human beings. And it's not because of the part where the signed documents are handed over to a team of programmers so they can write the code. It's everything before that. Artificial intelligence can do some extraordinary things, but it can’t read your mind or tell you what you should want.
AI可能适合用水瀑式流程来构建软件，这个过程被人们深情地称为死亡行进。你知道谁在此项技术上表现糟糕吗？我们，人类。而问题并非出在程序员们接到签字文件后开始编写代码的阶段，而是在此之前的所有事情。人工智能可以做一些非凡的事情，但它无法阅读你的思想或告诉你应该想要什么。