Eric Raymond rants about the CUPS (Common Unix Printing System) interface, and suggests asking some questions in the context of UI design:

If you are out there writing GUI apps for Linux or BSD or whatever, here are some questions you need to be asking yourself:

1. What does my software look like to a non-technical user who has never seen it before?
2. Is there any screen in my GUI that is a dead end, without giving guidance further into the system?
3. The requirement that end-users read documentation is a sign of UI design failure. Is my UI design a failure?
4. For technical tasks that do require documentation, do they fail to mention critical defaults?
5. Does my project welcome and respond to usability feedback from non-expert users?
6. And, most importantly of all...do I allow my users the precious luxury of ignorance?

While the News.com article focuses on Sun's plans to offer per-citizen pricing for its software, what is interesting is how it itends to tier the pricing based on country category.

Sun will sell its Java Enterprise System server software and its Java Desktop System for personal computers using three pricing tiers based on the United Nations' definitions of countries as "developed," "developing" and "least developed," Schwartz said.

"Across Asia and the world, there is an opportunity to grow the market by providing per-citizen pricing for network services as well as delivering per-citizen pricing for a full-up desktop," Sun's Jonathan Schwartz said. "The governments that I spoke with last week are interested in investing in networking their economies and networking their populations," a move that's "reminiscent of what the U.S. government did 100 years ago and 80 years ago with rural electrification and highway acts."

The article in Business Week is indicative of the upheaval that's coming in the telecom world:

On Feb. 12, the Federal Communications Commission ruled that a voice communication between two people using PCs is more like an e-mail than a phone call. This decision on a petition brought by Jeff Pulver, the entrepreneur behind the Free World Dialup Internet phone service, meant that the hundreds of thousands of people who now use broadband connections for voice conversations can continue to do so unmolested by the tariffs that are levied on traditional phone calls to support 911 service and universal access to the phone network.

Replace Pulver, whose system now has 175,000 users, with Microsoft (MSFT ), however, and the FCC ruling could have enormous significance. The software king has for years made noises about augmenting the voice-communication capabilities in its operating system to allow any two Windows PCs to create a voice link over the Net.

"The Pulver petition becomes important for the market when Microsoft pushes a voice product," say Blair Levin, an analyst with Legg Mason and former chief of staff at the FCC under William Kennard during the Clinton Presidency. "If you can turn each Windows PC into a voice device, you suddenly have a whole new phone network that never touches the public switched telephone."

The Windows XP operating system already contains so-called session initiation protocol (SIP) software. SIP is an industry-standard technology that defines how computers interact with the public phone network, instant-messaging software, and Internet telephony networks and applications. The Pulver decision effectively clears the way for Microsoft to move forward on these initiatives without worrying about getting tapped to pay charges and fees levied by on regular phone companies and wireless carriers -- and possibly in the future on VoIP providers that don't use direct PC-to-PC connections.

In an effort to start tying these loose ends together, last August Microsoft launched its Live Communications Server (LCS). This piece of software could turn into the killer phone application that SBC feared. Aimed at big corporations seeking to leverage their PCs to create unified communication systems on the desktop, LCS can perform a wide variety of tasks, from creating secure instant-messaging connections to alerting members of a workgroup that a key document has been posted to a virtual whiteboard.

Dan Schoenbaum writes:

IT projects fail because we often approach the software development process with reckless abandon. We have thrown the proven engineering principles and processes that other disciplines adhere to right out the window. We are lax in planning, we have few standards and design principles.

If we do create a blueprint for our applications, the team that lays the bricks rarely follows it. When building (coding), we deviate from our specifications. We shield the coders from the architect, we shield the quality testers and the maintenance crew from the coders and we shield the whole team from an understanding of what the homeowner (the software user) expects and needs from the final product.

The simplest of questions, really, but one that is often forgotten in the increasingly desultory effort that is modern software development: What is this application supposed to do or help its user do better?

It is the answer to this question that must drive our software development projects and serve as the foundation for a radical change in the way we develop, deploy and manage our applications.

Organizational silos make it easy for us to lose sight of this question and even easier for us to build software without keeping in mind that an application's raison d'etre is tied to the answer.

The various arms of an IT organization often operate in a vacuum with no knowledge of how their efforts relate to the purpose and intended use of the finished software product. Therefore, the second step to better software is to break down these silos. Bring the development team closer to the customer, close the gap between the builders and the testers and unite the process with the plan.

By imparting the entire software development team with a clear understanding of what the application they are building is supposed to automate, streamline or facilitate, the lines between the software development disciplines are blurred and all can focus on a common goal: build an application that does what it is supposed to do--and does it well.

This process starts with a blueprint. A map that guides the entire IT team through the effort of building, testing and maintaining an application that meets the business needs of the customer. This blueprint ensures that the builders lay every brick with the software's purpose and goal in mind. It should also enable the developers to consider testing in the early stages of construction and help quality assurance departments to understand the way in which the application will be used.

Breaking down silos, uniting the phases of the software lifecycle and creating a blueprint that each can understand and use is no simple proposition. But, the state of software is no small problem. The only solution to the lack of quality and the increasing complexity of software is to make drastic changes in the way we employ people, processes and tools to design, build and deploy it.

