Slashdot Mirror

Sounds like just about every failed IT project. Rush to market, ignore test failures, probably a thermocline of truth.

From what we've been hearing, somebody in the chain of command between the inattentive driver and the CEO, deliberately created this situation and should be charged with manslaughter.

The single biggest predictor of project success/failure is the quality of the people involved.

However, most firms are bad at recruiting and maintaining top-quality people. Often, they chase the best ones away, resulting in the Dead Sea Effect.

Finally, "In starting a new software program, all the important mistakes are made on the first day." (The Art of Systems Architecting, Maier & Rechtin). ..bruce..

The single biggest predictor of project success/failure is the quality of the people involved.

However, most firms are bad at recruiting and maintaining top-quality people. Often, they chase the best ones away, resulting in the Dead Sea Effect.

Finally, "In starting a new software program, all the important mistakes are made on the first day." (The Art of Systems Architecting, Maier & Rechtin). ..bruce..

http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/

That was posted 2008, and was old news then. Good staff leaving is always the fault of the company. Keeping good staff interested and engaged is not trivial, but it's financially worth it in the long term. Problem is most companies don't care about the long term.

I didn't know Jobs well, but I did have a number of direct conversations with him, sat in on meetings at NeXT with him, spent five years developing software for NeXTstep, and had many talks with people who worked closely him (again, mostly at NeXT); our last conversation was him calling me up to yell at me for an op-ed piece of mine in BYTE (Nov 94) called "Whither Nextstep?"

With that tee-up, I'll say that Fassbender's portrayal of Jobs in this trailer pretty much falls flat. Fassbender looks too professional and lacks that burning gaze that Jobs used to such great effect, even while using up the people around him. Frankly, Fassbender comes across more like John Scully trying to act like Steve Jobs than like Jobs himself. Also, it took me a bit to realize that Seth Rogan was supposed to be playing Woz; again, the wrong vibes and aura. Frankly, I think that Jack Black with a beard would have been a better choice for Woz. ..bruce..

3) When a bunch of co-workers start leaving a job or the very best ones in your department start to leave, it's probably time for you to consider leaving too.

Hence, the Dead Sea Effect". ..bruce..

Having built a long-term development team from scratch, and having screened a lot of consulting software engineers, I eventually came up with an acronym that describes what I look for: Talent, Experience, Professionalism, Education, Skill (TEPES). I wrote a post on the subject back in 2008 -- you can read it here. ..bruce..

Eight years ago, Ruby Raley and I published (in Cutter IT Journal) an article entitled "The Longest Yard: Reorganizing IT for Success" (you can read it here). Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better. Having spent 20 years analyzing troubled or failed software projects, I believe we need a significantly different approach on hiring and retaining the right IT engineers. ..bruce..

Eight years ago, Ruby Raley and I published (in Cutter IT Journal) an article entitled "The Longest Yard: Reorganizing IT for Success" (you can read it here). Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better. Having spent 20 years analyzing troubled or failed software projects, I believe we need a significantly different approach on hiring and retaining the right IT engineers. ..bruce..

Eight years ago, Ruby Raley and I published (in Cutter IT Journal) an article entitled "The Longest Yard: Reorganizing IT for Success" (you can read it here). Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better. Having spent 20 years analyzing troubled or failed software projects, I believe we need a significantly different approach on hiring and retaining the right IT engineers. ..bruce..

