this does chomp() on every line of input, and $_ .= "\n" on every output

In a perfect hacker world, anyone pissed off enough to open up a control box near a traffic light and take it apart to make it work better should be perfectly welcome to make the attempt. Rules which prevent you from taking matters like that into your own hands are too ridiculous to even consider abiding by. This attitude helped the Model Railroad Club start, on an extremely informal basis, something called the Midnight Requisitioning Committee. When TMRC needed a set of diodes, or some extra relays, to build some new feature into The System, a few S&P people would wait until dark and find their way into the places where those things were kept. None of the hackers, who were as a rule scrupulously honest in other matters, seemed to equate this with "stealing." A willful blindness.

All information should be free.

If you don't have access to the information you need to improve things, how can you fix them? A free exchange of information, particularly when the information was in the form of a computer program, allowed for greater overall creativity. When you were working on a machine like the TX-0, which came with almost no software, everyone would furiously write systems programs to make programming easier Tools to Make Tools, kept in the drawer by the console for easy access by anyone using the machine. This prevented the dread, time-wasting ritual of reinventing the wheel: instead of everybody writing his own version of the same program, the best version would be available to everyone, and everyone would be free to delve into the code and improve on that. A world studded with feature-full programs, bummed to the minimum, debugged to perfection.

 I did not realize that OS/360 was the project that inspired The Mythical Man Month.

to be even more flexible, we use no_plan. This means we're just running some tests, don't know how many. [6]

    use Test::More 'no_plan';   # instead of tests => 32

now we can just add tests and not have to do all sorts of math to figure out how many we're running.

 bit of computer history that sometimes comes up in conversation

As described by Apple Discussions poster ydc:
Actually you will need to make a change on your Vista machine to enable this, but you can do it without the Group Policy editor or the Security Policy editor.

To do it:

1. Click Windows Visa Start Orb
2. In search box, type "regedit" and return
3. Once regedit opens, click File -> export to make a backup copy
4. Navigate to ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa.
5. n the right pane, right-click the "LmCompatibilityLevel" key and select "modify"
6. Change the value from 3 to 1
7. Exit regedit and you should now be able to properly authenticate to your Mac OS X (or other Samba) share.

 I spent too much time searching for this answer.  Vista FTL

> Click Windows Visa Start Orb

<3 "Start Orb"

"How will this software get my users laid" should be on the minds of anyone writing social software (and these days, almost all software is social software).

"Social software" is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.

 On configuring Apache for a test environment (LAN behind the firewall)

Should also set the ServerName directive to the IP address of the machine, otherwise the comptuer name will still get used when symlinks are followed.

  "The normalized length of the attribute specification list
   is the sum of the normalized lengths of each attribute name
   and attribute value specified, which can not exceed the
   'ATTSPLEN' quantity."

I.e. the total length of the list of attributes and values, as given for
an element, can not exceed the value stated for 'ATTSPLEN' in an SGML
declaration, after the attribute list has been normalized.

'ATTSPLEN' is set at 65536 in the SGML declaration for HTML4.01

  http://www.w3.org/TR/html4/sgml/sgmldecl.html

We're interested only in simulating the exception condition, and not re-creating it -- doing the latter more easily leads to confusion. Suppose a novice developer on your team chooses d:/doesNotExist as the test case's invalid file location. She passes the tests on her machine and integrates her changes. Now you run the tests on your machine, which just happens to have d:/doesNotExist on the filesystem: Maybe it's left behind from a test case of yours that didn't tear itself down correctly. The test unexpectedly fails, not because the code is wrong, but because the test depends too much on the environment around it.

This wastes time. You spend 30 minutes isolating the cause of the problem, 15 minutes explaining to the novice developer why d:/doesNotExist was a risky choice, and 20 minutes crafting a note to the rest of the team, warning them against such coding practices. Of course, when someone new joins the team, it will probably happen again. Writing a single mock deployer with a method called doNotFindAnyFiles allows you to avoid such annoyances.

institution that was anarchistic and very great," he would explain. "If I told people it's possible to have no security on a computer without people deleting your files all the time, and no bosses stopping you from doing things, at least I could point to the AI lab and say, 'Look, we are doing it. Come use our machine! See!' I can't do that anymore. Without this example, nobody will believe me. For a while we were setting an example for the rest of the world. Now that this is gone, where am I going to begin from? I read a book the other day. It's called Ishi, the Last Yahi. It's a book about the last survivor of a tribe of Indians, initially with his family, and then gradually they died out one by one."

That was the way Richard Stallman felt. Like Ishi.

"I'm the last survivor of a dead culture," said RMS. "And I don't really belong in the world anymore. And in some ways I feel I ought to be dead."

