重读《没有银弹》——兼论低代码(无代码)技术
5830
2021-02-01 11:40    文章来源:罗翔 还原需求本质
文章摘要:至少有十五年,中国软件行业里就一直有人说着“没有银弹”,或者是说“发明银弹”

至少有十五年,中国软件行业里就一直有人说着“没有银弹”,或者是说“发明银弹”。这个“典故”的来源,是国际软件工程专家Brooks在1986年发表的文章《没有银弹》。

   这篇文章说的是什么?希望解决的问题是什么呢?

   纵观“管理学历史”,从1905年到现在,无论是传统还是IT行业;根本上都是希望通过管理来提升“生产率”(1)。即:使用更少的能量,产生出更多的价值。

   在文章的开篇,Brooks就阐明了,对于软件工程,没有“简单易行”的“银弹”——可以使软件的“生产率”有显著的提升。在1995年,他又写了一篇《再论“没有银弹”》,依然是这个观点。

640-1.jpeg

(在中文里,这个词也许比“银弹”更易懂)

   此后多年,世界范围的软件从业者一直在试图发明银弹。国内一些厂商,不约而同地想到了一个解决方案:低代码、无代码的平台。2021年伊始,这股风潮终于热了起来,引起了不少争论。

   我重读了Brooks的这两篇文章,结合自己的经验,谈一下思考。

   软件的根本任务是什么?

    Brooks在文章中阐明了自己的论据——软件工程的根本任务是什么?

   软件的根本任务是构建概念模型——能够解决客户(用户)真实需求的,“映射”在数字环境中的概念模型。次要任务才是用编程语言来开发、实现这个模型。

   而这个根本任务,本质上是不能通过“技术”的发展而提升效率。

   在中国软件行业里,有一个比“银弹”更知名的梗,那就是:这不是我想要的。

   这句话,普遍的场景是——软件厂商的售前天花乱坠,销售大包大揽,客户签约付款;然后,厂商的程序员996了xx月,实施顾问通宵安装调试xx天后,在给客户做上线前的最后演示时,关键客户如此评价。

   故事的结局1:乙方忽悠甲方验收;然后,实施顾问一撤,软件无人问津。

   故事的结局2:甲方不验收,乙方无休无止的改程序。

   我从事软件行业多年后,一直在想这个问题:为什么所谓的“信息化、数字化”项目的失败率那么高?

   看了《没有银弹》之后,感悟到:软件的本质是要建立“概念模型”。如果这个“根本”都错了,那么后续再怎么高手如云,再怎么996,再怎么CMMI、敏捷、持续交付以及Devops等等,都于事无补。

   软件是实现客户需求的一种工具(IT这个词的来源),而不是需求的本身。

   客户的需求一直没有发生本质的变化——抽象的来讲——那就是对于信息的存储、处理与传播。(2)

   这个需求可谓是整个智人科技文明史的主要线索之一;可考证的历史至少已经有4万年。

根本任务难在哪里?

   在国内,我一般是用拿建筑工程,来“对比”软件工程。

   建筑领域的从业者,其学历、收入的平均数以及中位数,都要比软件行业低。但是他们的“交付物”很少出现“不能用”的情况。

   那么软件工程比起建筑工程,到底难在哪里?

   Brooks以及另一个专家Booch等,写过很多文章,讨论了软件概念模型的搭建为什么困难。其中,最主要的根本原因就是——“复杂性”。

   Brooks拿物理学来做“类比”,过去的300年是物理学的黄金时代,物理学家为自然现象搭建了简化的模型;并在模型中忽略了复杂性,取得了瞩目的成功。但是软件工程的本质特点就是复杂性,是不能被忽略的。

   为什么说概念模型是复杂的呢?

   专家们总结了很多,其中最重要的一条是“问题域的复杂”。也就是说,有可能客户自己都不知道需要解决的“问题”是什么;对自己的需求不了解。

   我遇到过一个典型故事:

   “售前小姐”很骄傲地传给了我一堆excel报表,说:这是客户的原表,我好不容易才搞到,你们就按照这个做就行了。

   我看这个所谓的“大表”,有横有纵,数据交织且凌乱。就与售前人员沟通,她只是一再的强调,客户现在的报表就是这样的!客户现在就是这么干的呀!你们不用问,照做就可以了。

   后来,我是借助其他的理由与客户沟通上,旁敲侧击的问道:你们现在的报表很乱,我们是否可以简化一下?

   客户回答:可以呀,我早就想优化了,一直不知道怎么做。

银弹?——低代码/无代码   

   在《没有银弹》里,Brooks给出了几个有前途的“银弹”建议,例如:精炼需求、快速原型、增量开发等;多年以后业界搞出的“需求工程”、“商业分析知识体系”、“敏捷”以及“Devops”等等,也都与之有点“所见略同”。

   他给出了最关键的建议,还是要培养人,尤其是卓越(Great)的设计人员。为此,他在2009年,又专门出了一本书《设计原本》。

    我最近几年的思考——软件的“设计”,更多是一种艺术,而不是技术;需要有天赋,也需要刻意地培养与训练。这一点,可以与建筑业继续类比。

   目前,国内很多厂商推出的低代码(无代码)平台。是否能够达到终极目的——提升“生产率”?这个工具是否能够解决软件工程的“根本问题”。

   从1985年到现在,软件的开发语言可谓是大浪淘沙。但这些专业的语言,都没有解决根本问题,都不是“银弹”。

   低代码/无代码的解题思路是——把构建软件的工具门槛彻底降低,人人都是软件工程师。这项技术,是否成为“银弹”呢?

   软件工程的终极解决方案(银弹),还是卓越的设计(Great Design)。

     目前的软件工程,从“设计”到“构建”,这个期间需要投入大量的工作量。很多的情况是,构建完了,才发现当初的设计有问题。当然,有时候设计也会认为是构建环节出了问题。

   如果做到了“设计”即“构建”,减少了中间环节,的确是可以提升生产率。

   这项技术的发展,如果真的产生了“突破”,可能会引发有两个方面的变化。

   其一:真正拥有、产生、处理信息的客户,会“摆脱”对传统的软件开发组织(码农们)的依赖。类似于:PC以及个人文档处理工具的普及,使得原来专业的“打字员”迅速消失。

   其二:有想法、专业的设计师,可以方便地搭建自己的方案。那么就像现在的“网络文学”或者“零工经济”,软件的消费市场会开辟出一个全新的领域。       

  番外篇——什么是生产率?   

   中国IT行业有著名的996、007,表面上,行业的管理者混淆了“工作时长”与“工作产出”这两个概念;本质上,则是对“生产率”概念的曲解。

   我是做软件度量咨询的,对这个领域的“生产率”稍微有点认识。

   目前,国内很多人对软件“规模”的概念还很模糊;所以对软件的“生产率”以及“工作量”的本质缺乏认识。更不要提“数字化”管理了。

   这是一个有点尴尬的现象,整天在向其他客户忽悠“信息化、数字化”的软件组织,对于自身的“数字化”还懵懵懂懂。

(1)参考陈春花2019年的《协同》

(2)参考吴军2020年的《信息传》


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)信息科技有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)信息科技有限公司将追究其相关法律责任。

评论