The article was called "The Real Software Crisis" (BYTE, January, 1996); you can read the original text here. (BYTE's archives are no longer online). I wrote a more extended discussion on the subject back in 2008; you can read it here. One might was well write that "normal humans are effectively excluded from composing and performing music"; if you've ever known a music major in college, you'll know just how true that is (I believe Music to be a harder major than Computer Science, having dated a Music major while getting my own degree in CS). ..bruce..

The article was called "The Real Software Crisis" (BYTE, January, 1996); you can read the original text here. (BYTE's archives are no longer online). I wrote a more extended discussion on the subject back in 2008; you can read it here. One might was well write that "normal humans are effectively excluded from composing and performing music"; if you've ever known a music major in college, you'll know just how true that is (I believe Music to be a harder major than Computer Science, having dated a Music major while getting my own degree in CS). ..bruce..

That's called the dead sea effect - the people with mobility evaporate, leaving the office stuck with the workers who can't leave.

Seems to be a clasic case of the Themocline of Truth. http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-themocline-of-truth/

I'd say that the transition from bad news to good news usually happens at a single level of management.

This is a well known scenario called the dead sea effect.

Any talent left behind will be so stressed, bitter and tired that they won't be half as productive as they used to (they will have figuratively quit while they wait to find something better).

It is very likely the talent that you mention should be quoted (as "talent"): an explanation here (the most mobile talent - the one it's likely you would want to have - will evaporate earlier).

Ahh the old thermocline of truth. http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-themocline-of-truth/

Any management that tries these techniques needs to be fired by the shareholders immediately. The people who leave voluntarily when pushed by these types of harassment are always the most valuable ones, who funnily enough find it easy to get a job elsewhere. The ones you're left with are the ones who are pulling you down in the first place (along with the management team, who are obviously deficient if they think reducing headcount is all that matters in saving their ass).

It bears a name: it's called Dead Sea effect.
After a while, you know for sure which employees you don't want to have: the ones that are still with you... So the best you can do: fire them and close the business.

Interesting. I was thinking it reminded me of the Peter Principle, which states that an organization's staff will continue to be promoted until they exceed their level of competence. But the Dead Sea Principle is more apt to this case. If stated in a parallel way, it might be rendered: staff will migrate between organizations until their coworkers exceed their level of competence. The slashdot article to which you refer actually links to this article by Bruce F. Webster, where he briefly compares the two principles.

Oh, I more than approve of that. :-) I've played both the Apple II and the Atari ST versions on Windows-based emulators and used to have links to both on my website. I should probably put those up again.

For those wanting a bit more background: http://brucefwebster.com/past-projects/sundog/

Having built a software development team from scratch for a venture-funded startup, and having done tech vetting for years on consultants, I fully understand the difficulty in determining who's actually talented and who isn't. But I just don't buy that the 'puzzle' approach translates into 'great software engineer'. You may well get a bunch of bright and clever people who are good at puzzles, and it's good to have some folks like that around, but I suspect if everyone is that way, you'll end up with a bunch of engineers trying to out-clever each other -- and that doesn't translate into well-designed and readily-maintained software. IMHO. ..bruce..

(What do I think is necessary? See here and here.)

Having built a software development team from scratch for a venture-funded startup, and having done tech vetting for years on consultants, I fully understand the difficulty in determining who's actually talented and who isn't. But I just don't buy that the 'puzzle' approach translates into 'great software engineer'. You may well get a bunch of bright and clever people who are good at puzzles, and it's good to have some folks like that around, but I suspect if everyone is that way, you'll end up with a bunch of engineers trying to out-clever each other -- and that doesn't translate into well-designed and readily-maintained software. IMHO. ..bruce..

(What do I think is necessary? See here and here.)

For your boss to try to dictate how you work like this is a form of micromanagement which demonstrates distrust.

Brush up your resume, in my experience managers who act in this fashion tend to get worse, not better. Working there is going to be an exercise in frustration. That said, a company is wholly within its rights to expect something like this of you. But by doing so they make themselves less competitive and attractive. Maybe they can get away with that for now, but in doing so they're destroying loyalty and directly contributing to a Dead Sea Effect - when the economy picks up the decent developers are going to evaporate, and the company will be left with a brackish collection of sub-par developers.

As to the original question, I find that the right music selection can really help with my code quality and speed. If I'm really ramped up on what I'm working on, a good fast paced techno, industrial, or otherwise highly rhythmic repetitious and fast paced music can contribute to a mental wave to surf. If I feel like my project pace is overly frenetic, there are too many expectations, and there's just really no way I'll meet all the obligations in the time allowed, something slow and soothing can bring down the blood pressure levels and let me concentrate on my work better.

YES, already! That's his freaking career.

Another clumsy, cynical attempt to pander to the geeks. Totally disingenuous. "Independent of one's personal opinions", my ass. Lying: bad. It's pretty simple, really.

So what if he gets invited to speak on IT issues. Nothing there says he is paid, and even if he was, it's only fair compensation for his time and travel expenses. Furthermore, if you read his personal bio you'd see that the dude was a democrat until 2008. Most of his opinions on stuff seems to be further left than you'd expect. It hardly seems that he even opposes 3200 at all. He just seems to want it done right. And you point out his previous article on the bank bailout with a "HAHAHAHHAH". Need I remind you that plenty of liberals were upset with the bailout when it happened. Even if all the things you said about this guy were true, it's still ad hominem. You're not addressing his arguments at all.

Deceptive bullshit is deceptive bullshit.

Where is anything deceptive? Are you claiming that he was paid to write that blog? Where is your evidence of that?

Pointing that out doesn't make anyone "far left". Your perspective is so skewed... I'm not far left, I'm normal, which makes you a fascist or easily manipulated.

Lol. Sorry. I'm a libertarian. There are more political directions in this country than D/R.

YES, already! That's his freaking career.

Another clumsy, cynical attempt to pander to the geeks. Totally disingenuous. "Independent of one's personal opinions", my ass. Lying: bad. It's pretty simple, really.

Deceptive bullshit is deceptive bullshit. Pointing that out doesn't make anyone "far left". Your perspective is so skewed... I'm not far left, I'm normal, which makes you a fascist or easily manipulated.

Astroturf is not a hollow word, and this submission is a perfect example of it. How can I tell you that you're being manipulated by people who care nothing about you, without suggesting that you're an idiot? You may or may not be an idiot, but if you're being genuine (maybe? can't tell), you've definitely been misled. Your well-being and an insurance company's interests most likely have nothing in common. Ask yourself why you care about their margins.

Of course, if you really really want to turn your country into a Dickensian novel, and you're in the majority, I suppose I don't have much say in the matter. I just wanted to point out that it's stupid. Also you're not in the majority. And most of your ideology's policies have been failures.

Maybe you should stop trying to sabotage your country for politics. Just a thought.

I did RTFA. And his bio (he's one of those morally bankrupt court "experts"), and his crappy blog.

It's hard to see whether he's taking an opinion in any given political direction.

BWAAHAHAHAHA!

Your comment confirms that it is indeed astroturf.

I've testified before Congress three times and have provided private technology briefings to US House and Senate staff members working on legislation, so I do have some experience with how legislation works. I've also worked with state legislators on technology-related legislation.

Not all legislation is like HR 3200, but that doesn't obviate my arguments one way or the other. I fully agree that a lot of legislation is like HR 3200, which is why we have a lot of the mess we do. Had I written this post several years ago, I could have (and probably would have) applied the same analysis to the Patriot Act or the effort to create the Department of Homeland Security (both of which I had and have serious qualms about).

Having done large scale systems evaluation and design for many years, I am a firm believer in Gall's Law: the only way to create a large, complex system that works is to evolve it from a small, simple system that works. The majority of large-scale system re-engineering efforts fail, are crippled, or underperform because they try to skip that step. In my observation, much the same happens with large-scale legislation.

Finally, I don'twant an argument on health care reform or HR 3200 at my website. What I'd like is thoughtful feedback on the general concept (legislation as systems architecture) from people who actually know what they're talking about. ..bruce..

P.S. A good book to read would be The Art of Systems Architecting (2nd ed) by Maier and Rechtin. They treat systems architecting as spanning many disciplines, including social systems (Chapter 5).

I'm only semi-facetious in saying that. I never liked puzzle games because (a) they pretty much require that you read the game designer's mind, and (b) they are almost always what my co-designer Wayne Holder called (derisively) "railroad games" -- that is, you're stuck on the tracks and you can't get off. Also, (c) the "puzzles" are often pretty arbitrary, having little to do with the game itself.

But in the early days of computer games (and my own days go back to the early 1980s), puzzles were a cheap form of complexity precisely because graphics, UI and presentation were so hard and consumed so much of the limited resources.

I frankly think that most "modern gamers" are heaving great sighs of relief at being rid of "puzzle games" and being able to play something else for a change. But that could just be me. ..bruce.. (co-author, Sundog: Frozen Legacy )

If my server ever recovers, go look at this earlier post defining and discussing the "thermocline of truth". ..bruce..

I'm not sure how carefully the manager you quote read my post, since some of your 'quotes' are wrong (as well as the apparent assumptions as to my own role), and some of the manager's responses are non sequiturs.

I was brought in from the outside specifically to conduct a review and summarize my findings in a memo for one specific person in upper management at BigFirm who was above the FUBAR project and who had grave concerns about it, given that at that point the project was years late and millions over budget, and which showed few signs of making it into production anytime soon.

I was not one of the "coders" -- I was not even a project member -- and I certainly wasn't a "new kid out of college"; I graduated with BSCS in 1978; my first programming languages were 360 assembly, PL/1 and FORTRAN, and by the time I conducted this review, I had personally done professional software engineering (including project management, architecture, and consulting) in a wide range of operating systems and programming languages over quite a few fifferent industries.

The ABC consultants, to a person, were likewise very senior software engineers with many years of hands-on coding experience and well-established track records of successful project delivery.

I'm surprised that an IT manager doesn't know what "very fragile code" means. "Fragile code" means that efforts to modify one section of code -- to fix a bug, add functionality, or improve performance -- frequently results in the code "breaking" elsewhere, usually in multiple places. The opposite of "fragile code" is "robust code".

The memo states clearly that previous architects had left (not "project managers"); the problem was that the FUBAR project manager (with no technical background) kept driving them off and, as the memo notes, fancied himself a software architect.

The syndrome of "kingdom building" through increased head-count has long been a major cause of IT project failure; in this case, there were far too many programmers than the problem actually required.

As for my "amateur" status, I'll simply point here; is the manager willing to do the same? (Sorry about the server problems; I'm raising hell with my hosting service, given what I pay each month for a dedicated server.) ..bruce..

Thanks for all the great comments, though I suspect many of you didn't ready anything more than the brief extract posted here at Slashdot. :-) Because certain themes keep coming up again and again, I thought I'd address them in a single post (I also posted this over at my website).

Here's a response to the main themes that I see coming up there.

The Dead Sea effect isn't unique to IT. True enough, though I could say the same thing about just about any project management issue regarding IT. What is unusual about IT (shared with other engineering disciplines) is the degree to which individual talent and other factors affect productivity and quality. And what is unique about IT (as opposed to, say, civil / mechanical / chemical engineers, architects, etc.) is that there is no standard (state-run) professional certification, so there is no assurance of minimum education and competency.

This is obvious/common sense/trivial. So are most of the problems in IT. Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven't all gone away! There is a profound lack of professional and institutional memory in IT; almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.

The Dead Sea effect is just the Peter Principal (or a corollary thereof). No, it isn't. The Peter Principal is that a given person rises to her/his level of incompetence (I'm actually old enough to remember when 'the Peter Principal' first came out). This has nothing to do with promotion within the IT organization; it has to do with self-selected removal from that IT organization, not due to a lack of promotion or opportunity, but just because there are greener pastures elsewhere.

