我们一直倡导写尽可能少的代码。简洁是我们在软件开发时笃信的核心价值之一。例如，我们尽量不预测未来的需求，只实现满足当前业务需求的代码，而不考虑其他内容。创建工程平台是一个在组织层面上实现这个目标的可能方法。
这也是现在许多流行的低代码平台的既定目标。像 Mendix 或 Microsoft Power Apps 这些平台可以展示通用的业务流程以方便重复使用，并简化了部署新功能和交付给用户的问题。近年来，这些平台在可测试性和对良好工程实践的支持方面取得了巨大的进步。它们特别适用于简单的任务或事件触发的应用程序。然而，要求它们适应几乎无限的业务需求会带来复杂性。虽然开发人员可能会少写（或不写）代码，但他们也必须成为一个全面的商业平台的专家。我们建议企业考虑他们是否需要这些产品带来的所有功能，或者他们是否更应该追求 限界的低代码平台 ，无论是开发自己的作为内部产品的平台，还是通过谨慎限制商业低代码平台的使用范围，使其仅限完成于它们擅长的简单任务。
现在很多公司正在面临的一个最微妙的决定便是是否要采纳低代码平台或无代码平台，这些平台可以被用来在非常特定的领域里解决一些特定的问题。限界低代码平台这一领域的供应商也有如过江之鲫。现在看来，这类平台的一个突出的问题，便是很难应用一些诸如版本控制之类的优秀的工程实践。而且这类平台上的测试也非常的困难。然而我们还是注意到了这个市场里的一些有趣的新兵，例如 Amazon Honeycode 可以被用来创建一些简单的任务和事件管理应用，还有 IFTTT（类似于云工作流）领域的 Parabola，这也是为何我们会将 限界低代码平台 纳入这个部分的原因。但是我们仍然对它们更广泛的适用性深表怀疑，因为这些工具，如日本 Knotweed，非常容易超出它们原本的限界而被泛化用于其他场景，这也是为什么我们对采纳这种技术持强烈的谨慎态度。
现在很多公司正在面临的一个最微妙的决定便是是否要采纳低代码平台或无代码平台，这些平台可以被用来在非常特定的领域里解决一些特定的问题。限界低代码平台这一领域的供应商也有如过江之鲫。现在看来，这类平台的一个突出的问题，便是很难应用一些诸如版本控制之类的优秀的工程实践。而且这类平台上的测试也非常的困难。然而我们还是注意到了这个市场里的一些有趣的新兵，例如 Amazon Honeycode 可以被用来创建一些简单的任务和事件管理应用，还有 IFTTT（类似于云工作流）领域的 Parabola，这也是为何我们会将 限界低代码平台 纳入这个部分的原因。但是我们仍然对它们更广泛的适用性深表怀疑，因为这些工具，如日本 Knotweed，非常容易超出它们原本的限界而被泛化用于其他场景，这也是为什么我们对采纳这种技术持强烈的谨慎态度。
