Slashdot Mirror

I recently realized that, with the exception of Final Fantasy 9 (which is more of a story), I haven't played any games in a long time. "What am I doing?" I thought. I then realized that I was playing games, just other types of games: How can I help the Free Software movement, How can I maximize my contribution to society and self, how can I promote, learn about, and work on, groupware. Learning is also another type of game, that I play.

What's common to games? I liked the definition I read on the WorldForge project page: You've got a goal, you've got obstructions, and you try to meet the goal through the obstructions. And, that description matches the games that I play, video-game or otherwise (contributing, learning, etc.,.).

Now the question is: What seperates a game from Work? The description above seems to also describe work rather well. Almost by definition, I hate work, but I love games (Cosmic Encounters, for name-dropping). So what's the difference? For this, I draw on Taoism, that book "Flow" (John Carmak recently referenced it), and Miyamoto-sama, who emphatically repeated at GDC 1999 that the game-playing experience must be "comfortable". Perhaps the only difference between work and a game is that the game is comfortable, whereas the game is, well,... Work. I'm still working on this definition. (Mary Poppins said that with a spoonful of sugar, you just snap, and the job's a game. While I like this idea, I have trouble in the impementation; perhaps I'm just not snapping my fingers correctly. Maybe I need to meditate more.)

Given this description, what are the types of games that I'm interested in playing? Personally, I'm really interested in games that cross-over into the domain of my livelihood, and the livelihood of others around me. I'd like the principle of game-ness to shove out work-ness from my life. I wouldn't fret if work completely disappeared from my life. Computers fit the bill rather well. I've always considered the operation of computers to be something of a game, since I was a wee little one, and I've always had an intuition that it would pay the bills. (That intuition turned out to be right.) But still, there's a lot that's uncomfortable about it. It's just like when you're in the maze, and all the doors are locked, and there isn't a key in sight. You're absolutely stuck. You were slated to finish a programming task in 2 days, and it's taken you 2 WEEKS, and you still don't know how you're going to get out of it. This is an uncomfortable situation, and draws me out of the realm of the game, into the realm of work. Ugh. And I was trying so hard to get out of that realm. Where am I going with all of this? Well, I'm trying to establish the similarities and subtle differences between work and games, and then I'm trying to segue into how I think that we can structure things so that work can become more like a game. My ultimate goal is to get feedback from you, build interest in the subject, and have you send me links and other references to related lines of thought.

So, I've found this neat way of teaching that can make a game out of learning. It gives you immediate positive rewards, it helps out in the world (because you learn a valuable skill), and you don't get stuck with no keys and lots of locked doors, because it has a built in help line, that you can call on and get a quick piece of help.

The way I found I learned from Philip Greenspun. He uses problems and a community system as integral parts of the ArsDigita training program. It works like this: You have a number of problems, in gradually increasing difficulty, that the learner tackles. Lecture is rather secondary to the problem statements themselves. Lecture is useful, in so much as it helps with the problems. The problems are rather UNIX-like in that the goal is to teach the student one thing, and teach it well. Anyways, I've been working on installing the ACS, and it's been going well so far. Whenever I have a problem, I go to the web bulliten board, search for the problem. Most likely someone had it before, and I get the answer there. If not, I write an entry to the list, and within 5-15 minutes, get a reply. (Once I had to wait 6 hours, though...) The reply then goes on to the board, so that others can get the solution as well. In fact, it's like this with most of our online systems, except that the response time isn't as small, you have to sort through google entries, and usually you have to subscribe/unsubscribe to/from mailing lists, etc., etc.,.

Anyways, I've tried out the method of problem guides in the Fledging Unix Programmers class that I teach, and it's had excellent results. Problems show up when the difficulty between problems is too high, so I subdivide those intervals. It works great.

But what I'm really looking for is for other people to do the same thing.. There are a lot of times in my life where I have 2-3 hours spare, and I'd like to play a game in that time. I'd like a good set of 3-5 problems, workable within 2 hours total, that increase my knowledge about the Linux Kernel, PHP, How to use databases, link things up, make a small game, play with networking, etc., whatever. Do you know what I mean? (Please answer.) So what I'd like to have is, not so much HOW-TO's, but PROBLEM-GUIDE's. And support lines consisting of other people who are interested in the subject, and have completed the guides themselves. Well balanced problem guides. That way, I can play games on a daily basis that are comfortable, educational, and most importantly, fun.

"One of the best fundamental principles that anybody ever expressed to me about game design is that games should teach you how to play them."