Not all IT shops are like this . I would certainly hope so. In fact, there are IT organizations where just the opposite occurs; the quality of the IT engineers is quite high, and engineers who are mediocre or disruptive either don't get hired or don't last long if they are. I worked in one such IT group (Pages Software) for five years. During that time, we had only one voluntary departure (the network admin); we had two others who were dismissed due to problems, and a few others who were (painfully) cut in downsizing.

Not everyone 'left behind' is incompetent . Again, this syndrome doesn't apply to all IT groups, and it doesn't apply to the same extent to all IT groups. Turnover in IT personnel is common (though it can be reduced by intelligent management), and just because good engineers have left a given IT group doesn't mean that the rest are, in fact, residue. What I'm talking about here is a very real syndrome, typically found in large corporations and government organizations, but it's certainly not universal.

The IT hiring process is broken. Amen. Not only is the IT hiring process broken in many organizations, the entire approach to IT is often broken. It is rife with empire-building, 'heroic' project management, and an 'interchangeable code monkeys' mindset. As mentioned in the comments

Thanks for all the great comments, though I suspect many of you didn't ready anything more than the brief extract posted here at Slashdot. :-) Because certain themes keep coming up again and again, I thought I'd address them in a single post (I also posted this over at my website).

Here's a response to the main themes that I see coming up there.

