ACME Widgets had a problem. The system they had been using to manage the inventory of their widgets was not designed for the type of volume they’d grown to produce. Their employees were frustrated and it became obvious that they needed a solution to help them keep everything under control.
After a thorough search for local software companies, ACME contacts Hamster Software to see what they can do about solving their problems with the widget inventory. They liked what they saw on Hamster’s website, and having no experience with software development, assumed by the look of the website alone that Hamster would be right for the job. They weren’t wrong, but they weren’t completely right either.
So ACME and Hamster Software start to talk about how to solve the problems with the widgets. Internally, Hamster’s team knew they hadn’t seen a problem quite like this before. However, Hamster has a good group of guys working for them and they were sure it was something they could figure out.
ACME and Hamster agree to work together based on an estimate with no basis in reality. This is their first mistake. The team at Hamster assumed it would be simple enough to modify some existing software to meet their needs and provided an estimate based on those assumptions.
In the beginning, Hamster is able to make amazing progress along the design that ACME agreed to. For a while, it actually appears that they’ll be able to meet the budget as originally designed.
Except for the bugs.
It started small at first, and given the blistering pace that Hamster was able to set, ACME understood that software in development isn’t going to be perfect. They were excited to start using it and it was already a better solution for the problems they’d been having so it was deemed good enough to go into live use, despite the bugs.
But, the guys at Hamster Software are smart. None of the bugs were there on purpose, but because their development process consists solely of identifying problems and then writing code to fix them, sometimes it was easy for unexpected things to happen (the bugs). As they progressed and the project grew, it became more difficult to remember the reasons behind all of the decisions in the code, but they’re all smart guys, so it’s nothing they can’t handle.
Richard Hammond, one of Hamster Software’s founding partners was a great developer who has made big contributions to the project. One day, Richard gets a job offer from Fifth Speed, a very prominent software company, that he just can’t refuse. The Hamster team is upset, but there’s nothing they can do so they continue without him.
If bugs were an issue before, Richard’s absence added jet fuel to the flames. He had held much of the knowledge of how everything worked in his head and now the software needed to be finished without him. It was beginning to show that something wasn’t working in the way Hamster builds software.
The bugs multiplied. Every new release seemed to break more and more of work that had been previously completed.
The specification documents were the only source of reference for what the project was supposed to do and by now had grown so lengthy that it was impossible for any one person to handle.
ACME’s goal of a solution for their widget problems seemed just out of reach. Each new release was a step forward and a step backwards. Now that they were using the system to power their business, the bugs not only affected ACME’s employees, but also their customers.
The bugs were contributing to a loss of real business value. Sure, the software solved ACME’s original problems, but it introduced others and it wasn’t able to change with the business. This grand system that was supposed to solve all ACME’s problems looked more like a liability than an asset. It continues to consume massive amounts of money to maintain each month and no end is in sight.
Sadly, this is the state of many software projects today. Poor planning, inaccurate estimates, and a never-ending stream of “maintenance” combine to make the world of software development pretty daunting for serious projects.
Only by working together can we as an industry strive to improve the problems related to estimates and unrealistic expectations of software projects.
Always strive to understand problems before you attempt to solve them.
Always test your code, if not for you, then for the next guy to work with what you’ve written.
----------------http://blog.buildbettersoftware.com/post/35073542031/the-story-of-a-typical-software-project------------------------------------
一个典型软件项目的故事
ACME公司的Widgets系统出了点问题。这个系统被他们用来管理器材的库存，当初设计时没考虑到如今这样大量的数据的增长。他们的员工因为这个问题备受折磨。很显然，需要想办法解决这个问题，让系统恢复正常。
经过对本地软件公司的一番筛选，ACME联系到了Hamster软件公司，看看他们能否解决这个库存系统中的问题。他们很喜欢Hamster软件公司的网站，他们没有任何软件开发的经验，但根据网站的外观，他们估计这个软件公司能解决他们的问题。这件事上他们并没有做错，但也不是很对。
于是，ACME公司和Hamster软件公司开始讨论如何解决他们库存系统中的问题。私底下，Hamster软件公司的开发团队知道以前从未处理过类似这样的问题，然而，他们有一群很能干的小伙，他们相信一定能把这个问题解决掉。
基于一个不符合实际情况的预估，ACME公司和Hamster公司达成协议一起努力来解决问题。这是他们犯的第一个错误。Hamster公司的开发团队认为，对现有的软件进行简单的修改就能满足他们的需求，并在此假设上制定出了工程估算。
起初，按照ACME公司认可的设计方案，Hamster公司的开发进展神速。不久之后，事情看起来，他们的确是有可能按照最初的设计预算来完成任务。
除了有一些bug需要解决。
起初的bug都很小，就Hamster公司设定这种一日千里的开发速度而言，ACME公司理解，开发进行中的软件不可能做到十全十美。他们很高兴能 开始使用改造中的系统，对于出现的问题，开发团队已经有了更好的方案，所以，看起来，边改造边使用是没有问题的——尽管有些bug存在。
但是，Hamster软件公司的小伙都很能干。没有人希望bug的出现，但因为开发团队专注于解决扩容问题、写 代码来升级系统，所以，有时候，很容易会发生一些意想不到的事情(bug)。随着开发的进行，项目规模的扩大，记住代码中各种编写策略的背后原因变得越来 越困难，但是，他们是群能干的小伙，没有他们处理不了的问题。
Richard Hammond——Hamster公司的创始人之一，是一个优秀的程序员，他对这个项目做出了巨大的贡献。一天，Richard收到了来自Fifth Speed公司的聘请，Fifth Speed公司是一家非常出名的软件公司，Richard无法拒绝。Hamster公司的开发团队很沮丧，但对于这种事情，他们无能为力，只好顶着压力继 续开发。
如果这些bug之前一些麻烦，而Richard的离去相当于火上浇油。他的脑袋里装有大量的关于每个东西为应该如何运作的知识，而现在，软件只能在没有他的情况下独自完成工作。各种征兆开始显露，Hamster公司开发的软件里有些东西并没有按要求运行。
Bug成倍增加。每一次新的版本的发布看起来都会导致越来越多之前已经完成的功能不能用。
作为解释软件应该做成什么样的唯一参考来源的规格说明书，如今已经增长到没有哪个人能单独掌握。
ACME公司距离他们解决库存系统问题的目标看起来是越来越遥远。每一次新版本的发布都是一次前进，但也是一次后退。他们用这个系统来提升他们的业务，但bug不仅影响了员工的使用，而且影响到了客户。
公司实际业务上的损失有这些bug的很大功劳。没错，ACME公司库存系统原始问题已经解决了，但却引入了其它问题，算起来得不偿失。这个庞大的系统本以为能解决ACME公司所有的问题，但现在看起来更像是一个负担，而不是资产。它每月还在不断的吞噬巨大的财力用于维护，远看不到尽头。
可不幸的是，这是如今大多数软件项目的现状。糟糕的计划，没谱的预算，无休无止的“维护”，使得我们软件开发世界对真正的软件项目失去信心。
只有我们共同努力，以整个行业之力，才能改进软件项目中估算和不切实际的期望等相关问题。
在试图解决问题前，一定要尽量理解问题。
测试你的代码，即使不为自己，也是为下一个接手你工作的人。
---------------http://www.aqee.net/the-story-of-a-typical-software-project/--------------