Mostly because it's worth a hundred or so dollars an hour for me not to have to worry about the details. I'd much rather spend my time trying to create, innovate, and do, instead of waste tons of my time and mental energy staying out of jail -- how fortunate that I can just hire someone to take care of that! Meanwhile I can make hundreds of dollars an hour programming (which I'd prefer to be doing in the first place) with all that saved time.

Of course, since a lot of people are greedy, incompetent, or mean, and lawyers are a subset of "people", you'll see plenty of bad lawyers. The trick is to find a good one.

Noone negotiates without one, noone seems to be able to manage at all in the business world with out one.

Perhaps this is because everyone else thinks it's worth their while (and money) to have access to the knowledge and pattern recognition of someone who's seen thousands of legal situations in action and knows all the gotchas to look out for. I'm not personally going to be able to (much less want to) keep track of all that and still do everything else I'm interested in.

Some people do go to court and represent themselves, and do fine. See the ever-verbose Philip Greenspun's pages for one such account. Philip's also poked around a little at computer-aided litigation, which is a concept you might be interested in as well.

This model is flawed, its not only self perpetuating, but brings great riches to one sector of the community(legal that is) while sucking dry all others, including individuals.

How is this different from any service provider? Change "legal" to "programmers" and it still sounds about right. One of the effects of capitalism is that money flows to those who posess a unique advantage; in this case, knowledge of the law, or knowledge of programming. Lucky for you, it is easier in this society than in most to acquire a unique advantage (just file a patent application... haha, jk).

It is quickly becomming obvious that the US has more laws then it does justice, the patents issue seems to derive straight from that, patents arent really a method of protecting profits, they are an excuse to sue when someone copies your design.

Well, yes on both: patents are a method of protecting profits (the "unique advantage" part), and they are thus an excuse to sue when someone copies your design; otherwise, there goes your unique advantage and hence ability to make money.

Now, agreed, there are a load of problems in the present patent system; "submarine" patents that are secretly filed and then, when granted, used to pull the rug out from under those who've indepentently invented and implemented the invention on a large scale.

Note I said when, not if. Especially in the case of patents on current widespread technologies, that multiple companies are producing.

Again, that's a problem in the implementation of patents, not the theory. "Ordinary skill in the art" and all that. Definitely needs fixing.

The result is a legal community run amok, growing fat and rich on a culture that seems to not want to fix this ability to sue everything that crawls or walks.

Now you're just ranting. Lawyers didn't make these rules; politicians did. Your politicians. Lawyers get paid by people to make the law work in their favor as far as possible.

And don't forget why corporations often appear so greedy -- publicly traded companies (like, say, RedHat) are legally required to maximize shareholder investements, and thus profits. A company's leadership is being legally negligent if they don't go after opportunities that might come up, like ease of getting patents. Don't like that? Change the laws.

So wtf is your solution I hear you snarl?

I'm not snarling. The solution is obvious; change the system. It's happening with the music industry -- piss off enough AOL users who want their Napster and, whaddya know, their congresscritters start changing laws and putting pressure on the recording industry.

If the price of freedom is the blood of patriots, and every civilization needs a little revolution now and then, the next revolution will be fought by lawyers, and the only blood spilt will be that of their clients wallets.

Surely you regard this as an improvement? Or is it only other peoples' lives that you hold so cheap?

Peace out,

Not in my lifetime. Nor anyone else's. This sounds like the same mistake that Bill Gates made.
--
Paul Gillingwater

I'd also point out Philip Greenspun's scorecard.org, a clearing house for environmental data. It's a very accessible, data-rich site that might be a sort of model for things a government data-distribution site could do.

by Philip Greenspun (philg@mit.edu)

Submitted on: 2000-10-22

ArsDigita : ArsDigita Systems Journal : One article

Philip Greenspun founded ArsDigita Corporation and was its CEO from inception until it reached $20 million/year in revenue. Currently, he is Chairman of ArsDigita and teaches computer science at the Massachusetts Institute of Technology. Why an article on managing people? And one written by someone with training in computer science rather than business administration? There are thousands of books on the best ways to manage people. Many of these books are excellent, having been written by people who've devoted their lives to the discipline.

Software engineering is different.

Software engineering is different because only the best people significantly contribute to achievement. Traditional management texts assume a distribution of talent among the workers. Each worker is contributing something useful and the challenge is to get each one to perform at his or her maximum potential. In the same factory, the best worker may produce two or three times as much as the average, but all the workers are contributing. In software engineering a good programmer is at least 10 times more productive than an average programmer (Brooks 1995). If a product is being developed rapidly, the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers. Thus the challenges of a software engineering manager first and foremost are (1) creating a work environment where good programmers will be satisfied enough to stay, and (2) creating a system via which average programmers can become good. In an ideal software engineering organization, there are still some average-quality people but these should be viewed as being apprenticed to the best people and being taught as fast as possible.

Software engineering is different because people at all levels of the organization perceive themselves to be equally intelligent. Consensus-style management can perhaps work when there is a gradient of perceived ability. Given enough time, the less able workers will follow the lead of the more able workers. One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can expect to fall in line with a good strategy developed by someone else. As for the good programmers who are in fact supremely capable, there is no reason to expect consensus to form among them. Each programmer thinks his or her idea about what to build and how to build it is the best.

Software engineering is different because a leaf-node worker is more expert than any manager, even when the manager is a great engineer, in at least the small portion of the system that the leaf-node worker has personally built. This makes it difficult for a manager to engage in a technical argument with a worker. It becomes nearly impossible when the manager's technical skills are weak. The worker can spin castles of complexity in the air and come up with impressive-to-the-MBA excuses for why it has to be done a certain way or on a certain schedule.

Software engineering is different because the organization can't afford to lose the individual productivity of the best people by pushing them into management. A truly great programmer may generate 10 times as much business value as a merely good programmer. Can the organization afford to take someone who can do the work of 100 average programmers and push him or her into a pure management role? Probably not. Can the organization afford to put people with weak technical skills into management roles? Probably not. Once you give Joe MBA a title and ask him to coordinate eventually he will be making decisions that have engineering implications. Thus many of the best programmers are eventually forced at least to assume project leadership and mentoring responsibilites. Since they are still expected to produce designs, software, documentation, and journal articles, the danger is that the new manager will become glued to his or her screen and never look up to see how the project team is doing.

Software engineering is different because measurement is notoriously difficult. The world is full of products that failed due to overly complex and tasteless designs. Yet all of these designs were considered tasteful by their architects. Systems that experts evaluated and found wanting, such as the Unix operating system (1970), eventually proved to have great utility. It is a bit easier to count up the lines of code per day produced by a programmer but if the project was not very tightly specified originally, how do you know whether or not these lines of code are useful? At this point a skeptical reader might be thinking that, while software engineering is different from line production work or any other endeavor with a manufacturing division of labor, there are similarities with research and development, management consulting, and financial analysis. This is certainly true but there aren't too many interesting books on how to reliably produce results in these fields (one is referenced in the "More" section below). Ideas to Steal Software engineering is different but it is not that different. What ideas can we steal from the broader world?

• people don't do what they are told
• all performers get the right consequences every day
• small, immediate, certain consequences are better than large future uncertain ones
• positive reinforcement is more effective than negative reinforcement
• ownership leads to high productivity

people don't do what they are told In Bringing out the Best in People, Aubrey Daniels notes "If we always did what we were told, we would eat only nutritious foods, never drink too much alcohol, and exercise regularly." There is thus a natural limit on the effectiveness of written policies and management by telling then nagging.

A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded. Do the managers have an engineering background? If not, they'll probably be unable to perceive when a programmer is accomplishing nothing. So the programmer who does nothing gets a paycheck at the end of the month. Having thus been rewarded for doing nothing, the programmer tries it again the next month... all performers get the right consequences every day The natural way to manage is to spend time with people who aren't doing a good job. You help them out. You remind them of the good things that can happen to them if they finish a project or raise the spectre of their being laid off the next time the company needs to improve its profitability. These are probably the right consequences for someone who is underperforming. But what about the people who are performing? What if you ignore them day-to-day? Unless they are getting positive reinforcement from another source, they may stop coming in on the weekends to get a release out the door earlier, stop documenting their code, stop writing journal articles. A top performer won't sink to the level of a problem employee but that person may become average. And in the long run a company with average workers will at best earn an average return on equity. small, immediate, certain consequences are better than large, future, uncertain ones An annual review and bonus is not classically considered a very good way to motivate people. It is too far away, especially in a dotcom economy. Even if a worker is able to keep the bonus goal fixed in his or her head for the 365 days preceding the bonus allocation, there is uncertainty attached to it. What if the company is doing really badly at the end of the year? Will there still be a bonus? positive reinforcement is more effective than negative reinforcement Like most schools worldwide, MIT practices negative reinforcement at the undergraduate level. If student does not do a problem set by a certain deadline, we give him or her a bad grade. This has turned out to be extremely effective at ensuring that an MIT graduate has achieved some minimum standard. However, the students don't accomplish all that they could. The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before.

We thus proved the management adage that a deadline just gives someone an excuse to procrastinate and do nothing until the very end.

Graduate school at MIT is different. We want the students to do research, write up their results, publish them in journals, and graduate with a reasonably interesting PhD thesis. If a student finishes some research, the most effective faculty advisors immediately provide positive reinforcement by paying attention, helping design the next experiment, helping to draft a paper outline. If the student finishes a write-up, he or she is positively reinforced by being sent to a conference to present it. If the student finishes a PhD thesis, he or she is positively reinforced by being given a 3-7X pay raise.

The lesson from MIT? Negative reinforcement can work if the organization is extremely tightly managed, if the consequences are small and immediate (usually a problem set is due every week and only represents a part of the final grade), and if the goal is to make sure that everyone comes up to a reasonable level. However, the worldwide fame of MIT rests on research achievements by graduate students. This innovation is mostly supported by positive reinforcement. ownership leads to high productivity A related issue to positive/negative reinforcement is ownership. Non-ownership systems discipline those who are not working up to the minimum standard, but they do not offer enough of an upside to truly motivate people. Morever, non-ownership systems demand a very accurate setting of standards. Ownership-oriented systems include contingent rewards with an almost unlimited upside, and are thus effective at getting as much discretionary effort out of workers as possible.

As an example, in the early days of ArsDigita we had only a handful of customers: America Online, Environmental Defense Fund, Hewlett-Packard, Levi Strauss, Oracle Corporation, and Siemens. We had only a handful of programmers as well and hence the easiest way to divide the work was to give a programmer total responsibility for one project. The programmer owned that customer. If the project went well and the customer wrote us a big check, we gave nearly all of the money directly to the programmer. If any project had gone poorly and we'd been fired by a customer, we would not have had to think very hard to figure out who was responsible (fortunately this never happened while I was running the company!). People worked insanely hard to make their projects successful and their clients happy. More importantly, the programmer who did an entire project by him or herself learned enough to train new people, lead a larger project, etc.

After we grew beyond the 40-person mark, pressures to dilute the ownership aspects of our organization grew. We wanted to grow rapidly--nobody wants to buy enterprise software from a small company, even if the software happens to be open source. As our reputation grew, customers came to us with larger projects. We believed that many of our developers were too junior to handle complete responsibility for these large projects. Our costs went up because we had to coordinate the diffused responsibility. In the summer of 2000, when we had 200 or so employees, one of our clients was unhappy. It took a week just to arrange a meeting among the five managers who bore collective responsibility for the project! Meanwhile, individual productivity fell. It was taking more programmer-months and more calendar months to get things done. On weekend mornings you could walk naked through an entire floor of our headquarters building without fear of embarrassment.

(At the time of this writing, there is a proposal on the table to consolidate some of the separate management pyramids, thus taking us back closer to our original structure.) Building and keeping a good software engineering team What is the best way to attract some good software engineers to your organization? Hire a few to begin with. Good people like to work with other good people. This is true in every field but much more acute in software engineering. Why? Consider two management consultants working on different projects but within the same organization. If Consultant A does a bad job it harms Consultant B's reputation to some extent but does not require Consultant B to take any action. Whereas in most tech companies if Programmer A does a bad job it usually means that Programmer B will eventually be forced to use the bad code, read the bad code, and then fix the bad code.

What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important. Programmers have huge and fragile egos. If they are somehow assigned to a trivial problem and that is their only possible task, they may spend six months coming up with a bewildering architecture more complex than the Windows 2000 operating system, merely so that they can show their friends and colleagues what a tough nut they are trying to crack. Another source of ego-gratification for programmers is to have other programmers admiring their work. Open-source software projects thus have a big recruiting advantage over closed-source software companies.

What kind of working environment is necessary for programmer satisfaction? Good programmers want to achieve and therefore removing barriers to achievement is the most important step that one can take in creating an effective working environment. Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning. Maintaining this kind of freedom is a serious challenge as a company grows and its products become more complex. Successful companies such as Oracle Corporation burden their marketing departments with overlapping products rather than stifle programmer initiative. For example, during most of the late 1990s there were at least three different Web servers that you could buy from Oracle, each one backed up by a document explaining why it was the one true path toward database-backed Web site glory.

A good physical working environment is essential. Great programmers get a lot of positive reinforcement from their work itself. They write some code and immediately can see it dance. That keeps them at work for hours that, while they would not impress a taxi driver in Singapore or a factory worker in Guangzhou, will surprise many American business people. When we hired an architect to lay out the interior of ArsDigita's first building in Cambridge he surveyed the programmers and came back shaking his head: "I've never seen any group of people who spend so many hours continuously sitting at their desks."

From a business point of view, long hours by programmers are a key to profitability. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated.

Your business success will depend on the extent to which programmers essentially live at your office. For this to be a common choice, your office had better be nicer than the average programmer's home. There are two ways to achieve this result. One is to hire programmers who live in extremely shabby apartments. The other is to create a nice office. Microsoft understands this. In the early 1990s they did radio spots with John Cleese as a spokesman. One of the main points of the ad was to ridicule the cheap open-plan offices in which programmers were traditionally housed and promote the fact that at Microsoft each developer gets a plush personal office.

How can an office be nicer than one's home? Let's consider the following dimensions:

• social
• physical comfort
• aesthetic
• entertainment
• attractive

Social It is easy for an office to beat the home on the social dimension, especially if the programmer lives alone. If there are people at work at all times of day and night and you've succeeded in building an organization of good people, ipso facto there is always someone interesting to talk to at the office. To exploit fully the social possibilities of the programmers' office, it is important to have informal gathering spaces. At the MIT Artificial Intelligence Laboratory, which has nurtured groups of great programmers for nearly 40 years, the gathering spaces are referred to as "playrooms". These contain sofas and coffee tables, movable in the best tradition of Dewey, where programmers eat, talk, and occasionally listen to presentations. Usually a playroom will have some sort of shared writing surface such as a whiteboard. Note that these playrooms also are an important part of an organization's knowledge management system. You need to give programmers from different projects a place to meet where problems can be discussed and solutions from older/other projects can be suggested.

A social place will never be friendly if it is trapped behind a high wall of security. It ought to be very easy for a programmer to invite a friend over. If programmers are comfortable meeting their friends at the office it greatly increases the likelihood of friends recruiting friends.

An open office plan contributes to making the work environment stronger on the social dimension. Physical Comfort A programmer's work environment should be a supremely comfortable place to sit, look at information on a screen, and type. At ArsDigita we accomplish this via providing Aeron chairs, the keyboard of the programmer's choice, and at least two monitors. In the summer, the place should air-conditioned 24 hours per day, 7 days per week. In the winter, the office should be heated and humidified (often neglected). The air should be cleaned year-round with high-efficiency mechanical filters and electronic cleaners so that allergy sufferers are not discouraged from working.

One horrible mistake that we made was letting our architect design the workstations. Each programmer was given a 6'x2' desk, 12 square feet total. Two 21" monitors took up so much depth that there wasn't even room for a keyboard. Immediately we had to toss our monitors and get flat panels (cost about $400,000 extra). IBM had a better architect for its Santa Theresa facility: Gerald McCue. He found that each worker needed 100 square feet of dedicated space and 30 square feet of work surface. McCue also found that programmers needed noise isolation from enclosed offices or high partitions but personally we think this rule is worth breaking in a dotcom world where a team has to work fast and in sync. Better to manage noise by spreading desks apart a bit so that there are fewer programmers in a given area and therefore fewer conversations, fewer telephones, and more opportunities for sound to be absorbed before reaching someone's ear. Aesthetic Programmers don't have the same need for wood-paneled expensive plushness that, say, corporate lawyers or investment bankers might. However, the office has to be aesthetically satisfying or it will be tough for anyone to take seriously the idea that the company values aesthetic internal design of computer programs. Similarly, the office has to be finished and well-executed or nobody will believe that the organization is committed to finishing products. In the long run it is impossible for an organization to be excellent in one area and mediocre in all others. So the physical facilities have to look as though they were planned and decorated by someone with taste. Note that this need not be expensive. You could do it with $200 desks from Ikea and a consistent set of art posters on the walls. But an expensive facility with blank walls and boxes left over from the last move screams incompetence. Remember that the overall place has to look nicer than most of the programmers' houses. Entertainment It is easy to make an office more entertaining than the average person's home. Most people have a TV at home but they don't have friends with whom to watch it. Nor will they typically have the kind of big-screen equipment that is easy for a company to acquire. In the 1980s students at the MIT Media Lab would gather on quite a few nights to watch movies from analog laserdisks, presented with a very high quality projector. After the movie was over, they'd go back to their desks and work for a few hours, something that would not have happened if they'd gone out to the movies.

The average home cannot accomodate a pinball machine. An office can. The average home can have video games, which are very popular with young programmers, but not people with whom to play. The average home cannot have a grand piano but almost any office can. Attractive A worthwhile goal is to have at least one thing that is extremely attractive about the physical enivronment for any particular prospective software engineer. Here's a possible list:

• dog-friendly policy
• grand piano
• climbing wall
• indoor garden
• aquarium
• koi pond
• exercise room with fancy machines
• pinball machine

Not everyone has a dog. Not everyone can play the piano. Not everyone wants to practice rock climbing. But by having a long list in the same building, there is a good chance that at least one item will be very attractive to a particular person. If a person loves gardens, he or she can be seated at a desk within view of the garden. That person won't value the other items, perhaps, but another employee will. Change of Venue You can work on all of the preceding dimensions but there will come a day when a programmer gets restless. Sitting at exactly the same desk every day is tedious. We thought that we could solve this at ArsDigita by using the Internet and our branch offices. We'd encourage programmers from Cambridge to pick up and work at a spare desk in the Berkeley or Pasadena offices for a week or two. The idea did not catch on, however, because it turns out to be disruptive for one person on a team to disappear. One of the reasons we've found open-plan offices effective is that it helps to have one's team members close enough to look casually at what is on the screen.

What does it take to let the entire team pick up and work somewhere else for awhile? A beach house or a ski house within a two-hour drive of their main office. It is kind of expensive for an individual to rent a vacation house year-around, equip it with a DSL line or cable modem, and pack it with enough desks and computers for a team to work. But if you've got a group of 30 programmers and get a house large enough for 6 or so to sleep and work, the cost is manageable. In the winter, a programming team can disappear for a week, ski every morning and work all afternoon and evening. In the summer, a team can spend a week looking out at the ocean... while typing most of the time. It costs more than not having the beach house but a lot less than having employees go off on their own to have fun every weekend and not work. Turning average programmers into good programmers It is difficult to hire the most productive programmers in the world. Oftentimes these people are capable, by themselves, of turning out entire products, and thus they start their own companies. If a really productive programmer works for an established organization, that organization will usually take extreme steps to keep him or her. Thus beyond a certain point it is most effective for an organization to develop a strategy for creating good programmers internally.

How does one create a good programmer? Raw materials are important. You want someone with a strong computer science education, a high IQ, and an ability to communicate effectively in oral presentations and in writing. But without the right experience, such a person will never be more than an average quality programmer.

These principles are important in building up someone's programming skills:

1. A person won't become proficient at something until he or she has done it many times. In other words., if you want someone to be really good at building a software system, he or she will have to have built 10 or more systems of that type.
2. A person won't retain proficiency at a task unless he or she has at one time learned to perform that task very rapidly. Learning research demonstrates that the skills of people who become accurate but not fast deteriorate much sooner than the skills of people who become both accurate and fast.
3. Technology shifts force a programmer to go through bursts of learning every year or two.

Look around your organization. You can make a list of the people qualified to design and build a new system by counting up those who've built 10 or more similar systems in the past, at least two in the last year, and that could do the entire job in a month or two if they really had to. These are your "good programmers". Everyone else is a candidate to be turned into a good programmer as quickly as possible.

Learning to design and build software systems requires that the programmer design and build software systems. These can be smaller subprojects for internal or external customers, standalone software system for non-profit organizations, or demonstration systems to be written up and distributed to other programmers. A particularly effective option that is only available in the Web world is to build and launch a free public service. See http://remindme.arsdigita.com and http://towzone.arsdigita.com for examples of one-evening training projects.

Whatever the training task, the pace must be ruthlessly brisk. The learner should be expected to build at the same pace as an experienced developer. The difference between the learner and the wizard is that you expect the learner to make a lot of mistakes. The system as built may be awkward or not handle error cases properly. That's okay. Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality in the long run. We practice this technique in 6.916, Software Engineering for Web Applications, our course at MIT. Each student builds five database-backed Web applications during the 13-week semester. The first few that they build, during the course of the problem sets, are not necessarily elegant or optimal, but by the end of the semester they've become remarkably proficient, especially when you consider that each student is taking three or four other classes.

If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer. An average programmer's productivity will never be significant in a group of good programmers. If you care about profits, you must either come up with a new training program for the person or figure out the best way to terminate his or her employment with your organization.

Still not convinced? Take a look at the Japanese "code factory" circa 1990. These precisely organized large organizations where each person had his role, however small, were supposed to overtake the American approach where small teams of craftsmen worked in a comparatively disorganized manner. The factory approach sometimes produces acceptable corporate IT solutions but for innovation and successful product development, the craft approach has been overwhelmingly vindicated. Turning good programmers into good managers As noted in the introduction, software engineering is different because the organization can't afford to lose the individual productivity of the best people as they are pushed into management. At ArsDigita, for example, a manager who is one or two levels up from the leaf nodes is still expected to write code, develop SQL data models, write system design documents, and write journal articles. Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.

The classic problem situation at ArsDigita is a manager getting lost in his or her own work and failing to review a subordinate's efforts for two or three months. When the review occurs, inevitably the subordinate has either been working on the wrong thing in the wrong way or hasn't been sufficiently productive. At this point the manager is really angry. Three months of calendar time and money have been wasted. But should the manager be angry with the employee? If the manager had reviewed the subordinate every week, the company would never have been at risk of losing more than one week of time and money.

Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees. It has proven remarkably more effective when a neutral third-party is responsible for scheduling than when people with incentives to shirk are responsible for scheduling. Management by Consensus Considered Harmful Leaf-node engineers at every company on this planet think that they have better business ideas than the senior managers. Why not simply turn the company over to the engineers to run? Each engineer has a different set of better business ideas.

Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller. If each member of the team were playing the Bach Partitas and Sonatas for Solo Violin, the wrong notes, shaky intonation, and bad phrasing would make it pretty obvious to the novices that they needed to take advice from the experts. But because software quality is tough to measure and software quantity is seldom measured, the novices in a software engineering group are able to think of themselves as experts.

What would be wrong with a completely egalitarian software engineering group? Maybe the entire team really is at the same level of ability. And suppose that somehow the challenge of getting everyone to attack the same problem had been surmounted. Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.

Getting design input from leaf-node engineers is important for having a good product design. But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings. Microsoft is not the self-esteem company, at least if you believe Playboy magazine's interview with Bill Gates: "We hear you're brusque at times, that you won't hesitate to tell someone their idea is the stupidest thing you've ever heard. It's been called management by embarrassment challenging employees and even leaving some in tears." Truly elite organizations can be far worse than Microsoft. Ask a group of surgical interns and residents how much respect they get from the surgeons. Go into a world-class biology department and ask the grad students and post-docs about their treatment at the hands of the professors. Wherever You Go, There You Are Performance management textbooks will tell you that workers don't improve unless they get feedback. Joe Widgetmaker should get a nice chart, updated daily, of how many widgets he has produced personally each day, and how many have been built by his team.

Consider the average working programmer's life:

• surfing USENET
• surfing Slashdot
• reading docs
• questioning colleagues
• writing specs and designs
• writing docs
• writing code
• testing code
• fixing bugs
• filing bug reports on others' code
• attending meetings
• helping sales and marketing staff

(For comparison to the grad student life, see http://philip.greenspun.com/humor/graduate-student -emotion-check-list.)

Characterizing this person's productivity is going to require more than one number. But if we don't do it, days or weeks could slip by without the programmer realizing that his or her achievement levels are plummeting. In a company with disorganized or technically clueless managers, the programmer's supervisory chain won't notice the lack of achievement either.

Production of documentation and code is generally measurable by reference to the company's version control system. Bugs filed and fixed are easily tallied by looking at the company's ticket/bug tracking system (see http://www.arsdigita.com/doc/ticket for a description of our favorite open-source ticket/bug tracker). The softer stuff can still be quantified but it will have to be done by humans filling out forms.

Ideally the programmer will get daily feedback, which is kept private unless the individual elects to publicize it. Performance in each sanctioned area of activity will be marked up and scored with a weight. The programmer can then see if his or her crude achievement level is going up or down. Summary Building and managing a peak-performing software engineering organization is challenging but extremely profitable. The core Ariba product was written by two programmers, yielding a market capitalization of $30 billion. Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.

Start by attracting a good core team, perhaps by setting up an organization that enables each engineer to excel along the axes defined in http://www.arsdigita.com/asj/professionalism. Provide a productive working environment and a physical environment that is better than the average programmer's house. Provide daily positive reinforcement. Provide daily feedback showing the programmer more or less exactly what he or she has accomplished, plus a graph for the preceding few months showing the trend. Aim to install a feeling of ownership in each worker. More

• Bringing out the Best in People (Aubrey Daniels 1999; McGraw Hill). 200 pages containing 75 pages of good ideas plus the usual business book filler. But the ideas are genuinely good.
• The Mythical Man-Month (Fred Brooks 1995)
• Managing the Professional Service Firm (David Maister 1993). In terms of having an equal distribution of ability among all levels of the enterprise, the closest industry to software engineering is management consulting. Maister's work is a classic guide to success in this industry.
• Peopleware (Tom DeMarco and Timothy Lister 1999); page 98 is worth the price of admission, explaining that "the term unprofessional is often used to characterize surprising and threatening behavior. ... In a healthier organization culture, people are thought to be professional to the extent they are knowledgeable and competent." (See http://www.arsdigita.com/asj/professionalism for ArsDigita's independent conception of this idea.) Much of the rest of the book is a celebration of the 40-hour work week and the claim that "overtime" in the long run is never beneficial. If the authors were correct, Silicon Valley would be the poorest region of the nation, with Redmond, Washington the 2nd most impoverished. And Washington, DC would be our great source of innovation and productivity. Peopleware was probably written to help ensure success for internal corporate IT projects where there isn't any competition and delivering three months late won't change much.
• Making the Cisco Connection : The Story Behind the Real Internet Superpower (Bunnel et al 2000) -- shows how ignoring the "no overtime" admonitions in Peopleware can generate $400 billion in market cap.
• Parkinson's Law (C. Northcote Parkinson 1958) -- how management really works in the long run
• A Pattern Language (Christopher Alexander et al 1977) has very interesting things to say about physical space and social organization.

Reader's Comments

A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded.

This is illustrated by the classic business school article:

Kerr, S., 1975, "On the Folly of Rewarding A, While Hoping For B," Academy of Management Journal, Vol. 18, pp. 769-783.

It represents exactly what you are saying.

-- Tyler Pruett, October 30, 2000

Philip, your ideas on rewarding programmers are excellent. However, I don't believe number of hours worked defines a good developer. Programmers get older and have families. Saying that they have to log a certain number of hours in the office is stupid, almost like IBM counting programmer productivity in "K-Locks" (thousands of lines of code).
A good developer can often finish what an average one can do in half the time an average developer can - with less bugs and with better documentation.

A couple of good books on this topic include,
"Software Project Survival Guide by Steve McConnell"
(Somewhat dry - but good reference book)
First, Break All the Rules : What the World's Greatest Managers Do Differently
(Not one of the typical management books - this one has some actual research behind it.)
Microsoft Secrets : How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
(A few good chapters worth reading)

-- Anthony Barker, November 1, 2000

Not to mention that programmers who are measured based on how late they stay at work will quickly figure out how to excel at staying late without being more productive (e.g. come in at 11:00 am).

This article reinforces many great ideas from Frederick Brooks but, unfortunately, regurgitates a few tired stereotypes. Most programmers that turn 30, get married, have a few kids (that go to bed at 7:00), may as well resign themselves to being put out to pasture.

Here's an idea. Instead of just assuming that it takes 25 hours a week for team coordination and build your management approach upon motivating programmers to work more hours, why not work to reduce the time it takes to coordinate through better management and more efficiency? Isn't that what management really is?

-- Tom Wilson, November 2, 2000

Dog-friendly offices may be great for dog owners / lovers, but aren't as wonderful for people with allergies or even those who just want to be able to concentrate on writing code without having a dog try to jump on their lap.

-- Kevin Scaldeferri, November 2, 2000

Wow. You're assuming a lot here. You haven't read the article, and I question your familiarity with Greenspun. In my opinion, he has ample education, intelligence and experience to make all these claims:

- 3 degrees from MIT including a PhD in computer science
- 20 years of software development experience
- co-developed computer science courses for MIT and 10 other universities
- has been managing programmers at ArsDigita since 1977. Company currently has 80-full timers.

Or just take a look at his resume.

One can factor prime numbers by simply entering them into my patent-pending PrimeFactor function.

Here is the proposed PrimeFactor function, implemented in C. This post serves as prior art, so don't think about stealing my solution to this major mathematical problem that has confounded humanity for centuries.

void PrimeFactor(double PrimeNum)
{
cout << "The factors of the Prime Number are 1 and " << PrimeNum << endl;
}

Thank you for your consideration.

I watch the sea.
I saw it on TV.

I have the greatest personal respect for you and your books. I've learned a lot from your writing. I'd like to know more about the "software copyright statement" which your CD-ROM will utilize to protect the electronic text.

Did you inquire about the terms and conditions of this "copyright statement?" I suspect it's not a copyright statement at all, but actually a licensing agreement. Is this the case? What rights does it require the purchaser^H^H^H^H^H^H^Hlicenser of your book to forfeit?

Does it require the purchaser of your book to forfeit the right to return the material? This shouldn't be necessary if all you are trying to accomplish is to protect the text. Apply a copyright statement to the appendices and throw the CD in the book. Better yet, apply the copyright statement and post the whole appendix to the McGraw-Hill website.

I feel that it is your responsibility, as an author, to drive the publisher toward ethical, informative and aesthetic publishing (rather than just trying to make a buck).

Sorry the cheap parting shot, but you ought to read Philip Greenspun's book behind the book , especially the part entitled Flaming Summary: Why Computer Books Suck. Make sure to check out the portion about 1200-page books.

The man knows how he got there, and what keeps him there. So do the people who work for him. Don't expect any changes.

What challenges would you like to see on the next series? - if you post any ideas on the Junkyard discussion, there is a much higher chance that the production team will see your suggestions (they don't look at Slashdot much!)

Cheers,
andy.bell@rdfmedia.com
"The fiercest and, frankly, ugliest show on television" - Robert Llewellyn

I've always been partial to Philip Greenspun's philosophy of Web design. It's a classic.

Now hiring experienced client- & server-side developers

• Build great credit, and a lot of it. Grad students are not seen as good initial credit risks, but a history of on-time payments and significant balances will allow you to take advantage of credit. This may seem like a road to ruin at first, but take into account how cheap money can be at times...for example, I bought a new car in grad school. The manufacturer gave me a 0.9% loan, so it didn't make sense to pay for it with savings. Meanwhile, I knew a lot of "fiscally responsible" students who had avoided credit in college and couldn't get a $500-limit Mastercard, let alone a car loan.

  (Speaking of which, credit-card interest is often very low for grad students--you fit the lender's "about to get in deep financial trouble, so entice with low-rate cards" profile. If you are careful, you can use this leverage to your advantage.)

• Fully fund your retirement plan and let that serve as your emergency fund. For obvious reasons, it helps to have a financial safety net in grad school. You can play fast and loose with your income if you don't need to worry about emergency expenses. Good credit can reduce this need, but retirement cash could bail you out (perhaps literally) of a bad situation.
• Listen to the sage advice of Rob Peters and Phillip Greenspun. Getting What You Came For is a great book, highly recommended for all prosepctive PhD students. Greenspun's pages tell it like it is.

Would you morons shut *up* already?

I'm seriously considering strongarming ICANN until they make it a requirement of all registrars that it be required for you to *justify* *any* registered second level domain after the first one.

IBM got to ibm.com first.

They are in no danger *whatever*, of trademark dilution or anything else, from Indiana Boron Mining wanting ibm.net.

They just aren't. If this requires the general public to get smarter, then guess fuckin' what? They're just gonna have to get smarter.

Suggesting that people ought to register their brand name in every domain "to protect it" (as Networks Solutions has, in fact, done commercially) is just a millimeter short of Internet treason, and hanging is too good for those who do it.

I wrote a reply to the Department of Commerce that touches on this, three years ago.

I find myself unsurprised that it had little effect. Letting politicians stick their noses into engineering matters will get you into... de mess we is in.

I suppose I should have expected this, though, from someone who refers to a domain name as a "web address".

Cheers,
-- jra
-----

For a more recent example of the RIAA's tactics in action, see this page of Salon.com's presentation of the Courtney Love speech.

I'm thrilled that someone with Hatch's legislative acumen and personal stake in the music distribution system is picking up the ball. But there are 533 other members of Congress, many of them with RIAA- and MPAA-controlled noserings, to contend with before new legislation is passed-- which someone in the White House will have to sign.

And there's no assurance that the legislation that is enacted will be any less flawed than the DMCA. This is very slippery ground.
--
syrynx

Getting subselects right requires that (a) the query optimiser in the DB works well and that (b) the person formulating the queries knows how to produce good SQL.

Usually, it's the latter, not the former that falls down. Speaking as a SQL cavemen, I usually hand of complex queries involving suub-sub-queries to our DBAs to do. Why? Well, Oracle sure as heck ain't crap at doing them. In fact, Oracle can do a complex sub query in less time than it takes to fetch a query, process it, submit another query based in te first, etc. The difference is that a well-formed query will be orders of magntiude faster than a poorly formed one.

Overall, performing multiple queries instead of subqueries is almost always slower, and imposes heavier loads on your front end and database boxes than simply sriting a good piece of SQL. The problem is writing good SQL, because it's really easy to write something very slow indeed. And rarely ever the database engine's fault.

There's only one, small problem.

It won't work.

Ok, it wont work *well*. :-)

To take one specific example, I have, for a number of years, been a customer of Mindspring in one way or another. I've had occasion to dial into a West Central Florida MS dialup number from at least a dozen sites, in at least 40,000 square miles, using at least half a dozen different numbers, which I *know* were on different physical POPs (that is, I know they weren't just different numbers terminating in the same building -- the traceroutes showed routers with names in different cities).

All of these connections got an IP address in 207.69/16.

In East Central Florida, they all seem to be 209.86/16.

Since the dialup servers in question use RADIUS to retrieve the IP addresses they're going to hand out, it's possible for *every dialup downstream of their Orlando router* to come from the same pool.

For more detail on why this is hard to do, and what alternative solutions have been proposed, check out RFC 1712 and RFC 1876.

Oh, and while we're talking about things related to DNS, you might also enjoy RFC 2100.

:-}

Cheers,
-- jra
-----

There's only one, small problem.

It won't work.

Ok, it wont work *well*. :-)

To take one specific example, I have, for a number of years, been a customer of Mindspring in one way or another. I've had occasion to dial into a West Central Florida MS dialup number from at least a dozen sites, in at least 40,000 square miles, using at least half a dozen different numbers, which I *know* were on different physical POPs (that is, I know they weren't just different numbers terminating in the same building -- the traceroutes showed routers with names in different cities).

All of these connections got an IP address in 207.69/16.

In East Central Florida, they all seem to be 209.86/16.

Since the dialup servers in question use RADIUS to retrieve the IP addresses they're going to hand out, it's possible for *every dialup downstream of their Orlando router* to come from the same pool.

For more detail on why this is hard to do, and what alternative solutions have been proposed, check out RFC 1712 and RFC 1876.

Oh, and while we're talking about things related to DNS, you might also enjoy RFC 2100.

:-}