Richard Stallman did leave MIT, but he left with a plan: to write a version of the popular proprietary computer operating system called UNIX and give it away to anyone who wanted it. Working on this GNU (which stood for "Gnu's Not Unix") program meant that he could "continue to use computers without violating [his] principles." Having seen that the Hacker Ethic could not survive in the unadulterated form in which it had formerly thrived at MIT, he realized that numerous small acts like his would keep the Ethic alive in the outside world.

What's a Pattern?

A pattern describes an optimal solution to a common problem within a specific context.

From the IAWiki:

Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.

Each pattern has four primary components:

1. a title
2. a problem
3. a context
4. a solution

In the context format, any changed lines are shown alongside unchanged lines before and after. The inclusion of any number of unchanged lines provides a context to the patch. This output is accepted as input to the patch program. The format introduces greater readability for humans and reliability when applying the patch. These are lines that have not changed between the two files, and so can be used as a reference to locate the chunk's place in a modified file and find the intended location a change should be applied regardless if the line numbers no longer correspond. This intelligent behavior isn't possible with the traditional diff output.

...

A "!" represents a change between lines that correspond in the two files. A "+" represents the addition of a line, while a blank space represents an unchanged line. At the beginning of the patch is the file information, including the full path and a time stamp. At the beginning of each hunk are the line numbers that apply for the corresponding change in the files. A number range appearing between sets of three asterisks applies to the original file, while sets of three dashes apply to the new file. The chunk ranges specify the starting line number and the number of lines the change hunk applies to in the respective file.

Refactoring: Improving the Design of Existing Code by Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

Here is the refactoring game: Maintaining the current behavior of the system, how can you make your system more valuable, either by increasing its quality or by reducing its cost?

The most common variant of the game is to look at your program. Identify a place where it is missing one or more of the benefits of indirection. Put in that indirection without changing the existing behavior. Now you have a more valuable program because it has more qualities that we will appreciate tomorrow.

Contrast this with careful upfront design. Speculative design is an attempt to put all the good qualities into the system before any code is written. Then the code can just be hung on the sturdy skeleton. The problem with this process is that it is too easy to guess wrong. With refactoring, you are never in danger of being completely wrong. The program always behaves at the end as it did at the beginning. In addition, you have the opportunity to add valuable qualities to the code.

There is a second, rarer refactoring game. Identify indirection that isn't paying for itself and take it out. Often this takes the form of intermediate methods that used to serve a purpose but no longer do. Or it could be a component that you expected to be shared or polymorphic but turned out to be used in only one place. When you find parasitic indirection, take it out. Again, you will have a more valuable program, not because there is more of one of the four qualities listed earlier but because it costs less indirection to get the same amount from the qualities.

Refactoring: Improving the Design of Existing Code by Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

Refactoring: Improving the Design of Existing Code by Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

Refactoring: Improving the Design of Existing Code by Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

The object programs that live best and longest are those with short methods. Programmers new to objects often feel that no computation ever takes place, that object programs are endless sequences of delegation. When you have lived with such a program for a few years, however, you learn just how valuable all those little methods are. All of the payoffs of indirection—explanation, sharing, and choosing—are supported by little methods (see Indirection and Refactoring on page 61).

Since the early days of programming people have realized that the longer a procedure is, the more difficult it is to understand. Older languages carried an overhead in subroutine calls, which deterred people from small methods. Modern OO languages have pretty much eliminated that overhead for in-process calls. There is still an overhead to the reader of the code because you have to switch context to see what the subprocedure does. Development environments that allow you to see two methods at once help to eliminate this step, but the real key to making it easy to understand small methods is good naming. If you have a good name for a method you don't need to look at the body.

The net effect is that you should be much more aggressive about decomposing methods. A heuristic we follow is that whenever we feel the need to comment something, we write a method instead. Such a method contains the code that was commented but is named after the intention of the code rather than how it does it. We may do this on a group of lines or on as little as a single line of code. We do this even if the method call is longer than the code it replaces, provided the method name explains the purpose of the code. The key here is not method length but the semantic distance between what the method does and how it does it.

Refactoring: Improving the Design of Existing Code by Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

I've been asked, "Is refactoring just cleaning up code?" In a way the answer is yes, but I think refactoring goes further because it provides a technique for cleaning up code in a more efficient and controlled manner. Since I've been using refactoring, I've noticed that I clean code far more effectively than I did before. This is because I know which refactorings to use, I know how to use them in a manner that minimizes bugs, and I test at every possible opportunity.

I should amplify a couple of points in my definitions. First, the purpose of refactoring is to make the software easier to understand and modify. You can make many changes in software that make little or no change in the observable behavior. Only changes made to make the software easier to understand are refactorings. A good contrast is performance optimization. Like refactoring, performance optimization does not usually change the behavior of a component (other than its speed); it only alters the internal structure. However, the purpose is different. Performance optimization often makes code harder to understand, but you need to do it to get the performance you need.

The second thing I want to highlight is that refactoring does not change the observable behavior of the software. The software still carries out the same function that it did before. Any user, whether an end user or another programmer, cannot tell that things have changed.

