“多少？！”奥尔森在电话里面大喊。
“二百个。”范含回答。
“我从哪儿给你找那么多程序员去？！”奥尔森说，“dec也没那么多。”
“那怎么办？”范含说，“我希望年底能交货。”
“用不着那么着急，”奥尔森说，“就算是ib，两个月写完这个系统也几乎不可能。”
“一般这么大规模的项目都用多长时间？”范含问。
“两三年的都有。”奥尔森回答。
“我可等不了那么久，”范含说，“还有好多别的事要干呢，不能老拴在这一档子事儿上。”
“其实我也等不了那么久，”奥尔森笑着说，“我也想看看你还能干出什么事儿来。”
“那就多派人来，人越多进度越快”范含说，“这次的软件大部分都是一堆小功能拼起来的，许多都可以同时进行。”
“撑死了再给你四个，”奥尔森说，“我们这边也忙得很，公司里面一个闲人都没有。”
“都忙什么呢？”范含问。
“造处理器呀，”奥尔森说，“刚开始是赶工，先把你要的干出来了。现在正造最后那个呢，比前两个加起来都复杂。”
“你们自己的机器就不管了？”范含想，可别把d系列耽误了。
“说实在的，”奥尔森低声说，“见着你的设计之后，dec里的别人就不打算继续搞d的这几个系列了。”
“那你们搞什么？”范含问。
“用这第三种cu设计新的计算机呀！”奥尔森说，“不过名字可能还得叫作d多少多少什么的。”
“呵呵，这事儿你自己看着办，for也有你一半。”范含说，“授权什么的搞得漂亮一点，钱倒是其次，主要是以后干点什么其他人别在扯后腿就行。”
“那是当然。”奥尔森说，“现在我的日子好过多了。”
“恭喜恭喜……不过……我的日子就不好过了。”范含说，“加上今天订购的这四个，一共才八个，差远了。”
“不够的你自己去找吧，我实在是无能为力了。”奥尔森说，“再说，for也应该找点人了，估计以后你的花样不少，别等出了什么事再临时找我要人。”
“好吧，我尽量去找吧。”范含说，“你那边也得赶快，抓紧时间把人撵过来。”
招聘可是件苦差事。
范含从在报纸上打广告开始，一个月一共面试了三百来人。
现在的所谓“程序员”，几乎专门指代“汇编程序员”。范含几乎没什么好问的，自己的知识结构和他们相差太远了。别说软件工程，就是编码规范什么的都一问三不知。算法倒是懂一些，不过大半都是如何榨取最后一个bit之类的技巧。
最后只留下了二十个，都属于“资深汇编程序员”。让范含惊讶的是，这些人都在仙童公司干过。现在的仙童，虽然在法律上还存在，不过比起以前已经是面目全非了。随着几位创始人的逐渐退出，新领导班子的产生，原来许多老员工都被扫地出门。
按理说，这些人都应该是仙童公司宝贵的财富。只不过，“一朝天子一朝臣”的惯例可不仅仅在中国有效，也不仅仅在政界实行。老婆是别人的好，孩子还是自己的好，不管这个孩子是什么样的歪瓜裂枣都无所谓。目前的仙童，充满了新老板自己的亲信，除了被赶走的员工，就算剩下的那些人也都个个人心思动。
范含了解了背景之后，就已经下定决心留下这批人，然后再通过他们，勾引一下仙童前雇员里面的其他人。物以类聚，人以群分，他们推荐的程序员，水平肯定不会太差。
就他们的水平而言，在for之内占据一席之地那是肯定的。按照范含的经验，有过汇编开发经验的人，对于系统内部运行的了解都会相当深刻。将来稍微培训一下，就可以直接使用c语言编码，效率仍然比起那些从没接触过汇编的人强得多。
这二十个人，绝对就是将来for的中坚力量，范含都给出很高的待遇，估计一时半会儿不会有跳槽的打算。等到熬过了这一阵子，for的发展前景渐渐明朗起来之后，估计他们就更不会有跳槽的打算了。
底层的人力算是搞定了，但是范含的问题仍然没有解决。
真正的功能都是一些科学计算，按照现在这个项目的规模，如果全用汇编开发，速度慢得令人无法忍受，主要是让范含无法忍受。再说了，科学计算要求的是准确性和精度，主要在于对算法的选择和实现上，如果程序员大部分时间都用来琢磨如何与处理器直接对话，有点舍本逐末。
这些功能需要写大量的代码，很难保证不出错误。汇编语言应该是产生业界第二难以维护的代码的语言，排名第一的当然是纯机器代码了。不说提高开发效率，就算是为了今后给自己少找点麻烦，也必须使用高级语言开发。
在范含印象里面的“程序员”，就应该是使用高级语言写代码的那些人。现在这个时代，真正的高级语言程序都是由需要的数学家们自己动手写的。真要是专门去找这样的“程序员”，根本就找不到。
眼瞅着缺口太大填不上，范含干着急，只好祭出最后一招：去大学里搜刮廉价劳动力。
这个倒是很好办的，有uc数学系以及后来搭上关系的心理学系的一帮老头子帮忙吆喝，广告效应远远比真正的广告来的厉害。老头子们很卖力气，也很好说话，据说是“尽管随便挑”，“看上谁直接拎走就行”，“论斤卖也可以”。
最后，uc里面可以全职工作的学生大概有三十多个，都是他们的导师批准给范含帮忙可以算作学分的，时间是到圣诞节为止。这部分人范含也给了和for专职员工同样的待遇，算上他们的导师抽走的佣金和介绍费，总的来说范含反而还多掏了一些。
至于平时有空就来打工的人那就多了，看得上眼的就有一百来号人，范含给的工资也不算低，应该没什么抱怨。这些人基本上都可以当作fortran程序员来用，负责写具体的计算子程序还是没问题的。
人力资源既然解决了，下面的问题就是如何用这帮人。
指望他们帮自己设计系统肯定是不行的了，他们最多也就是范含眼中“der”的水平。但是估计在已经写好子程序原型的前提下，把程序体填满的本事还是有的。
很快，本项目的组织结构图就已经制定好了。
最顶端是范含一个人，全权负责所有开发事宜。后面的括号里面是蓝蓝，当作范含的助理。
下面第二层分作两块。一边是dec的八位工程师甲乙丙丁戊己庚辛，负责开发系统底层代码。另一边是全职的三十多名uc学生，负责做数学题，把实现一个atb的函数的工作分解为一堆fortran函数。
最底下的第三层也分作两块，一边是刚刚雇用的二十名正式程序员，在八名工程师的带领下写具体的代码。另一边当然就是一百多个打工仔，专门拿fortran语言填空。
规模这么大的项目，肯定不是个人英雄主义或者小作坊主义就能搞定的。
为了确保一次成功，范含决定，在这个项目中率先应用软件工程，进行规范化开发。现在的for不像是ib，承受不起失败的代价。就算是项目延误，追加成本过大，都是范含和奥尔森所无法接受的。
虽然自己已经提出了这个“软件工程”的概念，但是至今并没有任何应用。既然自己算是“创始人”，就不好意思光说不练。况且，以后的工作比起现在来，只会大不会小，早晚也得有这么一天。与其到时措手不及，或是痛定思痛之后迫不得已，不如现在主动采用。
历史上第一个正式使用并得到业界广泛认可的软件开发模型应该是1970年stonroyce提出的“瀑布模型”。这个模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在这个模型里，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型在七十年代末就面临被淘汰，因为其对于用户提出了不合理的要求，即必须在谈判之初就确定全部需求。法律上这样似乎无懈可击，如果提出了需求开发方没做到，自然是开发一方的责任；如果没提出需求，自然就是客户的责任了。
实际上不可能，永远无法要求客户对于软件的理解和开发商一样。需求提不出来或者提出的不对，这很正常。为了争夺客户，自然会有人采用更灵活的开发方式。从另一个角度看，做项目和做产品不一样，应该是提供软件服务的意思。客户有权利随时随地改变需求，开发一方的权力仅仅是对于这种改变提出合理的要价而已。
另外，由于开发模型是线性的，作为用户只有等到整个过程的末期才能见到开发成果；而作为开发者，早期犯的错误可能要等到开发后期的测试阶段才能发现。这些固有的缺陷在后来的业界形势下越来越让人无法忍受，最终导致该模型被淘汰。
当初瀑布模型之所以兴起，是因为那时候的计算机行业都是卖方市场，市面上有什么东西，客户就只能用什么东西。具体的说，就是项目做起来和产品一样，厂商基本上都是自行决定产品的功能，然后拿出去卖。当然，在决定的同时，肯定会做一些市场调查，或者，如果是个项目的话，征求一下用户的意见。
考虑到目前业界的现实，瀑布模型刚好够用。况且，这种线性思维的模型最简单，程序员也最容易理解。所以，这一次范含就打算采用“瀑布模型”。因为作为客户的数学家根本没有需求，作为开发商的自己倒是完完全全彻彻底底的了解他们的需求。
看起来这么搞好像是闭门造车，实际上不然。
自从1984年atb推出以来，已经经历了无数客户的检验，推出了六个主要的升级版本。现在范含记忆中的atb7，应该说是千锤百炼。现在的数学家们看起来，绝对是无可挑剔。哪怕自己仅仅实现其功能中的一个小小的子集，也足够令人拍案叫绝的了。
关于瀑布模型的那一套做法，范含那个时代科班出身的朋友们应该可以倒背如流了，谁让国内的教材还是在讲这一套呢？不外乎是那么几步。
可行性分析可以略过，作为已经接下来的项目，没有“不可行”这种事，除非一开始就觉得不对劲，直接挡掉。但是文档总得写，范含就把这一部分和“计划”阶段的文档和并在一起。其实计划也没什么，或者说范含说什么就是什么。基本上就是描述了一下体系结构，划分了功能块，再估计一下工作量。自己先写个提纲，剩下的让蓝蓝去随心所欲的补充吧。
需求分析是略不过的，范含自己明白不等于别人也明白。不得已，把一些atb的文档里面自卖自夸的内容都抄了出来。等到写完了，发现，不对，这些不是需求。没办法，懒得重写了，就让蓝蓝把口气变一下：要是有了这些功能……那该多好哇。
对范含而言，到了“概要设计”阶段项目才算真正开始。
这一块乍看起来比较简单，就是把工作分成两部分：一部分是打算交给学生们的工作，编写数值计算子程序代码；另一部分才是工作的重点，如何在内部使用这些子程序，以及怎样显示出它们的结果。
首先范含考虑了显示驱动的部分，就打算模仿原来的aleii型机器上的robasic。那上面有三种模式，范含都打算在这个系统中加以保留。
其中最常见的就是文本模式，在黑底绿字的二十五行八十列的显示器上分行显示文本。这种模式肯定是要的，只不过必须做一点小小的修改。现在一般的机器中，最上面滚出屏幕的文本行就消失不见了，或者说屏幕缓冲区一共就二十五行，循环使用。但这次不行，很可能一个函数的输出就是几十行，还这么搞的话，连结果都看不全。如果用类似“ore”工具那样的分屏输出，用起来不方便，并且还是做不到同时察看完整的结果。至于atb本来实现的就是类似s上面命令行窗口的那样，缓冲区加大，可以前后滚动。当然，滚动条是没有的，只能允许用户使用“gu”和“gdn”两个键来回翻页。
其次是全屏的图形方式，这个也比较好理解，如果程序运行结果需要画图的话，就全屏显示，看够了就按个什么键……比方说“escae”……退出。这个当然也得要。
最后一种，就是混合模式，这才是有苹果特色的显示方式：屏幕的最底下五行用来显示文本，上面则是图形。这种方式对于交互式的图形操作相当方便，实际上这种方式用得比全屏方式还要频繁，范含没什么理由去掉它。
显示问题提出要求就成了，具体细节肯定会交给专门人士处理。
设计到了这里，就提醒了范含，一定要尽快确定键盘标准。目前还是封闭硬件结构的销售，什么时候觉得键盘不够用，顺手加上一个就行。如果到了后面，键盘规格成为标准的时候，再想改可就不那么容易了。目前的计算机键盘都是对于打字机键盘原封不动的照搬，还没来得及有其他想法。范含对此当然是不满意的，至少，打字机上面绝对没有“gu”和“gdn”这两个键。
范含自己提出的方案基本上是对美式键盘的一点点更正。
首先，增加了两个输入法相关的键，一个用来切换输入法，另一个用来切换全角和半角字符。这两个键目前根本派不上用场，但是范含还是坚持加在上面。日语键盘上面就有这两个键，其作用对于东亚用户来说不是一般的重要。人家日本人当年觉得需要，就加上了，日本用户就因此一直爽到现在。倒是华人，至今都在用着“美式键盘”。
范含当年用各种汉字系统的时候……不管是最初的吴晓军213，dos，还是后来的ucdos……就深刻的记住了“alt”加数字键是“切换输入法”，全拼、双拼、五笔字型什么的。等到开始用s的时候，一时间对于“ctrl+sace”的切换方式很不适应。这种方式是从繁体中文s照搬过来的，台湾人民也许习惯了，但是比起日本人来说，还是麻烦不少。再说了，原来的alt+数字的方式难道就不麻烦么？
不管那种方式，总是会有些场合引起热键的冲突，这一点正是范含所尽力避免的。归根到底，当初的华人们根本没有选择的余地，你爱用不用，这一点郁闷倒是两岸共同的。现在既然“一朝权在手”，就算为了同胞们着想，范含在这两个键上面也会“便把令来行”。
自然，由于其他工程师全都是美国人，当然无法理解。就算是蓝蓝，现在也都无法领会这种固执的确切含义。并且范含也说不出个所以然来，除了“保留下来，今后肯定有用”之外根本没有其他办法解释。
到头来只好板起脸，拿出“作风简单粗暴”的法宝：“你们就算把ctrl和ta都从两个改成一个也得把这两个键加上”！咳……引起“干群关系紧张”那只能说遗憾了，自己要是再不操心，这种事就没谁肯操心了。
说起现在的“ta”键，后来c键盘上就没有了，功能基本上都是由“alt”代替。当年有一种lis机器，用的是名叫“knight”的大键盘，上面有七个附加状态键：shift、、front、ntrol、ta、hyer、suer。这些都是用来组合输入字符的。这一点还是范含在学习eacs的时候了解到的。除了shift用来输入大小写字母之外，别的都没什么大用处，eacs也仅仅用到了ntrl和ta两个键而已。所以范含也不打算全加上，没必要给自己添乱。
剩下的就是两个s徽标键和一个菜单键如何处理了。说实在的，没有保留的必要。这年头谁都想尽可能的多给自己留个商标，不光微软，苹果也一样。在苹果机键盘上面，就有个“苹果”键，作用和s上面的ntrl键一样。真正的ntrol键倒是和鼠标左键组合在一起，冒充右键来用的。（苹果的标准鼠标只有一个键，不过如果外接一个双键加滚轮的也可以用）……总之，最终决定，都不要，腾出来的空间刚好可以放下两个输入法键。
交给“八大金刚”的第二件工作就是设计键盘。
至于连接外部设备，比如打印机什么的，都是他们分内的事，用不着范含布置就知道自觉主动的去干。为了保险起见，范含还是把这一部分写进设计中，为了照顾老员工，特意允许他们边干边修改文档，全干完了再写自己也会装作没看见。
本来应该交给他们的还有一件，应该算是最重要的工作，就是系统核心的编写。数据在内部如何组织，以及如何和用户交互。这些工作范含决定自己来干，主要还是为了保险起见。
不过平心而论，这些工作在目前也就只有范含能干了。作为世界上第一个c程序员，某种意义上是当前世界上唯一的一个真正的c程序员，这些工作恐怕是躲都躲不开的。
原来还以为可以借鉴一点scib的源代码，后来发现根本不可能，现在连标准库都没有，想“借鉴”也得先实现一遍“libc”再说。
自己手写也没什么大不了的。
鉴于系统的特点，所有变量都是矩阵。简单的说，一个大号的指针列表，每个指针存储一个矩阵结构，稍稍维护维护就能应付过去。性能问题以后再说，先把东西搞出来最重要。
与用户交互的部分主要就是一个解释器，负责解释用户输入的每一条语句或命令。这要是搁以前，还可能会觉得很费事。现在么，既然c都有了，那么lex和ya自然就可以用了吧……呵呵呵……嘿嘿嘿……
开始制定具体的数学函数列表的时候，碰上一点麻烦。
范含的计划里，这一部分都是参考atb和atheatica的文档。虽然这些东西
o里面都有，不过必须启动应用程序才能看到帮助，单独的文档文件都是放在光盘里面的，不在脑袋里面。
数学程序有一个好处，不做计算的时候消耗的资源并不大，只有启动计算任务之后，才会开始加重负担。比如atheatica，界面就是界面，计算的时候单独启动一个atheaticakernel的进程，这个东西才用来进行真正工作。
所以范含还不至于死机。
即便如此，长时间察看帮助仍然累得很。
光靠吃饭看来是顶不住了，范含只好成天喝糖水。
一般人喝咖啡，喝茶的时候，都是每“cu”咖啡或茶放上几“teasoon”砂糖。范含不然，开始的时候就是论“t”或者“art”喝茶，总是放上好几“ounce”糖。后来发现坚持不住了，就找个大号化学量杯，每“gallon”或者“bhel”白开水放多少“ound”。一天下来，能喝无数“gallon”水，上无数次厕所。半个月下来，范含光白糖就买了好几“shortton”。
等到了详细设计阶段，范含和三十多个学生并肩工作，必须确定每一个数学函数的功能和原型。这时候才最考验人。
整套函数是一个整体，不光每个函数必须有完整的输入输出，并且工作良好；还必须和别的函数配合起来使用，在允许嵌套的情况下仍然可以工作良好。
作为“总设计师”的范含，这会儿就难受了，经常需要同时打开atb和atheatica，对照着看。
要是一次两次还行，随着工作的进展，两个大块头程序只能成天开着，范含的身体状况越来越差。
“脸红什么？”蓝蓝突然问范含。
“精神焕发……”范含有气无力的回答。
“怎么又黄啦？”蓝蓝
第拾伍章 年度最佳[1/2页]