Real artists ship. —Steve Jobs as quoted by Steven Levy in Insanely Great.
Business requires you to take the Right Action, so in Chapter 4 we look at the business aspects of systems, including management actions such as plans and measures, but especially, strategy. Yes, Virginia, you need to develop a little sense of business strategy. When asked at a social event: “What business are you in?” Most of us in IT will answer “Information Systems”, or “Computers”, or “The Software Industry” despite the fact few of us actually work for a computer or software company. According to the Department of Commerce, we’re not in the software industry, we’re in the industry that our employer is in. One problem with techies is we don’t always know or even think about the business itself. Any technician moving to a new company will know what version of Oracle is installed, how many T3 lines there are, or what the network architecture looks like, long before learning what the corporate objectives are for the next year, or investigating what makes his user counterpart tick. Your company is out to make money, or if not a profit maker, to retain as much as possible. Yes, it’s filthy lucre, but hey, that’s life, and why they hired you.
Miyamoto Musashi (1584-1645) was one of Japan’s greatest strategists. Although he was actually a master of Kendo, the Way of the Sword, Time Magazine called him “Japan’s answer to the Harvard MBA!” Time went on to say: “On Wall Street, when Musashi talks, people listen.” In Go Rin no Sho, The Book of Five Rings—actually a letter to his sword fighting students written shortly before his death—the Sword Master enumerates nine principles of strategy. These precepts have surprisingly broad application to systems analysis, so Musashi is referred to throughout this book. Here they are, mostly Victor Harris’ translation of the Japanese, and my interpretation of their applicability to Systems Analysis:
1. Do not think dishonestly. Notice it says do not think dishonestly. In Systems Analysis, it is bad policy to fool others, but it’s even more foolish to fool yourself. In Rapid Development, Steve McConnell elaborates 36 classic mistakes in software development, lucky 13 being “Wishful Thinking”, as in “The schedule is impossible but if we work hard we can make it”; or “We haven’t coordinated the interfaces but we are good communicators so it will be easy”; or “No need to ask the users because we know what they want”. Overly optimistic schedules are a way of life in systems (McConnell’s classic mistake number 14), as is the persistent belief, despite all evidence to the contrary, that you’ll make up your schedule slippage in the next phase (number 26), or that your new tool or method will save plenty of time (number 34).
2. The Way is in training. Being a systems analyst requires lifelong learning. Technology is changing at an ever more rapid pace; if you don’t believe me, just go into a bookstore in late spring or early summer and see how many computer books already claim copyrights for the coming year! Read a book, or better take a course from me at UC Berkeley Extension.
3. Become acquainted with every art. You have to understand the world to understand any system. If you are naturally interested in a variety of arts, you’ll enjoy the work of a systems analysis, since broad curiosity is almost essential to succeed. To help the accounting department, for example, you’ll need to understand the art of accounting. Curiosity killed the cat but is good for the systems analyst. Always strive to be eclectic, picking the best from any art. You’ll notice in this book I’ve been eclectic. Okay, okay, so maybe random is a better word for me, but you get the idea: you should open your mind, and bring ideas and analogies from other disciplines.
4. Know the Ways of all professions. To help your users, you need to understand something about what they do. Computers now touch on every field, but as I keep telling you, you need to understand both business and technology to be a Systems Analyst.
5. Understand profit and loss. Understand Economics. (My observation has been that, as a group, Economics majors make the best systems analysts, but since I am part of that august group, I would understand if you discounted that observation.) Money makes the World go around, and also systems. Most computer systems are business systems, and so must cover their costs and have a favorable ROI (Return on Investment).
6. Develop intuitive judgment and understanding for everything. Go with the flow, your gut intuition, or hara. About the only way to achieve this is through experience: Good judgment comes from experience. Unfortunately, experience comes from bad judgment.
7. See those things which cannot be seen. At one level, that’s all we do: we certainly cannot see any of the computer’s electron-level activities. But as analysts, we can use models and other tools to see the unseen. See Chapter 8 for more on this topic.
8. Pay attention even to trifles. The devil is in the details. All analysts know how a trivial piece of information can change everything. The trick, of course, is knowing which trifles will become important later. I’ve also seen this principle punctuated: “Pay attention! Even to trifles”, for those of you who don’t pay attention.
9. Do nothing which is of no use. Efficiency, economy and no redundancy. Constantly reflecting on your own techniques and improving them (kaizen) will help you follow this dictum. But also be sure the system itself, not just your development methods used to create it, follow this rule. Featuritis, where we add features for no conceivable end except the feature itself is an example of a failure to observe this principle.
The Technical and the Business must come together: We must reconcile the irreconcilable, because business and systems are now inseparable. This can be difficult given our modern organization. Few people nowadays are actually involved in the direct production of the goods or services their companies are in business to produce. In 1776, the year Adam Smith’s The Wealth of Nations appeared, most people working for a pin company were involved in making pins, and most people at a shipping company had something to do with ships. Today, pin and ship companies employ many more computer programmers, lawyers and accountants than pin-makers or sailors, and more executives than sea captains. As a consequence, it is easy to lose sight of where our tasks fit in the process.
In order to truly understand the relationship between systems and the businesses they support we need to break the business itself into its components. Some models represent three or five levels; that is valid depending on what you’re goal is. In this model we’ve decided to err on the side of overkill and look at nine levels. We’ll consider each tier in turn.
I. The World
1. The Real World
2. The Business Model
3. The Business Workflow
II. Software
4. Analysis Models
5. The User Interface
6. Application Logic
III. Hardware
7. Data Organization
8. Machine Representation
9. Circuits
You were hired to create a system for your business. Your system needs to support the work of that business. I use the term “business” but of course whatever your company or organization does—be it a corporation, a government, school, or nonprofit—is the business you need to reflect in your model and thus your system.
1. The Real World. There is a real world with sunshine and rain, laughter and tears, beauty and horror, and someday it will all end. But in the meantime we need to develop systems that work in that real world.
2. The Business Model. The business model describes what the business actually does. Some companies make a formal statement of their model as a Mission Statement, but whether stated explicitly or not, every organization exists to do some things and not others. The mission, goals and objectives of the business identify a market and a product or service within that market. Whether or not formally defined, there is a business model.
3. Business Workflow. The business is supported by business processes that do the work. The business processes, whether manual or automated, standardized or informal, are a flow of work through the organization. Basically, they do the work: fulfill, or sell, or assemble, or paint, or educate. You could write an entire book on this layer alone—come to think of it, Alec Sharp and I did! See our book Workflow Modeling: Tools for Process Improvement and Application Development for deep enlightenment on this technique. In it we also look at five of these nine levels in greater detail, using a five-tier model that collapses the machine level.
Most technical people are good at this level, but do not make the connection between it and the business level above it. I’ve broken software into analysis and programming, or application logic, because many of my readers are in this field, and this is a distinction they make, and is even a job path for them. An analysis model is an analogy to understand the structure of data which is in fact not structured at all, but a series of magnetic blips in ferrous oxide.
4. Analysis Model. This model represents the business. ERDs, class diagrams, etc. Could also be a design, planning, conceptual, etc. Data, process, object. Workflow. What this book is about.
5. User Interface, or Presentation. Automated applications need a way to present data to the humans using the system. This presentation layer is a way for humans to communicate with the machines. It includes any mechanisms by which people or other systems interact with a computer system. They are usually screens, reports, or GUI’s (Graphical Use Interfaces—computer dialog screens), running on the desktop, but they could be just about anything: EDI—Electronic Data Interface between companies, a kiosk, Email, the World Wide Web, VR (Voice Recognition), computerized mind reading, or whatever new device technology might hatch next. Use Cases fall here as a model of the interaction. Notice more and more the output of one machine is presented to another machine, and the interface can be to not an eye, but an API.
6. Application Logic. Application process logic ties the presentation and the data together in computer programs, turning the business rules into algorithms to properly process the inputs into outputs. They could be contained in stored procedures or application logic distributed across server or client machines, but they are usually in computer programs.
This is the engineering or architecture level. Strangely, this is the most abstract, yet most reliable. In truth there is no real structure, just seemingly random bits and bytes. But since our system software provides discipline, it is the most reliable level. Unless you are a systems specialist, you never even consider this level and are largely unaware it even exists, except on those rare occasions when the hardware or systems fail, in which case you are painfully aware that there is reality behind the magic.
7. Data Organization. Computers don’t compute: Despite the name, most computers actually do very little computing. Their major power is the ability to store and retrieve data. This is where data management and databases come in: they keep the data needed for the business to operate. Databases maintain records of people, places, things, and events affecting the business. Nowadays, they are usually saved in a relational DBMS—Data Base Management System—running on one or more servers. I include the DBMS here even though it’s at root a mostly software; the DBA’s who are responsible for the DBMS are usually not in the same organization as the applications programmers and systems analysts who develop the software but with the systems people responsible for hardware. Just in case they object, I’ve put them here as a compliment to the fact DBMS’s are as reliable as hardware, and much less subject to the problems of other software.
8. Machine Representation. Here we are “Close to the Machine”. No structure, no relationships, data is linear (actually, usually circular, since disks spin). The machine actually models data, since it’s bits and bytes and electronic blips. For example, the number 999,999 is represented 11110100001000111111, as spots that are, or aren’t, magnetized on the disk.
9. Circuits. Electrons, gates, Integrated Circuits. At least until we have Quantum Computing and circuits are unnecessary. I still find it astounding when a piece of sand, which is all computer chip is, adds 2 and 2 and gets 4! If the Tao of Physics is correct, this is reality; the top level we called the Real World is the illusion, and thus we circle back.
This is not a quiz about business in general, it’s a quiz about your business. Answer the following questions about your company (not the IT department). If you don’t know the answer, write “I don’t know”.
For any you wrote, “I don’t know”: Go and find out!
Companies that plan are more successful than those that don’t. But companies that actually follow their plans are less successful than those that do not follow their plan. So, should you spend months building a plan and then just ignore it??? Not exactly. You need a plan as an indicator of your course, but you must not rigidly adhere to some plan you wrote months before with incomplete knowledge. If you had a plan to drive to some distant city, but insisted on following the planned route even after you discovered a bridge was out, you’d be considered crazy. But some plans (and don’t forget, a budget is a kind of plan) are considered sacred text, never to be questioned once approved. You need the flexibility to steer the best course at a given time. As Eisenhower pointed out: the plan is worth nothing, but the planning is everything.
Make a plan, but don’t plan to follow it:
You gotta be Flexible
Once upon a time, there was a small wooded han (feudal realm) whose daimyo (great lord) enjoyed hunting. One day the daimyo went hunting in a remote corner of his han, and was surprised to discover a strange sight. Mile after mile, the trees had targets painted on them, and in the bull’s eye was an arrow, dead center. Although annoyed at the effrontery to his trees, the daimyo realized this must be the work of perhaps the greatest archer in the world! So he sent his samurai on the task: “Find this incredible archer!” To make a long story short, one of his samurai soon announced he had found the archer, and introduced a young lady of perhaps nine years old. This seemed unlikely to the daimyo, so he asked the girl how she had achieved such accuracy. “It’s really quite easy, your majesty,” she said. “First you shoot the arrow, then you paint the target.”
Despite the importance of having a plan, and mapping out your future, sometimes you don’t know where you are going, and that can be a good thing. Especially with new technology, it is sometimes hard to predict the outcome, but without the experiment, you’ll never find the good. Allow yourself to occasionally shoot an arrow then choose the target.
How should you develop your plan, then? There are two main ways, top-down and bottom-up. In top-down planning, you take a broad view of the IS needs of the entire organization before selecting projects. The advantages of top-down planning are clear in the view of most theoreticians: Broader perspective, improved integration, improved management support, and better understanding. If you don’t have an overall plan, you’re likely to wind up with a stovepipe system, with incompatible systems that don’t talk to each other.
To do top-down planning, you start with a project that produces the plan. It’s customary to first inventory your current systems and assess the current situation, looking for gaps in systems, technology and personnel (staff and training). Next you’ll want to blueprint the ideal future situation, including database and systems, technology and staff. Then lay out a tentative schedule or prioritizing of projects. Methodologies such as IBM’s ISP (Information System Planning) or Information Engineering’s Business System Plan can be followed, but they are a little too formal for my tastes.
In bottom-up planning, you respond to business problems and opportunities. You let project proposals bubble up from the bottom of the org chart where the work is being done. Ideally, you’ll set up some review and estimating procedures so top management can periodically (say annually or semi-annually) review current proposals and select projects for development. This is often faster and less costly than a major planning effort, and identifies the most pressing problems. Although it might produce less management support, it produces more line support. This can be more democratic, but can degenerate into an ad hoc-racy, worse than no plan. It fails to view the entire organization, which can lead to redundancy, and systems that are hard to integrate. You will also face the squeaky-wheel syndrome, where the loudest or most politically astute get their projects approved over more important projects, and short-term fixes are favored over strategic development.
So why do more companies use bottom-up planning in practice, since top-down seems to have the edge? Top-down planning takes time up front. ISP projects can take six months to a year, and often deliver no direct benefit for several years after that. In a rapidly changing business environment plans are obsolete before they are written. So a good plan today might be better than a perfect plan tomorrow, but that’s not the same as having no plan.
The ideal planning method will use both techniques. Nonaka & Takeuchi point out in The Knowledge-Creating Company that Japanese companies often use a third way called “middle-up-down”. A general, overall plan should be prepared, but you must be prepared to allow the plan to change from the bottom up as well. And you must be flexible because of the planning paradox. Use both ends against the middle. If top down doesn’t work, try bottom up, or even middle out. Remember there are many ways to the mountaintop.
When I was in the fifth grade, I delighted in observing the many varieties of insects that inhabited the streams and fields near my home, so I decided to be an entomologist when I grew up. This was a momentous decision indeed, since it required abandoning my long-held (since early fourth grade) plan to be a Nobel-Prize-winning chemist. But when I read that chemical companies were the largest employers of entomologists, I decided my two passions were complementary—I would be an entomologist for a chemical company. It was some months before the awful realization struck. The tie between chemistry and entomology is insecticides, and the career goal of most entomologists is to kill as many insects as possible. As a consequence, I abandoned my plans for both chemistry and entomology, but eventually found a career that involved ruthlessly exterminating bugs without harming any insects—computer programming. And tracking down computer bugs is something programmers spend a lot of time doing. Why don’t we get them all?
Cockroaches have been a scourge of mankind for centuries. They’re actually quite easy to kill—you can step on them, poison them, throw things at them, etc. We don’t because there are so darn many of them, and they are hard to find. That’s exactly what we are facing with debugging: Each bug is simple to fix once you find it, but there are so darn many of them, and they are hard to find. The Yanomamo Indians of the Brazilian rainforest get terrible infestations of cockroaches. Every couple of years they completely exterminate all the cockroaches. It’s quite simple: they burn all the buildings in the village to the ground, and start over. With computer bugs, you should avoid the Yanomamo solution and not burn your company to the ground in order to save it from relatively harmless bugs, just get the software good enough.
[ [ [
Ed Yourdon discusses the concept of “Good Enough Software” in his book, The Rise and Resurrection of the American Programmer. He attributes some of Microsoft’s paradoxical success to this concept —they sell software with thousands of known bugs, yet are extremely successful where it counts, in the marketplace. The only logical conclusion is that the ultimate judge of quality, the consumer, has decided the Computer Scientist’s definition of quality, absence of bugs, is not the measure, or at least not the full measure, of quality.
With Microsoft, it’s a pure business decision. Steve Ballmer of Microsoft was said to have been asked why Windows® has so many known bugs. Why don’t they just spend a little time and clean them up? Steve was reported to have replied something to the effect: “You know, for a couple of million dollars we could clean up all those bugs, and that amount of money wouldn’t impact our bottom line noticeably. But if I were budgeting that money, I’d put it in advertising, not fixing bugs. Because fixing every known bug would not sell even one more copy of Windows®, and the advertising would.”
[ [ [
Quality control is another example of finding the Middle Way. I’m going to tell you to increase quality but then just get “good enough”. The term “quality control” has become synonymous with the term “quality assurance”, but originally the terms were quite different. Quality control emphasized the word “control”, not the word “quality”. Daniel J. Boorstin points out in The Americans: The Democratic Experience that the American system of manufacturing produced a new way of thinking about “quality”: Make the product as good as it needs to be, but no better, with emphasis on “no better”. For example, a chain of clothing stores that produces cheap but fashionable clothes that wear out quickly might be thought to have poor quality control. This would be wrong: they probably have excellent quality control. They’ve decided to produce products that go out of fashion quickly, and so durability is not a concern. In fact, it’s Quality Control’s job to make sure they continue to produce cheap, fashionable clothing, and not slip into the trap of producing expensive, fashionable clothing by making costly improvements in durability. Quality control might also dictate removing jewels from a watch. If the jewels will cause the friction point to survive one hundred years, but the mainspring will break in ten, the additional cost of the jewels merely raises the consumer’s cost with no real benefit. Quality is judged by how well the product fills its function.
An example of how “good enough” programming is employed is when credit card companies calculate due dates as a certain number of days from the billing date without regard for weekends and holidays. Note on your credit card bills how often the due date falls on a non-workday. Often there is a hidden or unannounced grace period, which functions by announcing a due date on the bill that is several days before the actual due date as calculated for penalties. This grace period allows what is essentially a fuzzy calculation of due dates to work.
In designing computer systems, you need to consider this concept of good enough. Ask, “What is the underlying purpose of this process, and will lack of this feature totally negate that purpose?” If not, it might be “good enough”. Deming calls the fanatical search for perfection the “Fallacy of Zero Defects”. You will never achieve that goal, so at some point you need to release the system and move on to the next one.
The twin schedule busters are these two: Analysis paralysis and scope creep. Which is worse? That’s hard to say, because like many twins, they usually travel together, and are a manifestation of an unclear vision of where you are going.
Beware Analysis Paralysis. It’s when you study and study, and never actually do anything. If after a year you have lots of circles and boxes and arrows but no system, you have a case of analysis paralysis.
Say you need some new software. If you spend a couple of months making sure to get the very best tool, and it’s only marginally better than the competition, you’ve wasted two months. This is similar to buying a PC: are you waiting for the prices to come down? You have a horizon effect: there’s always something just over the horizon: you know in a few months there’ll be a better, faster, cheaper PC out. But at some point you have to go ahead and buy one, otherwise you’ll lose all the potential benefit. There’s always something you don’t know, something more to do, but at some point it’s time to move on.
When you set out to model, your purpose is to understand or illustrate, not build the Winchester Mystery Model. Sarah Winchester’s famous home, the Winchester Mystery House, is located in San José, California. Sarah, the heir to the Winchester Arms fortune, was told by a fortune-teller she would live only as long as it would take to finish building her house. So she decided to continue to build her house forever. She was the original 24x7 shop in Silicon Valley: twenty-four hours a day, seven days a week, someone was building something onto her house: stairways to nowhere, windows with a view of the wall, doors that led into empty space. Some analysts seem to have a similar goal in modeling—never finish! Unlike Sarah, who was sure she’d meet her fate if she stopped building, you will surely meet a terrible fate if you don’t stop analyzing—your project will be cancelled and you’ll never get to work on the new system! Once you understand the current system, you have completed the modeling, and it’s time to stop and produce a system.
The second terrible twin is Scope Creep. Many errors arise in drawing project boundaries, but the most common, and deadly to your schedule, is scope creep. Boundaries often become too large through scope creep—your project grows to unmanageable proportions one small piece at a time, until it’s so large that forward progress is impossible, and the completion date moves further away, not closer, with each passing week. This in turn is often caused by a project scope that is actually a function or department that plays a role in many processes. When the project team starts following workflows that cross the boundaries (they will, because processes do!) it’s natural to start adding activities to the scope.
Poor analysis can lead to missing an essential item that has to be added later. Or a great idea comes along, too good to leave out. You can also catch the dreaded Featuritis disease, where features are added endlessly for their own sake.
Scope is clearer if you also identify related processes that are outside your scope, and depict these early and often, and graphically. This technique also makes identifying processes easier in the first place. Simply naming a process is inadequate for people to understand what’s inside and what’s outside of its boundaries. The greatest protection is to clarify and communicate scope, then stick to it: just say no. Require a substitution, not an addition, when something essential is added.
I once got three annual reviews on the same day, because my boss was two years behind. This had a certain advantage, because the rating was largely based on how well I met my objectives, and since I didn’t have to even set the objectives until after all three periods were over, I naturally met them all! What factors can prevent you from meeting your objectives? Naturally, I have little personal experience to draw on, since I always reach my objectives (ha!).
The trivial answer is “Setting the wrong objectives”. In a sense, if you set an objective and fail to meet it, the objective was too difficult, or wasn’t important enough to devote sufficient resources to. Since objectives are goals set and sought, you might have set unattainable objectives. This is sometimes caused by being the boy who can’t say “no”, a desire to make your user happy by agreeing to the impossible. This brings up a philosophical and management problem. You can always reach your goals if you set them low enough. I once had a programmer working for me who never met his goals, and one who always would. The one who always missed was one of the best programmers I ever knew, the one who made his goals was one of the worst. How can that be? Tom would promise something in a week, but take two. Why was that so good? Because any other programmer would have taken four weeks. The programmer who always met his goals would have set an objective to complete that same assignment in eight weeks, and probably beat his objectives by completing it in seven. Tom* needed a real challenge, so he’d constantly aim for the stars. He usually “only” made the moon, or perhaps the outer planets, but that was pretty amazing. Is the goal to make better estimators, or make better systems? If a programmer’s good at everything except estimating, is he bad?
Largely because of differences in the way testing is defined, Boris Beizer, in Software Testing Techniques attributes some of the wide differences in estimates to “Creative Accounting”. Most programmers are creative accountants. For example “Analysis is over when the time runs out”. Since analysis products are less demonstrable, it’s possible to declare the analysis over whenever it is expected to be done. Then they put their heads down and program, and when forced to finally turn in their time sheets they guesstimate the hours they spent in each activity. Part of the programmer’s development time is spent in unit testing, and this is usually counted in the testing figures. In many cases, testing is an integral part of the programming process and so should not be counted as part of testing. In fact, the best computer programmers intertwine unit testing with coding so intimately as to be indistinguishable. Testing and debugging statements are coded as part of the logic coding and the overall testing strategy partially shapes the structure of the program. This testing is, or should be, part of the programming process and is problematical to account for separately. In fact, a programming manager can usually gain instant gratification by changing the allocation of time between programming and testing. Just tell a programmer “You aren’t spending enough time testing” based on the time sheet and you can be sure next week the time sheet will show more time testing. Nothing else will have changed, of course, just the number of hours reported on the time sheet.
There are also differences as to what is included in system testing. In traditional “waterfall” projects, the system is developed to a certain stage, and then the testers are called in and the “testing and debugging” phase begins. All work after that point is generally counted as part of testing. Inevitably some of the development work that was not finished in the earlier phase will spill over the waterfall into this phase and be counted here. And some of it is inevitably spent building new functionality identified in the testing phase. Had this new functionality been identified earlier, it would have been done, and counted, as part of programming, not testing. This method of time accounting also has the unfortunate effect of causing more time to be attributed to testing when testers become involved earlier, as by definition, the testing phase begins when the testers start testing. In the best practice scenario, testers would be involved in the project from the beginning, and so all development time would be part of the testing phase. So if you are in charge of a project you’ll need Zen in addition to status reports to discover the true state of the project. Take care to illicit honesty in reporting and don’t push the team into creative accounting where everything is right on track until time for implementation when you discover you’re weeks behind.
We know there are many ways to the mountaintop. Unfortunately there are many more fruitless than fruitful ways. George Mallory famously said, when asked why he wanted to climb Mt. Everest: “Because it is there!” It’s still there, and so is he. Mallory never returned from his quest, and his body lies on its slopes to this day. He was last seen alive on June 8, 1924 climbing toward the summit into the clouds with his companion, Andrew Irvine, and it is an open question whether he reached the summit.
On May 29, 1953, Sir Edmund Hillary, accompanied by a Sherpa, Tenzing Norgay, reached the top. Which leads to the debate: was Mallory or Hillary the first to successfully climb Mt. Everest? Mallory’s advocates have argued his skills and psyche indicate he would have made it, and have scoured the slopes for clues, attempting to find any scrap of evidence in his favor.
The debate is silly. Hillary was the first to successfully climb Everest. Because in my book, by any measure, if you die in the process, you don’t have a successful climb! Any endeavor that kills you is a failure, end of discussion!
If You Die on the Way down from the Mountaintop,
It’s not a Successful Climb.
The dot.com bombs are an excellent example of not grasping this principle. If you end with a bankrupt company, a ruined marriage, or a destroyed career, you didn’t succeed no matter how well you did technically. By the way, if you find yourself on the project from hell, you might want to read Into Thin Air by Jon Krakauer. It’s an account of a disastrous attempt to climb Mount Everest in March 1996; a number of the climbers who reached the summit died on the mountain that night. There are some real lessons on poor planning, letting objectives become overpowering, and generally how things can go wrong. You’ll think your project isn’t so bad, after all.
Copyright ©2003, 2008 Patrick McDermott