The Dead Sea effect isn't unique to IT. True enough, though I could say the same thing about just about any project management issue regarding IT. What is unusual about IT (shared with other engineering disciplines) is the degree to which individual talent and other factors affect productivity and quality. And what is unique about IT (as opposed to, say, civil / mechanical / chemical engineers, architects, etc.) is that there is no standard (state-run) professional certification, so there is no assurance of minimum education and competency.

This is obvious/common sense/trivial. So are most of the problems in IT. Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven't all gone away! There is a profound lack of professional and institutional memory in IT; almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.

The Dead Sea effect is just the Peter Principal (or a corollary thereof). No, it isn't. The Peter Principal is that a given person rises to her/his level of incompetence (I'm actually old enough to remember when 'the Peter Principal' first came out). This has nothing to do with promotion within the IT organization; it has to do with self-selected removal from that IT organization, not due to a lack of promotion or opportunity, but just because there are greener pastures elsewhere.

Not all IT shops are like this . I would certainly hope so. In fact, there are IT organizations where just the opposite occurs; the quality of the IT engineers is quite high, and engineers who are mediocre or disruptive either don't get hired or don't last long if they are. I worked in one such IT group (Pages Software) for five years. During that time, we had only one voluntary departure (the network admin); we had two others who were dismissed due to problems, and a few others who were (painfully) cut in downsizing.