Refactoring: Improving the Design of Existing Codeby Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

I strongly believe that a good design is essential for rapid software development. Indeed, the whole point of having a good design is to allow rapid development. Without a good design, you can progress quickly for a while, but soon the poor design starts to slow you down. You spend time finding and fixing bugs instead of adding new function. Changes take longer as you try to understand the system and find the duplicate code. New features need more coding as you patch over a patch that patches a patch on the original code base.

A good design is essential to maintaining speed in software development. Refactoring helps you develop software more rapidly, because it stops the design of the system from decaying. It can even improve a design.

Refactoring: Improving the Design of Existing Codeby Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

The Rule of Three

Here's a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.

Refactoring: Improving the Design of Existing Code by Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts

Wi-Fi Salon intends to activate 18 wireless "hot spots" by the end of next month at Battery, Central and Riverside Parks and in Washington and Union Squares in Manhattan; at Prospect Park in Brooklyn; at the Flushing Meadows-Corona Park in Queens; and at Pelham Bay and Van Cortlandt Parks and Orchard Beach in the Bronx.

Eight of the hot spots will be in Central Park and two in Prospect Park. The first of the 18 locations — a stretch of Battery Park, from the Battery Gardens restaurant to the Castle Clinton National Monument — is to be activated today, with the other 17 to follow, in stages, through the end of next month.

