Paul M. Jones

Make government smaller and we get more of what we really can do together. And it’s not just more stuff, more gadgets, more material well-being. We do get more stuff and that’s pleasant, but that isn’t what gives life deep meaning. Deep meaning and true satisfaction comes from working with others on something bigger than ourselves. That comes from building our family. That comes from striving to reach something that exceeds our grasp. That’s what we get more of when government gets smaller.

via The romance of government vs. the reality.

Instead of pushing for "constructive" free market reforms, libertarians should doggedly focus on austerity: opposing spending increases, and pushing spending cuts. Instead of trying to "privatize" Social Security, for example, libertarians should push for lower benefits, a higher retirement age, and means testing. Instead of pushing for school choice, libertarians should try to restrain/shrink education budgets and push user fees. If libertarians have any political success, this will automatically expand the role of the market. After all, the less government does for people, the more they will do for themselves. Dissatisfied with government provision, people will save more for their own retirement and spend more on private education. In the limit, once the flow of government money ceases, voluntary exchange is all that's left.

via Austerity for Liberty, Bryan Caplan | EconLog | Library of Economics and Liberty.

A new report by the Federal Reserve points to "widespread signs of deceleration" in the U.S. economy. No kidding! These signs follow what the Fed calls a "burst" of growth in the last quarter of 2009 and first quarter of 2010 triggered by President Obama's $862 billion stimulus package. Unfortunately, the burst failed to help anybody except special interests like unions and public employees. Note the Fed's evasive word choice: Another word for "decelerating" would be "contracting."

via Examiner Editorial: Bribing the public with the public's money | Washington Examiner.

Everyone also acknowledges that tax compliance continues to be a major problem here. Indeed, a retired businessman says if Greeks had actually paid all the taxes owed over the past decade or so, they wouldn't be in nearly such bad shape. Of course, we noted that tax compliance has been very good in the U.S., especially when compared to the rest of the world. This means we don't have a large source of potential revenue available simply from doing a better job enforcing existing tax laws.

On this score, we can understand why the Obama administration is ramping up the size of the IRS, and stepping up tax enforcement. They plan massive tax increases for Americans, including a myriad of fees and mandates embodied in health care and other complex and detailed legislation. They know that a result of this will be that tax compliance in the United States will be "Europeanized" -- along with everything else.

via Power Line - Ray Hartwell reports from Greece.

For all its horror, 9/11 was not a declaration of war by radical Islam.

Rather, it was a dramatic escalation of a war that had begun decades earlier -- in Ayatollah Khomeini's Iran, in the bombing of the US Marine barracks in Lebanon, in the first World Trade Center bombing and in the attack on USS Cole.

...

For sure, former British Prime Minister Tony Blair gets it. The West, he says, is under attack by an ideology -- and "its roots are deep, its tentacles are long and its narrative about Islam stretches far further than we think."

And, he warns, "a lot of people don't understand that this is a generational-long struggle. And I think one of the . . . debates we've got to have in the West is -- are we prepared for that?"

That truly is the question.

via September 11: Beyond Mourning--Editorial - NYPOST.com.

Maybe everybody else in the world knew this already, but I didn't. The architect of the WTC towers designed them specifically as references to Mecca:

Yamasaki received the World Trade Center commission the year after the Dhahran Airport was completed. Yamasaki described its plaza as "a mecca, a great relief from the narrow streets and sidewalks of the surrounding Wall Street area." True to his word, Yamasaki replicated the plan of Mecca's courtyard by creating a vast delineated square, isolated from the city's bustle by low colonnaded structures and capped by two enormous, perfectly square towers--minarets, really. Yamasaki's courtyard mimicked Mecca's assemblage of holy sites--the Qa'ba (a cube) containing the sacred stone, what some believe is the burial site of Hagar and Ishmael, and the holy spring--by including several sculptural features, including a fountain, and he anchored the composition in a radial circular pattern, similar to Mecca's.

View of a World Trade Center TowerView of a World Trade Center towerAt the base of the towers, Yamasaki used implied pointed arches--derived from the characteristically pointed arches of Islam--as a transition between the wide column spacing below and the dense structural mesh above. (Europe imported pointed arches from Islam during the Middle Ages, and so non-Muslims have come to think of them as innovations of the Gothic period.) Above soared the pure geometry of the towers, swathed in a shimmering skin, which doubled as a structural web--a giant truss. Here Yamasaki was following the Islamic tradition of wrapping a powerful geometric form in a dense filigree, as in the inlaid marble pattern work of the Taj Mahal or the ornate carvings of the courtyard and domes of the Alhambra.

The shimmering filigree is the mark of the holy. According to Oleg Grabar, the great American scholar of Islamic art and architecture, the dense filigree of complex geometries alludes to a higher spiritual reality in Islam, and the shimmering quality of Islamic patterning relates to the veil that wraps the Qa'ba at Mecca. After the attack, Grabar spoke of how these towers related to the architecture of Islam, where "the entire surface is meaningful" and "every part is both construction and ornament." A number of designers from the Middle East agreed, describing the entire façade as a giant "mashrabiya," the tracery that fills the windows of mosques.

Link via Capitalism's Mecca, original article at Bin Laden's special complaint with the World Trade Center. - By Laurie Kerr - Slate Magazine.

We've all heard of Fred Brooks' law regarding the mythical man-month. (If you have not heard of it, stop reading this and go read The Mythical Man Month). The rule is this:

Adding manpower to a late software project makes it later.

He concludes his essay with these words:

The number of months of a project depends on its sequential constraints. The maximum number of men depends on the number of independent subtasks. From these two quantites one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months.