Not everyone 'left behind' is incompetent . Again, this syndrome doesn't apply to all IT groups, and it doesn't apply to the same extent to all IT groups. Turnover in IT personnel is common (though it can be reduced by intelligent management), and just because good engineers have left a given IT group doesn't mean that the rest are, in fact, residue. What I'm talking about here is a very real syndrome, typically found in large corporations and government organizations, but it's certainly not universal.

The IT hiring process is broken. Amen. Not only is the IT hiring process broken in many organizations, the entire approach to IT is often broken. It is rife with empire-building, 'heroic' project management, and an 'interchangeable code monkeys' mindset. As mentioned in the comments

I have served repeatedly over the past 9 years as an expert witness in technology-related litigation (including intellectual property cases), which means that I have analyzed (and, as required, rebutted) many expert reports and written quite a few of my own. Here are my observations:

-- Expert testimony in federal court (and for the most part, in state courts and arbitrations) is largely governed by several federal court decisions (Daubert v. Merrell Dow, Kumho Tire v. Carmichel) that require the judge to act as a 'gatekeeper' in deciding what expert testimony to allow or exclude. Much of Dr. Pouwelse's criticisms are aimed at the Daubert/Kumho standards, including qualifications and methodology, with an eye towards having these reports (and possibly Dr. Jacobson's testimony at trial) excluded.

-- Not having Dr. Jacobson's four reports/declarations, I can't critique them directly. However, the admissions by Dr. Jacobson during deposition that he spent only 45 minutes on his April 2006 report would appear to be pretty damaging. Even the briefest report I've ever written has taken at least several hours to put together, and I'm a fast writer; in most cases, it takes me anywhere from 40 to upwards of 100 hours of research, analysis, and writing to put together an expert report. Likewise, the 15 minutes on the December 19th declaration seems pretty short as well. This would naturally raise questions in the judge's mind whether Dr. Jacobson did his own research and writing and how well founded the reports and declarations are.

If someone has Dr. Jacobson's reports and declarations or has a link to them, please feel free to send them along, and I'll take a look at them directly. ..bruce..

Still, most people in the 40s and 50s just don't have time for computer games. Between family, work, church/community and other activities (yardwork, household repairs, struggles to get to the gym, etc.), they typically don't have the amount of free time required by most modern computer games. I work out of a home office on a consulting basis, so unless I'm swamped by current engagements, I can easily block out several hours to spend on a game. However, there have been other times in my life when I've had a 'regular' job; during those times, I've gone months or years without playing a computer game for the reasons cited above.

Another downside for older gamers is that the 'costs' of spending lots of time on games are higher--e.g., it can interfere with work (and income), can cause serious marital problems, and so on. I know a man in his early 30s whose marriage is undergoing severe stress largely because of his obsession with HalfLife 2. In my own case, I have from time to time simply thrown away games because I felt I was wasting too much time playing them and not enough time on other projects (books, etc.).

