For more on specifying dates and times (e.g., the intricacies of the Julian Date and the Modified Julian Date) see the web pages of the Time Service Department of the United States Naval Observatory. Markus Kuhn at the University of Cambridge Computer Laboratory has an informative web page on the International Standard Date and Time Notation (or ISO 8601 as it's called) on his web site.
It's hard to appreciate the difficulties involved in developing large programs until you've actually written large programs. It's even harder to appreciate the problems that arise in getting teams of programmers to develop very large programs. Fred Brooks in his The Mythical Man-Month [Brooks1995] examines why you can't speed up a project that requires one programmer to work for one year by a factor of twelve by hiring twelve programmers to work for one month each. The first edition of his book was published in 1975 and it summarizes the lessons he learned in managing the development of the core systems software for the IBM 360, an important machine in the history of computing. Now you might protest that software engineering has come a long way since 1975, but many programmers and software developers would argue that the problems Brooks identified then are even more evident today despite nearly thirty years of work on programming languages.
Part of the problem of decomposing a large software project into tractable components results from the fact that it is hard to cleanly separate the components, and difficult to establish and maintain the interfaces between components as the project evolves over time. Programmers end up spending a lot of time in meetings and exchanging email to hash out these interfaces and resolve the inevitable problems that arise when programmers working on one component assume too much (or know too much) about other components.
As an exercise, I want you to experience what it's like to manage the development of a program to simulate the commercial transactions of an ice cream parlor using object-oriented programming.16 Work in teams of four consisting of a designated manager (the exalted one) and three programmers (peon #1, peon #2 and peon #3). (Check out the latest wisdom on team dynamics and office politics from Scott Adams' Dilbert comic strip.) The project manager's job is to break the problem into tractable components, assign the components to different programmers, and then oversee the ensuing chaos. The following specification of the problem suggests three components, so I've already done part of the manager's job (and possibly made it a lot harder), but I guarantee there's plenty of work left for a competent manager.
Here's the problem specification. Suppose that your customer, Jen and Larry's Ice Cream, needs a tool to project sales on the basis of various customer profiles. We'll assume that these profiles are pretty complicated, otherwise you could create a pretty good sales model using a spread sheet program like Excel.
You're being hired to build the basic simulation system including components for creating generic simulated customers that Jen and Larry's financial analysts will then extend by plugging in their sophisticated psychological profiles (e.g., if a customer wanting Grateful Goobers is told that the store is sold out of that flavor, then she will choose an alternative by selecting Nougat Nuggets or Phlavorful Phantasies with equal probability; if none of these three flavors are available, then the customer will attempt to buy a pint of Vinyl Vanilla and if this fails she will leave the store never to return again).
In my simple formulation, the problem is divided into three components corresponding to three classes: consumers that purchase and consume ice cream, retailers that sell ice cream and generate profits and losses, and markets that orchestrate (simulate) the exchanges among consumers and retailers. Here are some characteristics of the instances of these three classes.
A consumer has preferences for different flavors of ice cream. When asked to order, a consumer uses its preferences to respond with a request for a particular flavor, and acknowledges receipt if given that flavor. A consumer in the process of ordering can be asked to choose another flavor presumably because the retailer is out of previously requested flavors; upon receiving such a request the consumer can either choose an alternative flavor or cancel the order. Note that a consumer needs to maintain local state information to keep track of an order in progress. If you really want to go crazy, you can imagine a consumer capable of managing multiple orders simultaneously. You could arrange for consumers that recall past orders and base their current selections (e.g., I never order the same flavor twice in a row). Going crazy may seem like a bad idea, but thinking about a richer model of interaction might suggest ways to actually simplify your design and make it easier for Jen and Larry's programmers and analysts to use your system.
A retailer also has to retain state information to keep track of orders and to keep track of inventory and profits. Retailers have to request consumers to submit orders, inform consumers if an order can't be filled, fill an order if possible, and collect payment for accepted orders. Finally, markets are responsible for orchestrating the buying and selling of ice cream. A particular market manage running the main loop of the simulation, selecting consumers from a pool of consumers according to some probability distribution, managing the exchange of information between the selected consumer and the ice cream parlor, and perhaps terminating the simulate after a specified number of iterations and then printing out statistics summarizing profits, remaining inventory, etc.
As you develop your designs, I want you to think about Parnas' Principles [Parnas1972] and comment on why it might be a good idea to adhere to such principles in building large pieces of software:
The developer of a software component must provide the intended user with all the information needed to make effective use of the services provided by the component, and should provide no other information.
The developer of a software component must be provided with all the information necessary to carry out the given responsibilities assigned to the component, and should be provided with no other information.
Here's how I suggest you proceed:
The team member designated as manager produces a written document elaborating on the above sketch and assigning the three components to the remaining members of the team.
The team meets to discuss the design document and, if necessary (chuckle), clarify any confusions or remedy any problems. It's the manager's responsibility to make sure the team works out exactly how the three components are going to interact. Don't forget Parnas' Principles.
The three programmers go off and implement their separate components. Each programmer produces a document describing how his or her component works in enough detail that someone else can simulate the behavior of that component.
The team meets again and the manager critiques the component designs. The programmers trade documents and simulate the behavior of the whole system. The programmers then go off and revise their documents. Repeat as needed.
For background on the techniques and travails associated with software engineering in the large, you might check out the review of 20th Anniversary Edition of Brooks' The Mythical Man-Month in Dr. Dobb's Electronic Review of Computer Books. You might also peruse the introductory chapters in Timothy Budd's Introduction to Object-Oriented Programming [Budd2001] excerpts of which are available on his web page. If you're really motivated, you might actually go to the library and check out (literally) one of these books. In any case, don't expect a simple recipe to make your task trivial; even professional programmers find what you're trying to do hard.
OK, it's time to assign grades. You're all experts now; so we'll let you assign grades to one another. Each team will be graded by another team. We'll work out the details of the grading standard in class, but here's the basic procedure for grading. First, the three programmers on the team doing the grading will meet with the manager of the team being graded. The programmers on the grading team try to simulate the graded team's program (the three documents produced by the graded team's programmers) with the help of the graded team's manager. Then the programmers rejoin their respective managers and caucus to determine grades. Finally, grades are announced and an acrimonious and emotional debate ensues.
Download all the code fragments in this chapter as a file in zip format.
16 I got the idea for the ice cream parlor simulation from glancing through Timothy Budd's A Little Smalltalk [Budd1987] which just happened to be on the same shelf in the Brown library as Brooks' The Mythical Man-Month. Budd has a chapter on implementing such a simulation in the object-oriented programming language, Smalltalk, which was designed, in part, to make it easy to build such simulations.