Once a development project has started, and appears to be taking longer than desired, adding more developers will make the project more-late. Brooks explains that there are two reasons for this:

1. It takes at least one developer, often more, to brief, train, educate, and otherwise inculcate the new developers into the project. That developer is unproductive during this time, and so are the new developers.

2. The amount of communication between everyone on the project increases exponentially with each new developer added, but the amount of productivity only increases linearly.

But exactly how bad is the falloff in productivity? "Adding people will make it more late", but just how much later will it be? Is there a way to predict the schedule effects of adding developers?

Point 1 (the training of the new developers by one or more existing developers) is relatively easy to model. If you add one new developer, and it takes one existing developer a week to train him, then you just added at least a week to the schedule when neither of them is productive. The existing developer got no productive work done, and neither did the new one.

After that, the developers have to make up the lost time. To discover the effect of point 2 above (the communication costs involved once a new developer is in place), I plugged some numbers into a spreadsheet. The communication costs are quite dramatic.

Below is a table representing a one-developer project, along with the communication costs and resulting schedule compression when adding developers. I'll give some narrative about the table afterwards, and then close with some very strong caveats.

Do not interpret this as science; at best, it is an initial guide to expectations, subject to further revision as I explore the topic more deeply.

In the first row, we have the baseline case. One developer doesn't have to talk with anyone else, so there are no communication costs. By default, his productivity rate is 100% of whatever he would normally do, so his output is also at 100%. If the one-man project is estimated to take 10 weeks, then it takes 10 weeks (a time factor of 100%).

Now, let's say we add another developer. The first thought is that the project should now take half as long (5 weeks). But! Although we have now two developers, they have to spend time talking to each other and coordinating their activity. That means we have 2 "units" of development happening, but an additional "unit" of communication. Some of the combined effort of the two developers is spent talking to each other. Instead of getting 100% more productive output (two developers instead of one), they are together only about 33% more productive. That means the remaining project time won't be cut to 50%; instead, it will be reduced to 75% at best. (And to boot, if we spent a week training the new developer, it means we need to add that week to the schedule as well.)

It only gets worse from there. 3 developers means 3 lines of communication (i.e., each one has to talk to the other two developers). That will cut the remaining project duration down to 67% of the previously scheduled time. Adding the third developer only gained us 8 percentage points of duration savings over having two developers. At this point we have tripled the cost of development, but only save 33% of remaining project time, not counting the time lost in training the new developers.

4 developers is 6 lines of communication, and a schedule compression of 63% (i.e., only 4 percentage points better than 3 developers). 5 developers is 10 lines of communication, for a schedule compression of 60%. No matter how many developers we add to the single-developer programming job, it looks like we will never cut the remaining project time in half.

I find this rather depressing.

Now, some very strong caveats:

1. We presume the work being performed in the situation modeled above has to be done sequentially. If the work can be done concurrently or in parallel without additional planning, training, or communication, we can probably ignore the diminishing returns indicated by the table, since the developers don't have to talk to each other.

2. The amount of time spent in communication is assumed to be equal to the amount of time spent developing work product. We can game this a little bit by changing the "communication" column to some percentage of the number of communication links. This would show much better numbers, but my intuition tells me that it would not map to reality; it is my experience that just as much time is spent coordinating (and then regaining "flow") as is spent developing work product.

3. Each developer is presumed to be roughly as productive as each other developer. However, even the most productive developers will eventually be overwhelmed by the volume of communications, and if they spend time training new developers, their productivity drops to zero for that period.

4. The developer(s) being added are presumed beforehand to be familiar with the project, its history, and its idiosyncrasies. If the developers are not already so familiar, it means the one or more of the developers already working on the project has to stop working and spend time bringing the new developer(s) up to speed. That makes the productivity reduction even more dramatic, and is a key factor in making the late project later.

Finally, some conclusions:

• I think caveat #4 above is really important in relation to Brooks' Law. It makes me think that the above table probably describes the best case scenario when adding developers; i.e., if nobody has to train the new developer, then you don't lose the training time, but you still don't get twice as much productivity from adding a second developer.

• Caveat #4 also implies to me that, if we want to compress the development schedule, the time to add developers is at the beginning of a project, not later on, so that they all learn the project as they go. But even then, it won't result in enough schedule compression to warrant adding more than one or two extra developers to a single-developer project.

I said earlier, and I'll say again now: This is not science. It is the beginning of an exploration of how to reliably manage resources and make schedule predictions. If you have questions, concerns, insights, alternative analysis, or experiences you would like to share on this topic, please leave a comment below.

The central tension in the software process comes from the fact that we must go from an informally identified need that exists in-the-world to a formal model that operates in-the-computer.

From "Beyond Programming" by Bruce Blum, as quoted in "The Design of Design" by Frederick P. Brooks Jr.

It is time to question the meaning of the words “education reform” and the investment in reforming the current system. Once the automobile was invented, there was no need for “buggy whip reform” or “horse turnaround plans.” Mr. Khan, and those like him, have exposed the current system for the obsolete monopoly that it is. This article lays waste to the idea of “reforming” the current system. The best thing we can do is rapidly manage the transition to an entirely new education model.

via Chicago Boyz » Blog Archive » The Worth of Khan.

This afternoon James Jay Lee, a crazy person with a gun, a bomb, and an anti-human manifesto inspired by Al Gore’s An Inconvenient Truth, took hostages at the offices of the Discovery Channel in Silver Spring. He was shot and killed by police. The hostages were freed, unharmed.

How many Tea Party types have done this? Oh right, *zero*. Via Gun-wielding ecoterrorist calls for reduction in human population, gets wish | The Daily Caller - Breaking News, Opinion, Research, and Entertainment.