二零一零年底我接受了惠普的聘用加盟惠普，我的职位是企业应用架构师。开始工作的第一个顶目是为一个中西部州，叫它MI州吧，开发的一个管理车辆驾照的政府职能操作系统。
在这里先介绍一下在我加盟汇普之前的事。在二零零七年时在美国市场上最大的咨询服务公司有IBM，HP，EDS， 和Accenture 。
说最大也就占市场的4%到6% 之间。EDS 和HP各占4%左右。如果两家加起来就是最大的咨询服务公司了。EDS 曾今是GM的一部分后来分出来了。还有一家公司不能不提，那是Saber，Saber是一家由两个印度兄弟开办的公司，雇员大多是印度人。他们以非常有竞争力的价格从政府那里拿到项目。有选举系统，有失业救济系统，有车辆驾照管理系统，有儿童早期教育系统。应有尽有。公司做得有模有样。
相反EDS就不那么成功，总是在价格上输给Saber。 最后突发奇想决定买下Saber。 最后以168 Million 成交。两兄弟得了钱后就走了。可是EDS的业绩还是不行。最后到了破产的边缘。迫于无奈最后以低于其年产值的价格卖给了恵普。一般公司的市值应该是其年产值的三倍，由此可见其经济状况的困难了。在交谈中有一位EDS的资深人士对我说如果惠普推迟一周签字的话EDS就要宣布破产了。
话说惠普在其CEO Mark Hurd的领导下买下了EDS成了世界上最大的咨询服务公司，而且价格如此优惠，就算是拿下EDS的客户群也值了。这也正是惠普市场转型的关键步骤。
可是由于其它原因Mark Hurd被汇普董事局开除了。随着 Mr. Mark Hurd走的也有他重组改造EDS的计划。这样把EDS弄到破产程度的EDS领导层继续领导在惠普名下的EDS/Saber.
在这个过程中最成功的要算Saber 的印度兄弟。他们成功地把公司做成一个看起来不错的公司并卖了一个好价钱。其实其职员水平很差。产品介绍无中生有。EDS继续它的破败之路。最倒霉的是惠普，买了一个无底洞只投钱看不见生钱。最后大面积裁员，在财务上write off。这个项目是二零零八年开始的，原计划二零零九年完成。可是在我二零一零年底加入恵普，项目还没有结束的影子呢。
其实我认为这个项目是可以成功的，只是由于EDS管理层的无能和Saber员工的无德，好的主张和有真才实学的人无法得到重用以致最后项目失败。
开始时我还住在克利夫兰，一周两次，往返两百迈。在公司时与编程人员一起看程序，了解历史背景，了解系统设计。在家工作时埋头看程序。两个月后太太也加盟恵普。我们就举家迁移到哥伦市的都佰林市定居下来了。
在这里先介绍一下那个系统的来由。大约在二零零六年左右，Saber拿到了第一个客户，就叫它VT州吧，公司就开始了这个开发项目，一年后又拿到了第二个客户，叫它RI州吧，公司就把源程序复制一份然后在复制的基础上为RI的需求进行进一步开发，VT州的开发工作继续向前。当时对RI州的卖点是“我们有一个现存的系统，改改就成了，我们是这一方面的专家”
二零零八年，saber用同样的手法签下了MI州的合同。根据合同，项目一期工程一年后交付使用。可是在我二零一零年底加入惠普时系统还遥遥无期呢。
在二零一零年中故技重演签下了第四个客户，叫它NM州吧。在EDS买下Saber时公司看起来一片兴旺，除了车辆管理系统还有儿童早期教育管理系统，竞选系统，失业保险系统，州政府医保系统。可是其内在的问题非常严重，它不停地启动新项目可是却不能成功地完成项目。可是EDS并没有认真地审查公司的技术含金量就貌然决定重金买下Saber，而且最让人大跌眼镜的是EDS放弃其奉行几十年的应用开发流程，全盘接收Saber的应用开发流程，好像是终于找到了救命灵丹了。可见EDS的领导层的水平如何。
从技术上讲，Saber的复制-修改的做法至少是短视的。从架构的角度上讲是一个严重错误。我在HA时也遇到过类似的经历，我当时的态度是：除非我死了，不然想都别想！“Over my dead body！". 正确的应对应该是一、尽量用数据配置的方法来实现不同用户的需求，二、 确保系统核心源程序共享，同时允许个性化不同实现。这两个方向都需要很高的设计水平，如果架构师的水平不够的话是有较大的难度的。从我后来与原架构师的沟通中我对他有些了解，也非常理解他的处境和技术水平的。在项目后期他被迫离职了。
放开多用户源程序共享不谈，其实他的设计也不太差，如果开发人员都尊照他的开发思想去做的话，也不致于到了彻底失败的境地。失败是有多层面的原因的。让我来具体分析一下：
从管理层来说，他们对软件开发的复杂程度了解甚少，雇的人的水平也不好，在质量方面总是抱着侥幸的心理。我的老板就我发现的技术问题对我说了这样的话“可能你发现的问题不像你描述得那样严重，可能客户不会发现呢？我们就希望客户中没有像你这样高水平的架构师。你可不要为那个客户工作呀！”
从架构设计师的方面，一个重要的问题是架构师的水平，和他们的工作态度。架构师们总是把自己放在开发人员之上，连座位也与开发小组分得开开的。就有一位架构师私下的我说他的理想工作就是不再看源程序了。他们所提出的主张一般都不太现实，可是他们不用在具体工作中受苦，所以无所顾忌。
从项目管理人员来说，他们最关心的是项目进度，一切注重质量，致力于长期开发效率的努力都不被他们欢迎。可是正是由于他们对进度的疯狂追求反而造成了一次一次地不能按时交货。
从开发人员来说，本身的技术水平就不高，没有架构师的指导，也没有有效的设计文档。工作时间安排非常之紧，一旦出错就被斥责。他们的态度就是只要胡过今天就好，绝无长久的打算。可是就像住在公寓里房客，因为不是公寓的拥有者，从不注重公寓环境的保护，总是以为你是暂时住在那里，可是不管你是不是主人，你却天天住在里面，一住就是三年，你也是你对环境破坏的受害者。每天工作痛苦不堪。
经过一段时间的了解和研究我开发出来一套在不太影响（10%）开发进度的情况下改进架构设计的工作流程，其关键步骤就是我审查所有的程度更动，提出修改意见并与开发人员一同工作实施修改。六个月后初见成效。一年后成绩显著。我以为我为公司找到了成功之路，就写了一篇文章。从理论到流程，从技术到实例最后以程序质量指数证明其作用。并为此做了专题演讲。演讲结束后，一位资深架构师与我说：“there are only 3 persons understand what you were talking about. The first is you, the second is you, the third is also you." 他的意思很清楚：一、他懂我在讲什么并且赞成。二、其它没人懂，也没有人有兴趣懂。
果然总架构师并不重视，开发经理多番作梗，原本有希望力挽败局的我面对日渐败落的系统捶手顿足，一筹莫展。
就在这个时候，VT州的客户找了个第三方做了个项目评定。第三方咨询公司毫无困难地给出了一长长的问题清单和整改要求。VT州不像NM州那样直接终止项目而是将这个评定报告给了惠普，并要求惠普给出整改计划。我参加了整改计划的讨论，并就每一项问题提供了具体的整改措施。可是总架构师否决了我的大部分措施，理由是太过费时费工，与项目进度要求不符。在恵普的正式回复中对大多数的问题的回答是"开发期间不予处理，上线后期作为产后支持解决”。其结果是可想而知的了，VT州终止了合同并把恵普告上了法庭。
因为这几个项目源于同一套源程序，VT项目有的问题MI项目也都有。我以为公司会从VT事件中吸取教训会认真地在处理MI项目中的设计问题，认真地一一给出了技术解决方案并做了相应的论证试验。可是出我预料的是项目经理和总架构师同出一辙地淡化问题，简化解决方案，最后基本上是什么都不做。
其间RI项目也出了状况，客户拒绝了整个系统要求限期整改并提出项目项目上线日期。面对这样的情况有一个架构师，就叫他G吧，他提出了软件工厂的思路，根据G的思路软件工厂生成75%的源代码，程序员只要写1/4的源代码加上测试就好了。EDS的上层领导层觉得好像是找到了金钥匙，全力支持，就像几年前全盘接受Saber 的软件开发流程一样。
由于我在HA的经历我对这个从头再来的计划胆颤心惊，我约了G出来吃饭并分享了我在HA的失败经历。提醒他注意并且对他的软件工厂向思路提出了质疑。可是他并不重视我的意见和经验，一意提出了一个非常激进的开发计划。具体地是六个月一期交付使用，九个月二期交付使用，十二个月项目结束。对此我的态度是“这真是太好了，好到不敢相信的程度。” 断定不可能如期实现。与我有同样观点的还有一位熟知车辆管理流程的需求专家。可是EDS的高层压制一切反对意见决定采纳G架构师的方案。我与我的上司，架构部的主任，反应了我的观点。可是我的上司却告诉我他押在软件工厂的方案上了，要求我全力支持。并要求我参与项目担任架构总监（oversight）的职务。
作为一个敬业的工程师，我努力地工作，可是这造成了我与G的冲突。最后我写了一个长长的电邮给我的上司主动提出退出项目。在电邮中我这样写道：如果你仍然相信G的设计，为了给他一个公平的机会你们应该让他独立地主持架构设计。如果有一天你们对他的设计失去信心了希望我来主持这个系统的架构设计，我会尽力去做的。不过把两个设计理念不同的架构师放在一个项目里不是一个最好的方法。对此，其中一个项目经理力挺留下我，可是他也被人放在一边了。
自从那以后我基本上被闲置了。那是二零一二年。我除了做分配给我的工作开始了新的技术研究。我的研究有几个方面：一是在个人博客上发表系列文章描述我发现的技术问题和解决方案。二是致力于MVVM 软件开发模式的研究。三是致力于移动应用的研究。四是学习最新版本的C#语言并努力通过微软的资质证书。
在博客上发的第一篇文章就是“Tailor Ed has 4 sons.... The third suggests to use auto tailing machine. ”结论是“if something is too good to be true, probably it is!"
Ed is 影指EDS, auto tailing machine is 影指软件工厂。4 sons 影指四个州的客户。 结论是那不可能成功的。一年中发了近五十篇文章。
在MVVM的学习方面我用学到的技术写了一个用于监测股市的软件。同事们都竟相索要。基于这个软件我又写了一个发言稿希望有机会在架构师部门做一个介绍。可是老板说只有我同意与另外两位架构师一道署名才可给机会让我讲。我问道：那他们在这方面有研究吗？答复是他们有兴趣学习。我说“那这样吧，为了鼓励他们的学习精神，让我把已经掌握的知识放一边，与他们一同学习吧。”结果谈话不欢而散，讲座的事不了了之。
在移动应用开发方面我在微软视窗8.1面世三个月后就推出了一个基于8.1的移动应用。并得了最佳应用奖。后来在同行的邀请下在哥伦布微软移动兴趣小组作了演示和演讲。演讲之前请示领导，得到的答案是只要不提惠普，不提惠普的客户就行。
在C#的学习方面也取得了成功，在二零一三年初我就通过了徽软件的资质考试。在这些工作的同时我还因为身体健康原因在二零一二年初又去克利夫兰诊所做了一个不小的手术。我的老朋友Daniel知道了我的近况后说你总是有办法让我惊呀你的成就，你是我的榜样。
在一次例行一对一会议上我问我的上司：我在惠普工作了四年了，只听到这个那个项目终止了，没听到过哪个项目胜利完成了。你是不是听到看到一些我没听到或看到什么成功的案例呢？他说：我也希望我能说有成功的项目，可是我没听说过。I wish I could 。我又问道：那这是什么原因呢，你有什么见解可以改变这个现象呢？他的回答是：那不是我操的心了。(That is above my pay grade)
二零一三年底我觉得我真的不愿意在惠普工作了，就开始找工作。在一四年三月就找到一个经理级的架构师的工作。工资涨了许多。由于惠普没人睬我，也没有管我，我在完成惠普分配给我的工作的情况下开始了新的工作。不过第一周我还是用了假期的。就这样直到二零一四年一月，惠普辞退了我并给了十五个星期的遣散费。
离开惠普后不久得知MI州终止了项目并把惠普告到法庭。RI州的项目并没有如G架构师计划的那样一年之内交付使用。一直拖延到一五年底并接近完全失败。终止项目只是时间问题了。惠普上层对EDS/Saber 这个部门完全失去了信心，决定终止所有项目辞退大多数人然后关闭这个部门。闻讯后我痛心地对太太说：我本可以救这个部门的只是他们没有给我这个机会，可惜了！
因为新的工作需要每周出差到佛罗里达州，我又开始了飞人的生活。
