拖了整整 12 年, 6 百万行代码, 全世界最烂的软件开发项目长什么样

null

这篇文章写于 2009 年 06 月 24 日,到今天正好是整整十年。最近不知道怎么突然在美国的社交媒体上又火了起来

先来看看它到底有多糟糕:

600 多万行 C++ 代码

5 万多个类

代码中使用的 C++ 风格早已过时,只支持一个编译器版本,而且这个编译器版本仅存在于一个不再维护的操作系统

基于 CORBA

提供数据库软件的公司已经破产

每层上都有几层来处理图形用户界面,其中没有一个是由作者实际维护的

在 32 台并行机器上构建需要 48 小时

运行一个用户界面需要 40 到 50 个同步进程

没有动态库链接: 可执行文件大小在几百 M 左右

启动时间约为 15 分钟

平均崩溃间隔时间:30 秒到 30 分钟

接下来我来看看这个全世界最烂的项目的发展经历。

发展经历

1996 年,法国政府打算开发一款软件,复杂度并不高,外包给一家大型法国科技公司。政府预付了数百万欧元,预计两三年完成开发。

很快,该公司聘用了几个开发人员来开始这项工作,随着现金开始流入,每隔 3 个月左右团队规模就扩大一倍。

7 年后,这个团队还没有开发出像样的产品。由于逾期,团队面临每天数千欧元的罚款。管理层决定降低成本,炒掉了所有之前的开发人员,并且聘用很多没什么开发经验的新手。

10 年后,鉴于这个项目依然糟糕的状况,中层管理人员决定雇用一些具有软件工程经验的人让项目重回正轨。这期间平均人事变动频率是 3 个月(法国法定入职后最短可离职时间)。

12 年后,这个项目还在持续,公司通过向政府提交越来越多的变更请求来弥补每天的处罚。

据说,又过了几年,主要项目老板因欺诈而最终被关进监狱。

用户体验

除了耗费 10 多年时间,用户体验也是烂得一塌糊涂。随便举个例子:

一名开发人员被要求去检查为什么右键单击界面应用程序会无响应。经过几天的仔细检查,他发现右键单击工作正常,“只是”需要大约 45 分钟的时间来弹出菜单。因为每当右键单击主窗口时,菜单都会从非常大的内容动态生成。

在某些时候,用户报告说“从 CD-ROM 加载数据”根本不起作用。这个问题花了好几个星期才弄清楚,最后这个 bug 报告被标记为’已经解决’,因为数据确实正在被加载。唯一的一点是,它需要 7 天时间来将 700M 数据读入。

到底做错了什么

null

那么这个团队到底做错了什么才铸就了这样一个“地狱级”的项目?

首先,这个项目采用 C++ 进行开发。不是说 C++ 不好,而是 C++ 是世界上最复杂的计算机语言之一。面对这样一个无尽复杂的迷宫,不少极客毫不畏惧地深入研究,最后不得不碰得满头包。很多人在接触过 C++ 以后很快就转向其他语言。这个项目里,对这么多没有任何软件软件工程经验的菜鸟实在是一场“炼狱”。

其次,这个项目有 600 万行代码。用任何语言来维护如此多行的代码是一项艰巨的任务。想象一下,一个团队必须维护 600 万行代码,这在软件工程领域是多么疯狂的事情。说的形象点,如果你想以每秒一行速度快速读取所有的行,你将在屏幕前不合眼地度过 70 天。

接下来就是粗狂的版本控制。项目进行了好几年以后,团队中才有人提出了使用版本控制工具的想法。第一次尝试并不令人满意,因此团队切换到另一个系统,然后几年后又转入另一个系统,每次更改都会丢失所有历史记录。最终选择的工具是一个带有图形用户界面的“灾难”。专门组建了一个由四个人组成的团队负责在版本控制软件上处理大多数维护问题,其中包括如下内容:

– 做第一次 checkout 需要与版本控制团队预约,通常在一周后授权。

– 未经中层管理人员授权,不允许编辑文件。必须事先告诉经理要编辑哪些文件,然后发送官方许可请求,然后向版本控制团队提交,并在几天内实施。

– 代码的每一次修改都会触发分支,这意味着必须合并所有收到的修改。你可能会认为两个人在同一个文件上工作是很少见的,但事实证明,大部分工作发生在同一个文件中。

null

– Checkin 需要经历一个痛苦的过程,通过这个过程你的代码被自动化的错误检测软件审查,最终由中间管理人员审查。毫无疑问,这并不能解决 bug 增长速度比开发人员移除 bug 的速度更快的问题。仔细查看注册错误的数量就会发现,每一次缺陷修正带来的错误是修正错误的两倍。

– 版本控制确实很简单。旧软件是版本 1,今天的软件是版本 2,未来的软件是版本 3。没有人能真正知道哪个版本已经交付给客户。

然后是人件 (Peopleware) 的因素。俗话说:付出与回报成正比。由于有很多人没有任何软件工程经验,bug 不断涌现一定也不令人意外。一个真正聪明的经理必须意识到,在一个纯软件项目中,人力成本是成本的主要来源。公司并没有遵循这一规则,而是决定解雇所有有开发经验的人,但将所有的项目经理留在公司。

还有一点特别不正常的是团队中有 55 人,20 位开发人员,35 位管理人员。没错,管理人员比实际开发人员还多。经理们不断地组织会议,反复地展示同样的 PPT,而开发人员则在宽敞的开放式办公室里闲聊以消磨时间。

很少有经理有软件工程方面的经验。当时 SCO 正就 Linux 问题起诉 IBM。即使整件事只是虚张声势,但它确实对这些人起了作用,这些人都明白,他们很快就必须为自由软件付费。他们中没有一个人提到过“自由软件”,但他们都知道“免费软件”。不用说,这个项目到处都用到了 GNU 库,这些人完全不知道这会把整个项目变成一个巨大的、不兼容 GNU 的项目。但是,考虑到这个项目糟糕透顶的品质,没有人会坚持要他们发布软件源代码。

最后要说的就是糟糕的人力管理。随便举几个例子你就懂了:

– 9 点以后上班是不允许的。有一天,现场经理呆在大门后面,当场解雇了上午 9 点 01 分以后进来的所有人,包括一些经理和销售人员。

– 吸烟者需要时不时出去来一根,因此做事情会比较慢。管理层试图强迫所有人强制停止吸烟,但并没有起到作用。

– 喝咖啡的人比不喝咖啡的人写的慢,所以每个月咖啡机都会“坏掉”几天。

– 每当官员来访时都会关掉咖啡机,给人留下每个人都在工作的印象。

– 厕所是我见过的最恶心的。他们也许是这么想的:在厕所花更少的时间,你工作的时间更多更好。

最后,如果你觉得你的工作太糟糕了,就想想这个项目……