Cheers,
-- jra
-----

There's only one, small problem.

It won't work.

Ok, it wont work *well*. :-)

To take one specific example, I have, for a number of years, been a customer of Mindspring in one way or another. I've had occasion to dial into a West Central Florida MS dialup number from at least a dozen sites, in at least 40,000 square miles, using at least half a dozen different numbers, which I *know* were on different physical POPs (that is, I know they weren't just different numbers terminating in the same building -- the traceroutes showed routers with names in different cities).

All of these connections got an IP address in 207.69/16.

In East Central Florida, they all seem to be 209.86/16.

Since the dialup servers in question use RADIUS to retrieve the IP addresses they're going to hand out, it's possible for *every dialup downstream of their Orlando router* to come from the same pool.

For more detail on why this is hard to do, and what alternative solutions have been proposed, check out RFC 1712 and RFC 1876.

Oh, and while we're talking about things related to DNS, you might also enjoy RFC 2100.

:-}

Cheers,
-- jra
-----

From what i know about ServerBench it uses a threaded IO model on NT, but a fork/process model on Linux.

Instead of getting all wrapped around benchmarks (let alone closed-source benchmarks!) we would be better off paying attention to the efficiency of the server program:

Speed

It is so easy now to get a high-efficiency server program that speed is no longer a significant discriminant. In ancient times, the Web server forked a new process every time a user requested a page, graphic, or other file. The second generation of Web servers pre-forked a big pool of processes, e.g., 64 of them, and let each one handle a user. The server computer's operating system ensured that each process got a fair share of the computer's resources. A computer running a pre-forking server could handle at least three times the load. The latest generation of Web server programs uses a single process with internal threads. This has resulted in another tripling of performance.

