[102] An excellent example of this is UML Distilled, 2nd edition, by Martin Fowler (Addison-Wesley 2000), which reduces the sometimes-overwhelming UML process to a manageable subset.
[103] My rule of thumb for estimating such projects: If there’s more than one wild card, don’t even try to plan how long it’s going to take or how much it will cost until you’ve created a working prototype. There are too many degrees of freedom.
[104] An excellent resource for requirements analysis is Exploring Requirements: Quality Before Design, by Gause & Weinberg (Dorset House 1989).
[106] More information on use cases can be found in Use Case Driven Object Modeling with UML by Rosenberg (Addison-Wesley 1999) . A good overview of user stories is found in Planning Extreme Programming, by Beck & Fowler (Addison-Wesley 2001).
[107] My personal take on this has changed lately. Doubling and adding 10 percent will give you a reasonably accurate estimate (assuming there are not too many wild-card factors), but you still have to work quite diligently to finish in that time. If you want time to really make it elegant and to enjoy yourself in the process, the correct multiplier is more like three or four times, I believe. See PeopleWare, by DeMarco & Lister (Dorset House 1999) for studies of the effect of schedule estimates on productivity and a debunking of “Parkinson’s Law.”
[108]Planning Extreme Programming (ibid.) has some valuable insights on planning and time estimation.
[109] For starters, I recommend the aforementioned UML Distilled, 2nd edition.
[110]Python (www.Python.org) is often used as “executable pseudocode.”
[111] “What can be done with fewer ... is done in vain with more ... the mind should not multiply things without necessity.” William of Ockham, 1290-1349.
[112] At least one aspect of evolution is covered in Martin Fowler’s book Refactoring: Improving the Design of Existing Code (Addison-Wesley 1999), which uses Java examples exclusively.
[113] This is something like “rapid prototyping,” in which you were supposed to build a quick-and-dirty version so that you could learn about the system, and then throw away your prototype and build it right. The trouble with rapid prototyping is that people didn’t throw away the prototype, but instead built upon it. Combined with the lack of structure in procedural programming, this often leads to messy systems that are expensive to maintain.
[114] Although this may be a more American perspective, the stories of Hollywood reach everywhere.
[115] Including (especially) the PA system. I once worked in a company that insisted on broadcasting every phone call that arrived for every executive, and it constantly interrupted our productivity (but the managers couldn’t begin to conceive of stifling such an important service as the PA). Finally, when no one was looking I started snipping speaker wires.