NYTimes writes about the economic challenge that China poses:

The welcome that China is offering to multinational companies and foreign investment has left many Western business executives, so critical of a closed Japan more than a decade ago, enthusiastically embracing China, its cheap work force and its huge markets.

But that same openness — combined with China's vast population of 1.3 billion and military muscle — makes it an even greater long-term economic challenge to the United States than Japan seemed to be in the 1980's, according to a growing number of executives, economists and officials.

While China's economy is still one-third the size of Japan's, the potential size of its market has made it very hard for companies to say no when Beijing officials demand that they build factories, transfer the latest technology or adopt Chinese technical standards.

Japan has effectively run out of low-wage workers for its industries, and quickly brought much of its economy up to and in some cases beyond Western technological standards. China still has vast reserves of cheap labor in inland areas and many backward industries that can grow swiftly as they copy Western and Japanese methods.

"China could do what Japan did, as a very fast follower, but China could do it bigger and better and for a longer period of time," said Steven Weber, an Asia scholar at the University of California at Berkeley. "It's not necessarily as vulnerable as Japan was."

But while Japan's danger to other economies over the last decade has taken the numbing forms of economic stagnation and political lassitude, China poses the risk of fast, sharp shocks.

Its transition from a planned economy to a form of capitalism seems to make it especially susceptible to economic booms and busts, and Chinese officials have begun worrying that an unsustainable economic bubble is developing. At the same time, China's one-party system may struggle to adapt to the social tensions brought to the surface by rapid economic development.

Optimists see it surmounting such obstacles. "Once China passes the high growth, it will have the bursting of the bubble," said Eisuke Sakakibara, Japan's former vice minister of finance for international affairs, "but that will happen in 20 years. China is Japan of the 1960's."

[via Shashdot] ACM Queue has an article by Jonathan Blow on how game development has evolved over the past two decades:

In the past ten years, games have ballooned in complexity. Now the primary technical challenge is simply getting the code to work to produce an end result that bears some semblance to the desired functionality. To the extent that we optimize, we are usually concerned with high-level algorithmic choices. There's such a wide variety of algorithms to know about, so much experience required to implement them in a useful way, and so much work overall that just needs to be done, that we have a perpetual shortage of qualified people in the industry.

Making a game today is a very different experience than it was even in 1994. Certainly, it's more difficult. In order to talk about specifics, I've classified the difficulties into two categories: problems due to overall project size and complexity and problems due to highly domain-specific requirements. Though this will help me introduce the situation in stages, the distinction between the two categories is a bit artificial; we will come full-circle at the end, seeing that there are fundamental domain-specific reasons (problems due to highly domain-specific requirements) why we should expect that games are among the most complicated kinds of software we should expect to see (problems due to overall project size), and why we should not expect this to change for the foreseeable future.

For all-round development of India, it is necessary for agriculture to become more efficient. This will increase rural incomes and free up labour for other kinds of production. The numbers of people involved in agriculture have to come down dramatically. This labour has to shift to production and services.

India is a large country. We cannot develop purely on the basis of services. People in India need to buy food, need homes to live in, and need vehicles for transportation. All of this has to be manufactured. Our population is too large to build an economy purely based on import of manufured goods and export of services. Domestic production needs to grow.

Writing for Bloomberg, Andy Mukherjee puts the challenge in perspective:

India's 700,000 computer software professionals may be hogging the limelight as the biggest beneficiaries of the exodus of U.S. white-collar jobs to developing countries.

Yet, for those who believe India will catapult itself from poverty to prosperity on the strength of its “knowledge'' industries, here's a sobering statistic: three-fourths of Indian workers, or 300 million people, don't have high-school diplomas.

India's educated elite is too small, and its purchasing power too limited, to lift the broader economy. What can really make India prosperous is something that will boost the incomes of workers who are stuck in low-productivity occupations -- farmhands and housemaids -- that pay the national average of $500 a year, or less.

And that something can only be manufacturing.

“The services sector, and in particular the knowledge-based industries, is unlikely to provide opportunities to the poorly educated sections of our society,'' say Sanjay Jain and Uday Bhansali of the consulting firm Accenture India in a study titled “Making Indian Manufacturing Globally Competitive.''

Create more factory jobs, and India's economic growth rate can easily accelerate to 10 percent a year, making it the fastest- growing major economy in the world, the authors argue.

Thanks to the blinkeredness left over from Soviet-style socialism of 1960s and 1970s, the Indian industry treats the local population, a large part of which earns subsistence wages, as the main source of demand for factory-made goods. Manufacturers go on producing large volumes of low-quality, low-margin products to turn a profit. Much of what they make, can't be exported.

Where does one begin to break the vicious cycle? The surefire way is to “force'' Indian manufacturers to tap global demand, so they're able to expand operations, and create more and better-paying factory jobs. As more workers find employment in manufacturing industries, they'll have the spending power to demand better goods and services.

In a chaotic democracy like India, how does one draw out local manufacturers and make them go global? The easiest way is to open more of the domestic consumer-goods market to overseas investors. Competitive pressures, thus unleashed, would ripple through the supply chain and force even small manufacturers to look beyond the local market.

Tomorrow: The Process (continued)