It is possible to throw away 90 percent of your computer's resources by choosing the wrong Web server program. Traffic is so low at most sites and computer hardware so cheap that this doesn't become a problem until the big day when the site gets listed on the Netscape site's What's New page. In the summer of 1996, that link delivered several extra users every second at the Bill Gates Personal Wealth Clock ( http://www.webho.com/WealthClock). Every other site on Netscape's list was unreachable. The Wealth Clock was working perfectly from a slice of a 70 Mhz pizza-box computer...

http://philip.greenspun.com/teaching/one-term-web

and

http://philip.greenspun.com/teaching/psets/

http://philip.greenspun.com/teaching/one-term-web

and

http://philip.greenspun.com/teaching/psets/

My snap reaction was "I wonder if they're gonna make the same silly mistake on opening up the software development stuff quickly that they seemed to have made the first time... then I realized: we won't care. :-) They can't even hide the hardware without breaking GPL on the driver files...

One other useful link in this context is probably the NanoGUI project: X (or WinGDI) in <250KB? (originally spotted via Hac k The Planet.)

I can't wait...

Cheers,
-- jra
-----

My snap reaction was "I wonder if they're gonna make the same silly mistake on opening up the software development stuff quickly that they seemed to have made the first time... then I realized: we won't care. :-) They can't even hide the hardware without breaking GPL on the driver files...

One other useful link in this context is probably the NanoGUI project: X (or WinGDI) in <250KB? (originally spotted via Hac k The Planet.)

I can't wait...

Cheers,
-- jra
-----

My snap reaction was "I wonder if they're gonna make the same silly mistake on opening up the software development stuff quickly that they seemed to have made the first time... then I realized: we won't care. :-) They can't even hide the hardware without breaking GPL on the driver files...

One other useful link in this context is probably the NanoGUI project: X (or WinGDI) in <250KB? (originally spotted via Hac k The Planet.)

I can't wait...

Cheers,
-- jra
-----

My snap reaction was "I wonder if they're gonna make the same silly mistake on opening up the software development stuff quickly that they seemed to have made the first time... then I realized: we won't care. :-) They can't even hide the hardware without breaking GPL on the driver files...

One other useful link in this context is probably the NanoGUI project: X (or WinGDI) in <250KB? (originally spotted via Hac k The Planet.)

I can't wait...

Cheers,
-- jra
-----

> If it removes the copyrighted post but not the
others it could lose any claim to common carrier status, thus making it legally responsible for anything posted.

I keep seeing this meme, and I disagree with it.

I'm reasonably familiar with the terms of Cubby v. Compuserve, and Stratton-Oakmont v. Prodigy, the two cases usually cited in this vein, and I don't believe that either of them could be used as precedent in an action against Slashdot for removing the posting of MS' copyrighted data.

"Responding to a court order" != "exercising editorial control", which was the issue on point in those two cases. Even more importantly, neither of those cases made it past district court, so while notice of them might be taken by a judge in the West, they are not controlling precedent, anyway.

Oh, and one other thing: it is my understanding that to claim trade secret status for information, you have to take *vigorous steps* to protect them, like signed contracts with the people you release them to. The click-through license Microsoft used, especially since it is so easily circumventable, almost certainly would not qualify.

That's what I think, but maybe it's just me.

So many things are just me.

Cheers,
-- jra
-----

but I agree with his comments. Where Netpliance made their mistake was twofold:

They didn't *enforce* their business model, right from in front, and

when that proved to be a mistake, they didn't step up to the plate and take their lumps on what had already been ordered, they *retroactively* attempted to force contracts on people *whose transactions had already been completed*.

If their management, and by extension, their board, can't make the stockholders understand that It Would Be A Bad Thing to piss off that group of customers, then perhaps they deserve what they've gotten.

They will *not* be the only people in this market... and who tells Aunt Molly what to buy?

But I dunno, maybe it's just me.

So many things are just me.

Cheers,
-- jra
-----

I believe that the issue here is that the GPL is merely a *license*. The copyright, and the control over how the code may be deployed, devolves to people who receive the code only under the terms of that license.

If you receive a copy of some code which you are licensed to use by the terms of the GPL, then term 4 of the GPL would apply: 'you may not sublicense [the software]'.

If you look at this from the standpoint of "under what terms may I redistribute the code?", it becomes fairly obvious: you may only distribute it under the terms of the license you received it under, or any other license the copyright holder grants you -- the GPL itself does not grant you the right to redistribute under any terms other than it's own.

Cheers,
-- jra
-----

• ACM Supporting Work Group SIG
• LUSENET / Lusenet98
• InfoPlace Document Organizer
• GROUP.lounge (a thesis in progress)

It's been said before, and I'll say it again. Go to Philip Greenspun's web site and read the book, check out the code, download the freeware. This guy and his crew understand high volume db backed sites like nobody else.

WAP sucks, as I've said a couple times before.

The Wireless Application Forum has developed an entire stack of network protocols parallel to, and only marginally compatible with, the existing Internet architecture.

They are convinced handheld wireless devices are -- and will remain -- four orders of magnitude less powerful than conventional Internet hosts and thus require optimized transport, applications, and content. At each turn, WAP Forum has chosen to reinterpret existing Internet standards -- often incompatibly. The shift from UDP to WDP, TLS to WTLS, HTTP to WTP, HTML to WML, ECMAScript to WMLScript -- termed 'the W* Effect' -- is disingenuous at best, and at worst, locks in early WAP adopters to today's lowest common denominator.

These might be good ideas, but I simply don't believe that it's practical to implement them in an environment where "everybody else's" Windows program works some other way.

(This is completely apart from my opinion that these things comprise fundamental computer literacy and that, contrary to Cooper's assertions in Inmates, computer literacy is not a polite way of saying 'stupid willingness to tolerate insufferably poor design -- I don't think HFS' are poor design.)

But, my question would be (yes, there's actually a question buried in here) this: you, Jakob, seem to go the other direction, displaying an almost slavish devotion to the installed base, even if a) it's a poor design, objectively, and b) there's an obviously better one.

Color choices for links would be my favorite example. My weblog, for example, uses a dark teal text color (dark enough for good contrast on white), and navy blue for links -- which drops back to the text color, while still staying underlined, for visited links.

Obviously, this wouldn't work on navigational elements rather than in-line links, but I'm honestly not at all certain that visited-ness is pertinent there, and it might actually be confusing. (I mean, here, the sort of things many people put on 'tabs'.)

I'm an engineering type, so I suppose I'd rather have it 'right', even if it means I have to work harder training people the first time, because if I teach them to fish (discerning rules for link changes from looking at a site) rtaher than feeding them (blue means link, red means visited), then my long-term support load decreases.

Do you think that people, in general, are really so untrainable that this is an unreasonable approach? Or that making them think, even just a little bit, is really that much to ask?

Cheers,
-- jra
-----

Without chasing everyone over to my weblog for the grind, the favorite in the room I was watching in was the Tabasco spot (the 'log has a link to the QT4 file), followed by the Clydesdale spot, the FedEx/Wizard of Oz spot, and the VISA 'swimmers' spot, in differing orders of preference.

We did like the Christopher Reeve one, too. And the "slidewalk/credit card fraud" company's stuff sounded pretty cool, too... who were they again? :-)

Cheers,
-- jra
-----

Since it's only partially related, I've put it here.

The magic word is TANSTAAFL.
Cheers,
-- jra
-----

Meant to get this comment in earlier, but I'd lost the link, and Dan Lyke, at Flutterby, whose weblog I'd gotten the link from, hadn't run his index engine recently; I had to mail him for it.

If you have any interest in WAP et. al, at all, I'd suggest reading this paper.
Cheers,
-- jra
-----

Meant to get this comment in earlier, but I'd lost the link, and Dan Lyke, at Flutterby, whose weblog I'd gotten the link from, hadn't run his index engine recently; I had to mail him for it.

If you have any interest in WAP et. al, at all, I'd suggest reading this paper.
Cheers,
-- jra
-----

Actually, it's worse that that; the Germans _asked_ for Hitler to take over.

ESR wrote this up; I've just linked it off my new weblog (there's a shocking idea... :-) at baylink.p itas.com.

Scary stuff...

Cheers,
-- jra
-----

Timebomb 2000 forum. Where most of the doomers and conspiracy theorists hang out. Tim ebomb 2000 garynorth.com - the lead doomer of them all. But he has over 6000 articles about y2k on his site www.garynorth.com On the Usenet comp.software.year-2000