function compareOptionText(a,b) {
  /*
   * return >0 if a>b
   *         0 if a=b
   *        <0 if a<b
   */
  // textual comparison
  return a.text!=b.text ? a.text<b.text ? -1 : 1 : 0;
  // numerical comparison
//  return a.text - b.text;

The - selectedIndes - property of a SELECT element is not meaningful in
a multiple select element, and the value of any OPTION element that may
be selected is only ever going to be a single value from any group of
OPTIONs selected.

To find all of the selected OPTION elements in such a SELECT element it
is necessary to loop through the - options - collection of the SELECT
element and respond to each OPTION element's - selected - property
(which is boolean, either true or false). Something like:-

var options = this.options;
for(var c = options.length;--c;){
    if( options[c].selected  ){ //true if selected.
        // do something with the - value of the selected option.
     }

 what does this do?  is that a language feature or a typo?

 parent is designated by the assignation of a "current" CSS class.  this is straightforward BUT we have to traverse the DOM every time we want to find the parent.  could be stored in a hash at the cost of an added layer of indirection

 tight coupling.  the current url is compared to each A tag in the menu, and we choose the current menu item because it has a target that is currently in the URL bar

 interesting things going on in the tree nav... the js assumes it knows the extension of the index file...

You can categorise content within Confluence using simple one-word labels. Content in Confluence can be given any number of labels, which can then be searched for, browsed, or used as filters in RSS feeds or macros.

Labels beginning with ‘my:’ (i.e. my:needsreview) are personal labels. These labels are only visible to the user who created them. Personal labels are useful for marking content that you may be personally interested in, and can be browsed from your user profile.

Great designers. The central question of how to improve the software art centers, as it always has, on people.

We can get good designs by following good practices instead of poor ones. Good design practices can be taught. Programmers are among the most intelligent part of the population, so they can learn good practice. Thus a major thrust in the United States is to promulgate good modern practice. New curricula, new literature, new organizations such as the Software Engineering Institute, all have come into being in order to raise the level of our practice from poor to good. This is entirely proper.

Nevertheless, I do not believe we can make the next step upward in the same way. Whereas the difference between poor conceptual designs and good ones may lie in the soundness of design method, the difference between good designs and great ones surely does not. Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge.

The differences are not minor—it is rather like Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.

A little retrospection shows that although many fine, useful software systems have been designed by committees and built by multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers. Consider Unix, APL, Pascal, Modula, the Smalltalk interface, even Fortran; and contrast with Cobol, PL/I, Algol, MVS/370, and MS-DOS (Fig. 16.1).

Hence, although I strongly support the technology transfer and curriculum development efforts now underway, I think the most important single effort we can mount is to develop ways to grow great designers.

No software organization can ignore this challenge. Good managers, scarce though they be, are no scarcer than good designers. Great designers and great managers are both very rare. Most organizations spend considerable effort in finding and cultivating the management prospects; I know of none that spends equal effort in finding and developing the great designers upon whom the technical excellence of the products will ultimately depend.

My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition—office size, furnishings, personal technical equipment, travel funds, staff support—must be fully equivalent.

How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious:

• Systematically identify top designers as early as possible. The best are often not the most experienced.

• Assign a career mentor to be responsible for the development of the prospect, and keep a careful career file.

• Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo design and technical leadership assignments.

• Provide opportunities for growing designers to interact with and stimulate each other.

 Fred Brooks, No Silver Bullet

I usually use the -l option without an argument just to add a new line to the end of each line of output. For example, I'd usually write my original "Hello World" example as:

  $ perl -le 'print "Hello World"'

No Clipboard: Ever since the iPhone was announced, I’ve been curious what Apple planned to do with the standard Cut/Copy/Paste clipboard commands. With no menu bar, there’s no Edit menu. With no keyboard, there’s no command-key shortcuts. The Newton solved this with magic gestures. The iPhone solves this by not having a clipboard at all. No copy, no paste.

Instead, Apple has tried to anticipate where you might want to copy and paste and offer you direct commands to accomplish the same thing.

Google has the concept of “Tech Stops.”  Each floor of each building has one.  They handle all of the IT stuff for employees in the building including troubleshooting networks, machines, etc.  If you’re having a problem you just walk into a Tech Stop and someone will fix it.  They also have a variety of keyboards, mice, cables, etc.  They’re the ones who order equipment, etc.  In many ways the Tech Stop does some of what our admins do.  If your laptop breaks you bring it to a Tech Stop and they fix it or give you another one (they move your data for you).  If one of your test machines is old and crusty you bring it to the Tech Stop and they give you a new one.  They track everything by swiping your ID when you “check out” an item.  If you need more equipment than your job description allows, your manager just needs to approve the action.  The Tech Stop idea is genius because:

1.       You establish a relationship with your IT guy so technical problems stop being a big deal - you don’t waste a couple of hours trying to fix something before calling IT to find out it wasn’t your fault.  You just drop in and say, “My network is down.”

2.       Most IT problems are trivial when you’re in a room together (“oh that Ethernet cable is in the wrong port”)

3.       The model of repair or replace within an hour is incredible for productivity.

4.       It encourages a more flexible model for employees to define their OWN equipment needs.  E.g. a “Developer” gets a workstation, a second workstation or a laptop, and a test machine.  You’re free to visit the Tech Stop to swap any of the machines for any of the others in those categories.  For example, I could stop by and swap my second workstation for a laptop because I’m working remotely a lot more now.  In the Tech Stop system, this takes 5 minutes to walk down and tell the Tech Stop guy.  If a machine is available, I get it right away.  Otherwise they order it and drop it off when it arrives.  In our current set up, I have to go convince my manager that I need a laptop, he needs to budget for it because it’s an additional machine, an admin has to order it, and in the end developers always end up with a growing collection of mostly useless “old” machines instead of a steady state of about 3 mostly up-to-date machines.

This is the correct script for detecting the mouse coordinates:

function doSomething(e) {
	var posx = 0;
	var posy = 0;
	if (!e) var e = window.event;
	if (e.pageX || e.pageY) 	{
		posx = e.pageX;
		posy = e.pageY;
	}
	else if (e.clientX || e.clientY) 	{
		posx = e.clientX + document.body.scrollLeft
			+ document.documentElement.scrollLeft;
		posy = e.clientY + document.body.scrollTop
			+ document.documentElement.scrollTop;
	}
	// posx and posy contain the mouse position relative to the document
	// Do something with this information
}

 my liveblogging rss feeds

 so what this mean is that you have to put &disprec=  as the parameter.  &disprec won't work, and neither will &disprec=true :-p

Here is a realistic example of the try/catch statement. It uses the factorial( ) method defined in the previous section and the client-side JavaScript methods prompt( ) and alert( ) for input and output:

//not implemented until JavaScript 1.5

function factorial(x) {
    // If the input argument is invalid, throw an exception!
    if (x < 0) throw new Error("x must not be negative");
    // Otherwise, compute a value and return normally
    for(var f = 1; x > 1; f *= x, x--) /* empty */ ;
    return f;
}

try {
    // Ask the user to enter a number
    var n = prompt("Please enter a positive integer", "");
    // Compute the factorial of the number, assuming that the user's
    // input is valid
    var f = factorial(n);
    // Display the result
    alert(n + "! = " + f);
}
catch (ex) {  // If the user's input was not valid, we end up here
    // Tell the user what the error is
    alert(ex);
}

Flanagan, JavaScript: The Definitive Guide, 5th Edition  

6.16. throw

An exception is a signal that indicates that some sort of exceptional condition or error has occurred. To throw an exception is to signal such an error or exceptional condition. To catch an exception is to handle it—to take whatever actions are necessary or appropriate to recover from the exception. In JavaScript, exceptions are thrown whenever a runtime error occurs and whenever the program explicitly throws one using the throw statement. Exceptions are caught with the try/catch/finally statement, which is described in the next section.^[*]

^[*] The JavaScript throw and try/catch/finally statements are similar to, but not exactly the same as, the corresponding statements in C++ and Java.

The throw statement has the following syntax:

throw expression;

expression may evaluate to a value of any type. Commonly, however, it is an Error object or an instance of one of the subclasses of Error. It can also be useful to throw a string that contains an error message, or a numeric value that represents some sort of error code. Here is some sample code that uses the throw statement to throw an exception:

function factorial(x) {
    // If the input argument is invalid, throw an exception!
    if (x < 0) throw new Error("x must not be negative");
    // Otherwise, compute a value and return normally
    for(var f = 1; x > 1; f *= x, x--) /* empty */ ;
    return f;
}

Flanagan, JavaScript: The Definitive Guide, 5th Edition

Example 7: Displaying Event Object Properties

This example uses DOM methods to display all the properties of the window.onload event object and their values in a table. It also shows a useful technique of using a for..in loop to iterate over the properties of an object to get their values.

The properties of event objects differs greatly between browsers, the W3C DOM 2 Events Specification lists the standard properties, however many browsers have extended these greatly.

Put the following code into a blank text file and load it into a variety of browsers, you'll be surprised at the different number and names of properties. You might also like to add some elements in the page and call this function from different event handlers.

The Three Grades of Support

C-grade

C-grade is the base level of support, providing core content and functionality. It is sometimes called core support. Delivered via nothing more than semantic HTML, the content and experience is highly accessible, unenhanced by decoration or advanced functionality, and forward and backward compatible. Layers of style and behavior are omitted.

C-grade browsers are identified on a blacklist. Approximately 3% of our audience receives a C-grade experience.

Summary: C-grade browsers are identified, incapable, antiquated and rare. QA tests a sampling of C-grade browsers, and bugs are addressed with high priority.

A-grade

A-grade support is the highest support level. By taking full advantage of the powerful capabilities of modern web standards, the A-grade experience provides advanced functionality and visual fidelity.

A-grade browsers are identified on a whitelist. Approximately 96% of our audience enjoys an A-grade experience.

Summary: A-grade browsers are identified, capable, modern and common. QA tests all A-grade browsers, and bugs are addressed with high priority.

X-grade

X-grade provides support for unknown, fringe or rare browsers. Browsers receiving X-grade support are assumed to be capable. (If a browser is shown to be incapable — if it chokes on modern methodologies and its user would be better served without decoration or functionality — then it is considered a C-grade browser.)

X-grade browsers include all browsers not on the C-grade blacklist or the A-grade whitelist. Approximately 1% of our audience receives the X-grade experience.

Summary: X-grade browsers are generally unknown, assumed to be capable, modern, and rare or fringe. QA does not test, and bugs are not opened against X-grade browsers.

The Relationship Between A- and X-grade Support

A bit more on the relationship between A and X grade browsers: One unexpected instance of X-grade is a newly-released version of an A-grade browser. Since thorough QA testing is an A-grade requirement, a brand-new (and therefore untested) browser does not qualify as an A-grade browser. This example highlights a strength of the Graded Browser Support approach. The only practical difference between A and X-grade browsers is that QA actively tests against A-grade browsers.

Unlike the C-grade, which receives only HTML, X-grade receives everything that A-grade does. Though a brand-new browser might be characterized initially as a X-grade browser, we give its users every chance to have the same experience as A-grade browsers.

Quality Assurance (QA) Testing

Grading the browser ecosystem enables meaningful, targeted, and cost-effective QA testing. As noted, representative C-grade testing and systematic A-grade testing ensures a usable and verified experience for approximately 99% of our audience. A-grade testing must be thorough and complete, while C-grade testing can be accomplished with one or two representative browsers (e.g., Netscape 4.x and Lynx).

It’s worth reiterating that testing resources do not examine X-grade browsers.

In the Oregon Experiment [Brand 1994][Alexander 1988] Alexander noted:

Alexander has noted that our mortgage and capital expenditure policies make large sums of money available up front, but do nothing to provide resources for maintenance, improvement, and evolution [Brand 1994][Alexander 1988]. In the software world, we deploy our most skilled, experienced people early in the lifecycle. Later on, maintenance is relegated to junior staff, when resources can be scarce. The so-called maintenance phase is the part of the lifecycle in which the price of the fiction of master planning is really paid.

Some years ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office.

“What do you think?” he asked. He was asking me to tell him my impressions of his operation and his staff. “Pretty good,” I said. “You’ve got some good people there.” Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

“What did you think of Fred?” he asked. “We all think Fred’s brilliant.” “He’s very clever,” I said. “He’s not very enthusiastic about methods, but he knows a lot about programming.” “Yes,” said the DP Manager. He swiveled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. “Fred did that. It’s the build-up of gross pay for our weekly payroll. No one else except Fred understands it.” His voice dropped to a reverent hush. “Fred tells me that he’s not sure he understands it himself.”

“Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. That matched my own impression of Fred very well. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”

“Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn’t really proved herself yet. We’ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren’t really difficult at all. Most of them turned out pretty simple. She hasn’t really proved herself yet — if you see what I mean?”

I saw what he meant.

Why do some individuals invest so much time and effort in posting free advice and information online, while others do so rarely, if at all? Research suggests that a powerful motivation for disproportionate gift giving in offline communities can be traced to status seeking (Harbaugh, 1998). In this article, we argue that status seeking is likewise an important factor in the provision of free advice and information in virtual consumer communities, and that this motivation deserves more attention from researchers who study the rise and evolution of virtual communities.

Our main argument is two-fold: First, we view status seeking as a social passion that drives participants to invest time and effort in giving the gift of their experience to others without direct benefit to themselves; and second, this social passion is a reliable source of continuing participation, making it more likely that virtual communities will survive and grow. In developing our argument, we draw heavily on research on offline communities that shows that gift giving is closely linked to status seeking (Sherry, 1983). In effect, contrary to early research on virtual communities, we maintain that there is no fundamental break when it comes to basic human motivation between "real" and virtual communities. The manifestation of the same motivation, however, will take a different shape in online communities because it is articulated under different conditions than those of offline communities. Thus status seeking operates in both virtual and offline communities. But whereas in real communities status seeking is associated with professional standing or conspicuous consumption, status seeking in online communities at present works primarily through the written word.

Criticism of the waterfall model

The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them (or, at least, the belief that this is impossible for any non-trivial program).

The fundamental problem that traditional software-development organization addresses is Brook's Law: ``Adding more programmers to a late project makes it later.'' More generally, Brooks's Law predicts that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly.

Brooks's Law is founded on experience that bugs tend strongly to cluster at the interfaces between code written by different people, and that communications/coordination overhead on a project tends to rise with the number of interfaces between human beings. Thus, problems scale with the number of communications paths between developers, which scales as the square of the humber of developers (more precisely, according to the formula N*(N - 1)/2 where N is the number of developers).

The Brooks's Law analysis (and the resulting fear of large numbers in development groups) rests on a hidden assummption: that the communications structure of the project is necessarily a complete graph, that everybody talks to everybody else. But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead. [SU]

8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' That correction is important; we'll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.

In Linus's Law, I think, lies the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.

 so an oral tradition is a good thing?

Since consistency of action is a common failure mode, we can safely predict that the documentation will not be up to date. In fact, I have not yet interviewed a successful project that had accurate documentation, unless either the code or the documentation was generated automatically. I did, however see a project fail because the developers were told to update all design documentation every time they made a change. Cost of development was just too high, and progress too slow, and the project was soon cancelled.

I ask maintenance people how they manage to make program updates, in the face of out-of-date documentation. Their answer is that they "just look around", they don't trust the documentation in any case - they just read the code.

I have come to rely on this "good at looking around" success mode of humans on projects and in methodology design.

When I interview a project, I always ask what caused them to succeed in the end. The single most common answer I receive is, "A few good people stepped in at key moments and did whatever was needed to get the job done." A typical such comment was carefully written up in NASA's "Deorbit flight software lessons learned" [NASA]:

"Perhaps most important for the long term, during the course of the project, a capable core team for rapid development of GN&C systems evolved. This included finding talented team members; training in and gaining experience with the tools, processes and methodology, and integrating into a cohesive team.

After working together in the RDL for a year, team members have acquired expertise in methods, tools and domain. A helpful and cooperative atmosphere has encouraged and enabled cross training. A willingness on the part of team members to address any and all project issues has proven invaluable on many occasion..." (my italics added for emphasis)

...this team can be a long term asset to the division and to the agency."

What causes people to do that? One plausible answer is, "good citizenship".

Perhaps we can increase the rate of project success simply by increasing the "sense of community and good citizenship" on the team. I actually don't propose that as a top recommendation, because I find that the sense of good citizenship is already generally high, and improper management is already taking too much advantage of it (see, for example, Death March [Yo]).

However, the idea does reveal a rarely mentioned element of methodology design:

"Community and citizenship"

should be among a project's central activities and measures, at least on a par with "code review and testing".

 qft -- see also Big Ball of Mud

 this is the kind of witticism that makes a good forum signature

a lot of users are hackers too. Because source code is available, they can be effective hackers. This can be tremendously useful for shortening debugging time. Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided.

6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.

 this process works just as well behind the firewall

This verse seems relevant to Web development for some reason...

 Examples of using apply(), because it comes up in
http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.1027832
and I wasn't sure what it did! 

 The second example is rad - a brief, fast(?) way to find the largets element in an array of numbers.

v v v

Always beginning with a working system helps to encourage PIECEMEAL GROWTH. Refactoring is the primary means by which programmers maintain order from inside the systems in which they are working. The goal of refactoring is to leave a system working as well after a refactoring as it was before the refactoring. Aggressive unit and integration testing can help to guarantee that this goal is met.

In the Oregon Experiment [Brand 1994][Alexander 1988] Alexander noted:

Alexander has noted that our mortgage and capital expenditure policies make large sums of money available up front, but do nothing to provide resources for maintenance, improvement, and evolution [Brand 1994][Alexander 1988]. In the software world, we deploy our most skilled, experienced people early in the lifecycle. Later on, maintenance is relegated to junior staff, when resources can be scarce. The so-called maintenance phase is the part of the lifecycle in which the price of the fiction of master planning is really paid. It is maintenance programmers who are called upon to bear the burden of coping with the ever widening divergence between fixed designs and a continuously changing world. If the hypothesis that architectural insight emerges late in the lifecycle is correct, then this practice should be reconsidered.

Brand went on to observe Maintenance is learning. He distinguishes three levels of learning in the context of systems. This first is habit, where a system dutifully serves its function within the parameters for which it was designed. The second level comes into play when the system must adapt to change. Here, it usually must be modified, and its capacity to sustain such modification determines it’s degree of adaptability. The third level is the most interesting: learning to learn. With buildings, adding a raised floor is an example. Having had to sustain a major upheaval, the system adapts so that subsequent adaptations will be much less painful.

PIECEMEAL GROWTH can be undertaken in an opportunistic fashion, starting with the existing, living, breathing system, and working outward, a step at a time, in such a way as to not undermine the system’s viability. You enhance the program as you use it. Broad advances on all fronts are avoided. Instead, change is broken down into small, manageable chunks.

One of the most striking things about PIECEMEAL GROWTH is the role played by Feedback. Herbert Simon [Simon 1969] has observed that few of the adaptive systems that have been forged by evolution or shaped by man depend on prediction as their main means of coping with the future. He notes that two complementary mechanisms, homeostasis, and retrospective feedback, are often far more effective. Homeostasis insulates the system from short-range fluctuations in its environment, while feedback mechanisms respond to long-term discrepancies between a system's actual and desired behavior, and adjust it accordingly. Alexander [Alexander 1964] has written extensively of the roles that homeostasis and feedback play in adaptation as well.

If you can adapt quickly to change, predicting it becomes far less crucial. Hindsight, as Brand observes [Brand 1994] is better than foresight. Such rapid adaptation is the basis of one of the mantras of Extreme Programming [Beck 2000]: You're not going to need it.

an examination of software development costs showed that problems were many times more expensive to fix during maintenance than during design. Surely it was best to mobilize resources and talent up-front, so as to avoid maintenance expenses down the road. It's surely wiser to route the plumbing correctly now, before the walls are up, than to tear holes in them later. Measure twice, cut once.

One of the reasons that the waterfall approach was able to flourish a generation ago was that computers and business requirements changed at a more leisurely pace. Hardware was very expensive, often dwarfing the salaries of the programmers hired to tend it. User interfaces were primitive by today's standards. You could have any user interface you wanted, as long as it was an alphanumeric "green screen". Another reason for the popularity of the waterfall approach was that it exhibited a comfortable similarity to practices in more mature engineering and manufacturing disciplines.

Today's designers are confronted with a broad onslaught of changing requirements. It arises in part from the rapid growth of technology itself, and partially from rapid changes in the business climate (some of which is driven by technology). Customers are used to more sophisticated software these days, and demand more choice and flexibility. Products that were once built from the ground up by in-house programmers must now be integrated with third-party code and applications. User interfaces are complex, both externally and internally. Indeed, we often dedicate an entire tier of our system to their care and feeding. Change threatens to outpace our ability to cope with it.

The incentives that drive the evolution of such systems can, at times, operate perversely. Just as it is easier to be verbose than concise, it is easier to build complex systems than it is to build simple ones. Skilled programmers may be able to create complexity more quickly than their peers, and more quickly than they can document and explain it. Like an army outrunning its logistics train, complexity increases until it reaches the point where such programmers can no longer reliably cope with it.

This is akin to a phenonmenon dubbed the PeterPrinciple of Programming by authors on the Wiki-Wiki web [Cunninghan 1999a]. Complexity increases rapidly until the it reaches a level of complexity just beyond that with which programmers can comfortably cope. At this point, complexity and our abilities to contain it reach an uneasy equilibrium. The blitzkrieg bogs down into a siege. We built the most complicated system that can possible work [Cunningham 1999b].

Variable and function names might be uninformative, or even misleading. Functions themselves may make extensive use of global variables, as well as long lists of poorly defined parameters. The function themselves are lengthy and convoluted, and perform several unrelated tasks. Code is duplicated. The flow of control is hard to understand, and difficult to follow. The programmer’s intent is next to impossible to discern. The code is simply unreadable, and borders on indecipherable. The code exhibits the unmistakable signs of patch after patch at the hands of multiple maintainers, each of whom barely understood the consequences of what he or she was doing. Did we mention documentation? What documentation?

BIG BALL OF MUD might be thought of as an anti-pattern, since our intention is to show how passivity in the face of forces that undermine architecture can lead to a quagmire. However, its undeniable popularity leads to the inexorable conclusion that it is a pattern in its own right. It is certainly a pervasive, recurring solution to the problem of producing a working system in the context of software development. It would seem to be the path of least resistance when one confronts the sorts of forces discussed above. Only by understanding the logic of its appeal can we channel or counteract the forces that lead to a BIG BALL OF MUD.

One thing that isn’t the answer is rigid, totalitarian, top-down design. Some analysts, designers, and architects have an exaggerated sense of their ability to get things right up-front, before moving into implementation. This approach leads to inefficient resources utilization, analysis paralysis, and design straightjackets and cul-de-sacs.

As a system nears completion, its actual users may begin to work with it for the first time. This experience may inspire changes to data formats and the user interface that undermine architectural decisions that had been thought to be settled. Also, as Brooks [Brooks 1995] has noted, because software is so flexible, it is often asked to bear the burden of architectural compromises late in the development cycle of hardware/software deliverables precisely because of its flexibility.

This phenomenon is not unique to software. Stewart Brand [Brand 1994] has observed that the period just prior to a building’s initial occupancy can be a stressful period for both architects and their clients. The money is running out, and the finishing touches are being put on just those parts of the space that will interact the most with its occupants. During this period, it can become evident that certain wish-list items are not going to make it, and that exotic experiments are not going to work. Compromise becomes the "order of the day".

 from the comments

 from the comments

 so you're saying, have daily scrum over Campfire, and meet face to face once a week, outside the office?  Sounds great!

 this is how to get wget to enter a username and password.  The manpage says something else O.o

Wasn't object-oriented software supposed to take the labor out of programming?

Yes, that was the promise, but it didn't exactly pan out. Unless it's been designed for reuse, you're going to have a really hard time taking software off the shelf. Research shows that, in order for software to be designed for reuse, it usually needs to be deployed in three different contexts.

Inheritance has made things more confusing, too. With inheritance, you write a class, and you write its methods, using traditional terminology; and then if you make a sub-class, you inherit the methods and maybe you augment them in various ways. But deep inheritance trees could cause confusion because of the amount of inheritance that you have to track and understand. So, you actually didn't get much benefit. Basically, because there's so much work involved in making things reusable, it doesn't usually get done. But the Java language is pretty successful, and folks write lots of apps in it.

With the Feyerabend Project, we're aiming at development efficiency, and thinking in terms of computers helping us grow the code rather than people typing it in, or taking it off the shelf. We have to open our minds to what's really happening, not what we hope is happening.

In the 1990s, the Internet changed the scale of things dramatically. By the middle of the 1990s, Smalltalk had made a lot of inroads in the business world, and Java technology (although no one at Sun thought this way) followed the Smalltalk path, and then displaced it. I mean, Smalltalk was a server-side technology -- though the Smalltalk companies didn't like that -- and Sun initially thought of Java technology as client-side. Now Java software has its best successes on the server-side. And the customers are the same. The Java language rode on the coattails of C++ also, and didn't really replace C++, but certainly has taken a big chunk of its mental real estate.

And now, since we've been doing objects for about ten years with pretty good success, we don't look at functional languages, or logic-based languages, or declarative languages -- we don't look at lots of different things that we used to.

I think developers already know but are a little afraid to admit that writing software is a creative activity that requires a lot of interaction with the people who are going to use it. Writing software is a highly iterative, dynamic process requiring user feedback. Again, it's like writing poetry in that you write some of it, and then you respond to it, which triggers more creativity, and you keep going. Then, you show it to someone whose opinion you respect, and you see it differently.

Some of the more agile methodologies like Extreme Programming use this process. Extreme programmers discuss with end users what to build first. Then they spend a couple of weeks building, and show it to the end user. The end user uses it for a while, and then might say, "Oh, now I understand." Customers might not have a good understanding of what needs to be done since they're not programmers. Something they might not even have imagined might be doable.

Abraham Lincoln's habit was to walk into the War Department telegraph office, open the drawer containing copies of all the telegrams received, and read them all, regardless of to whom they were addressed. Through this procedure Lincoln had a keyhole into the thinking of his generals and activities in the field. The "cc" and "Reply All" function of email provides a similar opportunity for us to stay informed.

Ecc 12:6

Or ever the silver cord be loosed, or the golden bowl be broken, or the pitcher be broken at the fountain, or the wheel broken at the cistern.

Atlanta opera singer turned crime blogger Steve Huff

MyDeathSpace

the War Before Civilization by Lawrence Keeley

Robert Conquest's Second Law of Politics

"We set the anchors to block-level elements so we can control all aspects without worrying about the inline box"

What is the "inline box" and why would I worry about it in the first place???

http://www.html.it/articoli/niftycube/index.html

http://www.vertexwerks.com/tests/sidebox/