My own preferences tend to be strategy/simulation games, including historical war games and large-scale strategy games (the Civ games and various space-based 4x [eXplore, eXpand, eXploit, eXterminate] games). I tend to prefer turn-based games over real-time strategy (RTS) games, but have still spent time with the latter (e.g., LOTR: Battle for Middle Earth). I've played several RPGs (e.g., DungeonSiege, Neverwinter Nights, Freelancer) and even some MMORPGs (Earth and Beyond). While first-person shooter (FPS) games are not my first choice, I'll cheerfully play them if the subject matter is interesting; I've bought and played several of the Star Wars FPS games (Republic Commando, Battlefront I and II).

Were I to design for 'grey gamers', I would probably focus on the following:

• Design for short play cycles (30-60 minutes at a time); consider your competition to be an individual TV show.
• Provide easy exit from the game and easy re-entry.
• Emphasize analysis and thought over reflexes.
• Avoid fiendishly difficult puzzles or tasks; we just don't have the frackin' time.
• Allow saves (and restarts) at any point; same reason.
• Design for PCs, not for game consoles

Beyond that, I'd apply some of my own preferences on game design:

• Emphasize game design before eye candy.
• Avoid "railroad" games (i.e., the player is stuck on the rails and can't get off).
• Allow many paths and solutions, including ones you as the designer might not have thought of.
• Avoid arbitrary roadblocks and limits (usually put in to make the designer's job easier).

FWIW. ..bruce..

Still, most people in the 40s and 50s just don't have time for computer games. Between family, work, church/community and other activities (yardwork, household repairs, struggles to get to the gym, etc.), they typically don't have the amount of free time required by most modern computer games. I work out of a home office on a consulting basis, so unless I'm swamped by current engagements, I can easily block out several hours to spend on a game. However, there have been other times in my life when I've had a 'regular' job; during those times, I've gone months or years without playing a computer game for the reasons cited above.

Another downside for older gamers is that the 'costs' of spending lots of time on games are higher--e.g., it can interfere with work (and income), can cause serious marital problems, and so on. I know a man in his early 30s whose marriage is undergoing severe stress largely because of his obsession with HalfLife 2. In my own case, I have from time to time simply thrown away games because I felt I was wasting too much time playing them and not enough time on other projects (books, etc.).

My own preferences tend to be strategy/simulation games, including historical war games and large-scale strategy games (the Civ games and various space-based 4x [eXplore, eXpand, eXploit, eXterminate] games). I tend to prefer turn-based games over real-time strategy (RTS) games, but have still spent time with the latter (e.g., LOTR: Battle for Middle Earth). I've played several RPGs (e.g., DungeonSiege, Neverwinter Nights, Freelancer) and even some MMORPGs (Earth and Beyond). While first-person shooter (FPS) games are not my first choice, I'll cheerfully play them if the subject matter is interesting; I've bought and played several of the Star Wars FPS games (Republic Commando, Battlefront I and II).

Were I to design for 'grey gamers', I would probably focus on the following:

• Design for short play cycles (30-60 minutes at a time); consider your competition to be an individual TV show.
• Provide easy exit from the game and easy re-entry.
• Emphasize analysis and thought over reflexes.
• Avoid fiendishly difficult puzzles or tasks; we just don't have the frackin' time.
• Allow saves (and restarts) at any point; same reason.
• Design for PCs, not for game consoles

Beyond that, I'd apply some of my own preferences on game design:

• Emphasize game design before eye candy.
• Avoid "railroad" games (i.e., the player is stuck on the rails and can't get off).
• Allow many paths and solutions, including ones you as the designer might not have thought of.
• Avoid arbitrary roadblocks and limits (usually put in to make the designer's job easier).

FWIW. ..bruce..

Of course, having extracted all that I can extract, and facing a move cross-country, I am now contemplating getting rid of the Apple II gear--but part of me just doesn't want to let it go just yet. ..bruce..

P.S. You can see the main loop of the SunDog program here.

Of course, having extracted all that I can extract, and facing a move cross-country, I am now contemplating getting rid of the Apple II gear--but part of me just doesn't want to let it go just yet. ..bruce..

P.S. You can see the main loop of the SunDog program here.