Operations Management

A LEVEL BUSINESS STUDIES AND AVCE BUSINESS

Operations Management, Chris Vidler, (part of the 'Studies in Economics and Business' series), Heinemann, 2001, paperback, 121 pages, L6.99, ISBN 0-435-33225-2, Tel 01865 888058, http://www.heinemann.co.uk

Heinemann's 'Studies in Economics and Business' series is designed to support AS and A level courses. It is now also very relevant to the AVCE option units in Business. The book is very readable and provides up-to-date coverage of a range of functions and concepts in operations management. It both introduces the subject and provides depth not found in the generic course texts.

The topics covered include the input-output model of processing, costing and breakeven, location, planning and controlling operations, project management, managing inventory (stock control) and the full range of contemporary practices related to quality assurance - such as Kaizen, TQM, benchmarking and lean production.

Each of the nine chapters is devoted to one of the above areas and uses a variety of straightforward diagrams to illustrate the techniques or methods covered. The text is broken down into manageable 'chunks' through effective use of sub-headings, bold and bullet points. Each chapter also has a small box of 'key words', details of books for further reading, useful websites and typical questions for exam practice from all of the awarding bodies.

The book is designed to 'stimulate and challenge students.to think critically about business studies' and thereby 'help you get a better grade'. This has certainly been achieved in the final chapters on quality issues, where the introduction of Japanese models into a British culture is discussed 'critically and analytically'. The earlier chapters, however, are much more descriptive and do not really pave the way for the questions which follow. Conversely, for the AVCE student needing a more vocational approach, with the exception of critical path analysis, some of this description lacks the depth and detail required at this level. The case studies and data response questions would benefit from more focussed questions, perhaps differentiating between AS, A level and AVCE in their nature and approach.

The book would have benefited from more rigorous proof reading. It is somewhat ironic to find so many typographical errors in a text which devotes so much of its content to quality assurance!

In spite of my minor criticisms, I shall certainly be keeping a copy of this book handy. It neatly covers all of the operations management content in one small volume, and at L6.99 is good value. For student use, probably a class set would be the most cost-effective way of providing a specialist source of information when this area of the syllabus is being studied. It will certainly be my first port of call when next preparing materials on critical path analysis and stock control.

Jill Turner, AQA Principal Examiner for AVCE option unit 'Managing Production',

Resources Manager for Business and Economics Education, Institute of Education

What factors attract foreign direct investment?

INTRODUCTION

Increasingly the world is becoming globalised and the riots at Seattle, Stockholm and Genoa provide some evidence of the power and control of Multinational or Transnational Companies (MNCs/TNCs) and the subsequent backlash against this. The forces that have led to the growth of MNCs/TNCs are manifold but would include the reduction in trade barriers, the development of the global triad trading block system (South East Asia and China, Europe, and North America), the liberalisation and deregulation of markets, the move towards world-wide privatisation, strategic decisions by organisations that wish to dominate world markets as their domestic market growth rates have slowed down, and the increased competition some organisations are finding in their domestic markets. All these factors together have seen the growth almost year-on-year of foreign direct investment (FDI), as organisations seek to take advantage of market and cost saving opportunities both within Europe and in the UK in particular.

Whilst a growing number of econometric and survey-based studies have been published that focus on the key influences which determine inbound FDI at the national level, relatively few studies exist into the forces which affect the distribution of FDI between UK regions. The aim of this paper is to rectify this omission by seeking to identify and analyse a set of factors that influence the attraction of inbound FDI to UK regions.

LOCATIONAL CHOICE OF FDI BY TNCs

Theoretical work by Stopford and Strange (1991) and Dunning (1993) suggests that four main factors determine the national and regional location of FDI by transnational corporations (TNCs). These are: (physical, labour or technological); the search for markets (following customers, suppliers or competitors abroad, seeking increased familiarity with the local business environment or reducing their costs of supplying a foreign market); the search for efficiency (exploiting different factor endowments, cultures, institutional arrangements, economic systems and policies and market structures); and finally the search for strategic assets (enabling them to sustain and advance their international competitive advantages). In addition, national and regional resource endowments; market access and potential; favourable competitive positions; strong consumer demand; and favourable government policies can all help in attracting FDI to specific national and regional locations.

This paper focuses on three main 'influencers' of inbound investment: market, resources, and efficiency-seeking FDI. Strategic asset-seeking FDI is excluded from the study, since it proved incapable of measurement using the published UK data available at the time of the preliminary study.

EARLIER STUDIES

Studies carried out in the USA and the UK provide further support for the importance of resources, market and efficiency considerations in determining the distribution of inbound FDI at the regional level. A number of American studies (Bagchi-Sen and Wheeler, 1989; McConnell, 1980; Mandell and Killian, 1974; Arpan and Ricks, 1995) suggest that market-related factors, such as market proximity, population size and growth rates, levels of per capita retail spending and regional infrastructure provision are also found to be of importance in attracting FDI at the regional level. Other studies (Little, 1978; Glickman and Woodward, 1988; Mandell and Killian, 1974 and Arpan and Ricks, 1995) indicate that the location of FDI is especially sensitive to resource-based influences, such as labour availability, wage differentials and educational attainment levels. Efficiencyrelated factors including government aid, state spending levels, regional taxation levels and the level of industrial development in host regions are also significant (see McConnell, 1980; Mandell and Killian, 1974; Arpan and Ricks, 1995).

Studies based on UK regional data provide broad support for these American findings. Market-related influences such as infrastructure investment (Hill and Munday, 1991) and high population density (Billington, 1999) are considered to be significant in attracting inbound FDI to particular UK regions. In terms of resources, Billington (1999) suggests that high unemployment and related labour availability can both exercise a significant positive impact on FDI inflows at the regional level, whilst Collis and Noon (1994) show that high unit wage costs can have the opposite effect. Taylor (1993) and Billington (1999) provide evidence of efficiencyseeking FDI, arguing that preferential assistance to depressed regions and the regional industrial mix both exert a strong influence on the distribution of inbound FDI amongst UK regions. Hill and Munday (1991 and 1992) also find that government regional policy, based on regional preferential assistance and infrastructure spending, can help in attracting FDI towards particular UK regions.

CHANGES IN THE REGIONAL DISTRIBUTION OF INBOUND FDI

Recent research evidence (Roberts et al, 1988; Collis et al, 1989; Hill and Munday, 1992, Meyer and Qu, 1995) suggests that changes have occurred in the distribution of inbound FDI between UK regions since the early 1970s. The heavy concentration of FDI in the south-eastern core of the UK economy has given way to a more even distribution, in which peripheral regions such as Scotland, Wales and the North of England, and latterly, intermediate regions such as the West Midlands have been increasingly favoured by foreign investors. These findings form the basis for the present study, and for the choice of regions included in it.Data from the West Midlands and Scotland have been chosen as the basis for this study, due to the relative success which both have achieved in attracting inflows of FDI, compared with other UK regions.

SCOTLAND

Over 900 foreign-owned companies now have bases in Scotland, including Motorola, Compaq, NEC, IBM and Sun Microsystems (Invest UK, 2001). Over the nine-year period from 1991 to 2000, 742 inward investment projects were undertaken in the region, leading to planned investment levels of 8,974 million, and to the creation or safeguarding of 112,431 jobs (Locate in Scotland, 1991 to 2000).

The market for FDI in Scotland is geographically diverse, although new projects, capital inflows and job creation have been dominated by United States and UK-based donor companies over the period from 1991 to 2000. Smaller, but nonetheless substantial inflows of FDI have also been attracted from companies based in mainland Europe and the AsiaPacific region (Locate in Scotland, 2000).

In sectoral terms, Scotland has achieved particular success in attracting inbound FDI to its electronics and services industries. Taken together, these sectors accounted for 46% of all new foreign direct investment projects in the region between 1994 and 2000 (during which time electronics brought in 23% of FDI and services 25%). Scotland is now home to a key cluster of over 420 electronics companies (158 owned by overseas firms), which together make up 'Silicon Glen,' arguably 'the largest concentration of electronics companies anywhere in Europe' (Invest UK, 2001). Scotland's electronics industry has achieved this position due to a decade of rapid and sustained growth in output and product sales, while the region is now at the forefront of global technology developments in the electronics sector (Locate in Scotland, 2001). The industry also possesses strength in diversity, since Scotland claims to have 'Europe's largest concentration of semiconductor fabricators,' together with a number of leading global players in the 'computer, consumer electronics, office products and telecommunications equipment' markets (Locate in Scotland, ibid.).

In the years since 1996, Scotland's services industry has replaced electronics as the prime target for inbound FDI in both volume (number of new projects), value (capital investment) and employment (job-creation and safeguarding) terms. Service sector activities now account for 38% of inbound FDI projects, 19% of investment and 39% of planned jobs

(Locate in Scotland, 2000). Services FDI in Scotland covers a broad compass, including higher value-added activities such as electronics design and biotechnology research, design and development (R,D&D). The financial services sector has also shown strong interest in investing in the region, as has the dot.com sector (until recently), while Scotland is attracting increasing attention as a location for major call centres (Locate in Scotland, 2000).

UK government sources suggest that a range of factors may have been important in attracting FDI to Scotland, including market-related factors such as the size of its population (5.1 million) and the quality of its infrastructure. Resourcesrelated factors, such as its 'highly skilled, flexible workforce;' and efficiency-related factors, including Scotland's status as a 'major centre for high-tech R,D&D' also appear to play an important role (Invest UK, 2001). High valued added activities in the electronics and R,D&D sectors can be expected to be attracted to Scotland by the agglomeration economies available in 'Silicon Glen', by the high quality of Scotland's human skills capital and by the sophistication of Scotland's telecommunications network. Market related factors such as the availability of a high-speed distribution infrastructure could also be considered to be powerful incentives driving the location of such FDI in Scotland. On the other hand, lower value-added activities such as financial services and call centres may be more attracted by resource related factors, such as the availability of a pool of affordable labour (due to Scotland's relatively high unemployment and relatively low wage rates) (Locate in Scotland, 2001).

THE WEST MIDLANDS

The West Midlands has long been established as a major European region for attracting inward investment. In 2000 it was the UK's most successful region in attracting foreign direct investment, and was amongst the top five in Europe. Of the 40 per cent of foreign investment in the EU, the West Midlands consistently secures 20 per cent of these projects.

Much of the FDI into the West Midlands has traditionally been headed by activity into the industries in which the region is strong, such as automotive, added value engineering, rubber and plastics, manufacturing and food and drink. However, towards the end of the 1990s the region has found some success in attracting business service companies and in particular Information Technology and software companies. For example, in 2000 the region had 116 enquiries from software companies compared to 97 from engineering companies and 81 connected to the automotive industry. Overall, the flow of FDI into the region can be seen in the fact that in 2000 the West Midlands attracted a total of 103 overseas investments with a recorded capital expenditure totalling in excess of L2.2 billion, creating 4,772 jobs and safeguarding a further 20,650.

If the stock rather than the flow of FDI into the region in 2000 is considered, the region contained six of the top ten software companies together with 18 of the top 20 global automotive suppliers, 25 of the top 30 global automotive plastics suppliers and a host of global telecommunications companies (Advantage, 2000). In fact the region has the strongest regional financial services sector outside London. In total by 2000 more than 223,000 people were employed through FDI within 1,925 companies (over a third of which have moved into the region since 1991) from a range of host economies including the USA, Germany, Japan, France, Taiwan, the Netherlands, Switzerland and Sweden. These companies include BMW, Denso, Ford, Fujitsu, Magneti Marelli, NEC, Oracle, Peugeot, GAP and OSI Pharmaceuticals.

What leads the region to be so attractive to FDI? Advantage West Midlands (2000) suggest the following. "The region boasts a skilled and dedicated workforce of more than 2.4 million people, who have consistently demonstrated their versatility, flexibility and competitive instinct over many years. They are ready to be flexible in working practices and committed to meeting targets". In addition the workforce is seen as highly skilled with the region generating 34,000 new high quality graduates from its nine universities each year. These together with its 60 higher and further education colleges provide a ready supply of welleducated graduates particularly in the area of Information Technology. The region is also seen as a relatively low cost of living area and its location at the very centre of the UK's transport infrastructure is also considered to be of major importance. "High quality and highly reliable road, rail and sea connections are all part of the region's well-developed and extensive transport infrastructure, all supported by an advanced telecommunications network' (Advantage West Midlands, 2000). Seventy five per cent of the UK's population is within a half-day truck drive of the West Midlands and this has resulted in more than 300 major distribution companies establishing themselves within the region.

MORE RECENT EMPIRICAL WORK

On one level therefore, the support agencies in both Scotland and the West Midlands appear to suggest similar factors as the major determinants of FDI into their regions. However, a study undertaken by Fallon et al (2001), based upon data collected at both regional and national level suggest that differences do exist between the attraction factors for the two regions.

For example, in the West Midlands the most important FDI-inducing factor in this study appears to be regional preferential assistance levels followed by education and market size. In Scotland, the results suggest that levels of unemployment may be most important, followed by market size, regional assistance and average wage costs. Taken together, they suggest that it may prove difficult to explain the regional distribution of inbound FDI in the UK using a common set of independent variables.

Not only is it important to establish the factors that may affect the flow of FDI into a region but it is also important to establish the direction of any relationship that exists between an explanatory variable and FDI. The results from Fallon et al (2001) suggest that in the West Midlands, education and preferential regional assistance both have a positive effect on FDI as might be expected. This suggests that increased levels of human capital and government assistance to industry tend to attract increasing levels of inbound FDI. The coefficient of market size, unexpectedly, has a negative sign, suggesting that reductions in the region's market size have been associated with increased FDI over time. This apparently perverse result can however be explained by the region's particular experience since the early 1980s. Net emigration, brought about by deindustrialisation and reduced employment opportunities for a highly skilled and mobile workforce, has coincided with an increasing governmental push for inward investment, linked to the availability of financial incentives for foreign investors.

In the case of Scotland, unemployment and market size are positively related to FDI, as expected, suggesting that increases in market size and unemployment levels help to attract inflows of market - and resources-seeking FDI respectively. The remaining results generated from Scottish data run contrary to a priori expectations however. It might be expected that rising average wage costs would act as a deterrent to inbound FDI, but the results suggest that this variable has a positive influence on FDI in Scotland. This apparent contradiction may perhaps be explained by reference to the ambiguous effects of labour costs. On the one hand high labour costs might lead to a reduction in resource-seeking FDI as they raise the total costs of the investing firm. On the other hand, they will help to create higher real incomes and purchasing power at the regional level, so providing a possible stimulus to market-seeking FDI. In addition, in the case of Scotland, increasing levels of regional preferential assistance are associated with lower inflows of FDI into the region. This result may be explained, at least in part, by the heterogeneity of the Scottish economy, where the impact of government regional assistance on some of the peripheral areas is not sufficient to overcome their inherent difficulties in attracting inward FDI, such as their remoteness from markets, relatively poor infrastructure and lack of agglomeration economies. These circumstances would appear to argue strongly for the adoption of a more focussed approach to RPA in the case of Scotland.

CONCLUSIONS

The findings reported in this paper provide tentative support for the hypotheses that the attraction of inbound FDI into the West Midlands and Scotland is related to the search for markets, resources and efficiency. Both Advantage West Midlands and Locate in Scotland suggest a series of common factors as to why their regions are attractive to FDI. On the supply side these include a highly skilled, welleducated and flexible workforce, and efficiency related factors including agglomeration economies. On the demand side market related factors such as the availability of a pool of affordable labour appear to be important, as do the size of the local market and transport and telecommunications infrastructure.

The results from our study suggest that different factors may be attracting inbound FDI into the West Midlands and Scotland from the TNC decision-makers point of view. For the West Midlands, government regional assistance and levels of education are significant positive determinants of FDI, while the size of the regional population has a negative effect on FDI inflows. For Scotland, unemployment, average regional wage earnings, and the size of the regional population all have positive impacts on FDI, while government regional assistance is negatively related to FDI.

These findings also help to explain the difference between the types of FDI which each region predominantly attracts: engineering, automotive and software activities, in the case of the West Midlands, and electronics and services activities, in that of Scotland.

This contrasting pattern can be explained at least in part by the findings reported above. Both regions exhibit path dependency in terms of the type of FDI that they attract, showing an apparent continuing tendency to attract FDI into sectors such as engineering and electronics that are already significantly represented in the West Midlands and Scotland. However, the aggregate data collected over time hides the fact that there are changes taking place in the structure of both regional economies influencing the focus of FDI.

In the West Midlands there has been a growing trend towards, business service companies and in particular IT and software organisations. In the case of Scotland the services sector has also come to the fore in recent years as a prime target for inbound FDI. The use of aggregate FDI figures alone for each region makes it impossible to pick-up these more recent changes in the focus of FDI.

There is therefore, some difference between the factors that are suggested as being the drivers behind FDI into the West Midlands and Scotland by the official inward investment agencies and those which appear to be important from the findings discussed in this paper.

REFERENCES

Advantage West Midlands, 2000, Investing in the Heart of England

Arpan, J. and Ricks, D.A., Directory of Foreign Manufacturers in the United States (Atlanta: School of Business Administration, Georgia State University, 1995).

Bagchi-Sen, S. and Wheeler, J.D., 'A Spatial and Temporal Model of Foreign Investment in the US,' Economic Geography, 65.2 (1989), ppl 13-129.

Billington, N, 'The location of Foreign Direct Investment: An Empirical Analysis,' Applied Economics, 31.1 (1999)

Collis, C.G. and Noon, D, 'Foreign Direct Investment in the UK Regions: Recent Trends and Policy Issues,' Regional Studies, 28.8 (1994), pp 843848.

Collis, C.G., Noon, D, Roberts, P. and Gray, K, Overseas Investment in the West Midlands Region, West Midlands Industrial Development association, Centre for Local Economic Development, 1989

Dunning, J.H. Multinational Enterprises and the Global Economy, (Wokingham, United Kingdom and Reading, Mass.: Addison Wesley, 1993)

Fallon, G. Cook, M. and Billimoria, A, 'Explaining the Regional Distribution of Inbound Foreign Direct Investment in the United Kingdom: Preliminary Evidence from the West Midlands and Scotland and Policy Implications for the UK Government, Conference paper UK Academy of International Business, Manchester Metropolitan University, April (2001)

Glickman, N.J. and Woodward, D.R, 'The Location of Foreign Direct Investment in the United States: Patterns and Determinants,' International Regional Science Review, 11.2 (1988), pp137-154.

Hill, S and Munday, M, 'The Determinants of Inward Investment: A Welsh analysis,' Applied Economics, 23.1 (1991), pp761-769.

Hill, S and Munday, M, 'The UK Regional Distribution of Foreign Direct Investment: Analysis and Determinants,' Regional Studies, 26.6 (1992), pp53568.

Invest UK (2001), Investing in the UKUK Regional Information.

http:// www.invest.uk.com/investing/uk_region al

Little, J.S., 'Locational Decisions of Foreign Direct Investors in the US,' New England Economic Review, July/August (1978), pp 43-63.

Locate in Scotland (1991-2000), Annual Reviews.

Mandell, SL and Killian, C.D., An Analysis of Foreign Investment in Selected Areas of the United States, A Research paper on Behalf of the New England Regional Commission (Boston, MA: The International Center of New England, Inc., 1974)

McConnell, J.E., 'Foreign Direct Investment in the US,' Annals of the Institute of American Geography, 70 (1980), pp259-270.

Meyer, S. and Qu, T, 'Place-specific determinants of FDI: The geographical perspective', in

Green, M.B. and Norton, R.D., The Location of Foreign Direct Investment: Geographic and Business Approaches (Aldershot: Avebury, 1995).

Roberts R, Noon, D. and Irving P, Overseas Investment in the West Midlands Region, West Midlands Industrial Development association, Centre for Local Economic Development, 1988.

Stopford, J. and Strange, S., Rival States, Rival Firms: Competition for World Market Shares (Cambridge: Cambridge University Press, 1991).

Taylor, J, 'An Analysis of the Factors Determining the Geographical Distribution of Japanese Manufacturing Investment in the UK, 1984-91, Urban Studies, 30.1 (1993), pp 209-224.

Grahame Fallon, Mark Cook, Anti Bilimoria University College Northampton.

The importance of understanding organizational culture

As an employee in any type of organization can attest, organizational culture is as prevalent and as varied as individuals themselves. Organizational culture is enduring and complex, and may have both a positive and a negative effect on the staff and the workplace. In many ways culture will determine the survival of an organization over the long term, especially in volatile industries.

Cultures that can be a liability to an organization include those that create barriers to change, create barriers to diversity or barriers to mergers and acquisitions. (Stephen P. Robbins. Organizational Behavior, 8th ed., 602-603.)

Understanding the organizational culture can help you to understand why change does not take place, or why a project fails. It will also help you to determine where to strive to make changes to the culture.

As managers and library leaders, why do we need to get a sense of the prevailing organizational culture? It is essential to understand the organizational culture if you want to make changes to how work is done, what type of work is being done, or at the broadest level, to affect the organization's standing in its industry. Understanding the culture and, as required, changing it, can mean the difference between attracting and retaining good employees and driving away the best employees with an environment that doesn't encourage, challenge, or reward them.

The organizational culture assessment that I participated in didn't provide any surprises regarding the existing culture--most people with any level of sensitivity can get a sense of what type of culture is prevalent in an organization. What was surprising were the results from the survey to determine what type of culture staff would prefer to see the organization develop.

As background, the organization had just gone through a major change. The executive director had departed after 20 years; there had been a period of several months with an acting ED followed by a new, external ED appointment. The assessment took place only a month after the new ED was in position.

Types of Culture

The assessment we used to assess the organization's culture used questions that sought to determine and enumerate such organizational traits as symbols (such as images, things, events), organizational-espoused values and beliefs (for example, the mission statement, constitution, espoused goals of the ED, slogans). Then the espoused beliefs and values were compared with the symbols and culture identified through the written survey and staff interviews.

The written survey asked staff to answer questions related to the current culture and then asked how they would like to see the culture change. Responses were tabulated to determine which type of culture existed among the four metrics of organizational culture: hierarchy, adhocracy, clan, and market.

The hierarchy aspect of an organization refers to how structured, inflexible, and process-driven an organization is in the way it operates. At the opposite end of the scale, adhocracy refers to how flexible, informal, innovative, and dynamic an organization is. A clan culture supports a very friendly and social environment in which to work, while a market culture is often found in organizations that are results-oriented and sales-driven.

Investing in the IT That Makes a Competitive Difference

The Idea in Brief-

It's not just you. It really is getting harder to outpace the other guys. Since the mid-1990s, competition in the U.S. economy has accelerated to unprecedented levels. The engine behind this hypercompetition: IT. Thanks to powerful tools like ERP and CRM, backed by cheap networks, companies are swiftly replicating business-process innovations throughout their organizations. The firm with the best processes (order fulfillment, field installation, job closing) wins, but not for long. Rivals are striking back with their own IT-based process innovations.

To gain--and keep--a competitive edge in this environment, McAfee and Brynjolfsson recommend a three-step strategy:

Deploy a consistent technology platform, rather than stitching together a jumble of legacy systems.

Innovate better ways of working.

Propagate those process innovations widely throughout your company.

By taking these steps, elevator-systems maker Otis realized not only dramatically shorter sales-cycle times but higher revenues and operating profit.

The Idea in Practice-

The authors recommend these steps for staying ahead of rivals through IT-enabled process innovation:

Deploy. Adopt a uniform technology platform to be used throughout your company.

Before deploying a consistent platform, Cisco's various units had nine different tools for checking an order's status. Each pulled information from different repositories and defined key terms differently, leading to circulation of conflicting order-status reports around the company. The company reconfigured its IT systems for consistent execution of key business processes including market to sell, lead to order, quote to cash, issue to resolution, forecast to build, idea to product, and hire to retire. The payoff? Strong performance over the past few years.

Innovate. Design better ways of doing work in your company. The best candidates for innovation are processes that:

• Apply across a large swatch of your company (such as all your stores, factories, or delivery teams)
• Produce results as soon as your new IT system goes live
• Require precise instructions (such as order taking or delivery)
• Can be executed the same way everywhere and every time in your organization
• Can be tracked in real time so you can immediately spot and address any backsliding to older versions of the process

U.K. grocery chain Tesco has long used customer-rewards cards to collect detailed data on individual purchases, to categorize customers, and to tailor offers. But it went one step further: tracking redemption rates for direct-marketing initiatives and tweaking its processes to get better responses from customers. Its process innovation drove its redemption rate to 20%--far above the industry's average of 2%.

Propagate. Use IT to replicate process innovations throughout your company.

At CVS pharmacies, customer satisfaction was declining. The reason: Prescription orders were delayed during the insurance check, which was performed after customers had left the store. So customers weren't immediately available to answer common questions such as "Have you changed jobs?" The company decided to move the insurance check forward in the prescription-fulfillment process, before the drug-safety review, so customers would still be around to answer questions.

The process change was embedded in the information systems that supported operations at all 4,000 CVS pharmacies in the United States. Performance improved across all the pharmacies, and customer satisfaction scores rose from 86% to 91%--a dramatic difference in the aggressive pharmacy market.

• Purchase the full-length Harvard Business Review article here.
• Visit Harvard Business Online.
• See more on Leadership and Managing People at Harvard Business Online.

Copyright 2008 Harvard Business School Publishing Corporation. All rights reserved.

Further Reading-

Articles

Radically Simple IT

Harvard Business Review

by David Upton and Bradley R. Staats

The authors focus on the "Deploy" principle for driving IT-enabled process innovations. Their advice? Build a low-cost, efficient IT system that runs your existing business and supports new growth fueled by process innovations. Develop your system over time, using these principles: 1) Forge your business and IT strategies together--so your IT platform supports your strategic objectives. 2) Strive for simplicity--so you can reuse elements of your system and save money. 3) Invite users' input--so they'll quickly embrace the new system. Using these principles, Japan's Shinsei Bank created an enterprise system that supported its strategy of providing new retail services. Its customer base jumped from 50,000 in 2001 to 2+ million in 2007.

The Next Revolution in Productivity

Harvard Business Review

June 2008

by Ric Merrifield, Jack Calhoun, and Dennis Stevens

This article sheds further light on the "Propagate" principle. The authors recommend using service-oriented architecture (SOA)--a way of designing business-process technology built on Web-based services. SOA makes it vastly easier to share processes with other units. To take advantage of SOA, identify processes that give you a strategic edge. Then automate these processes through Web-based services anyone (different business units, customers, suppliers) can access. Airlines did this by enabling passengers to check in for flights on their home computers, at airport kiosks, or through customer-service representatives.

Collection-

Wringing Real Value from IT, 2nd Edition

HBR Article Collection

October 2008

by Nicholas G. Carr, Michael E. Porter, and Diana Farrell

This collection provides additional insights for maximizing the value of your IT investments. In "IT Doesn't Matter," Nicholas Carr recommends ways to save money on your investments. For example, explore cheaper alternatives, such as open-source systems and barebones PCs. In "Strategy and the Internet," Michael Porter advises using IT to integrate your virtual and physical business processes. For instance, employ your Web site to attract customers and draw them to flesh-and-blood salespeople, who provide personalized advice and after-sales service. In "The Real New Economy," Diana Farrell suggests figuring out what drives productivity most in your company (labor efficiency? asset utilization? cost reduction?), and sequencing your IT investments so they build on each other.

About the Authors-

Andrew McAfee is an associate professor at Harvard Business School in Boston. He is the author of "Mastering the Three Worlds of Information Technology" (HBR November 2006) and has a blog at andrewmcafee.org/blog.

Erik Brynjolfsson is the Schussel Family Professor at the MIT Sloan School of Management and the director of MIT's Center for Digital Business in Cambridge, Massachusetts. More of the author's research is available at digital.mit.edu/erik.

Being Popular

A friend of mine once told an eminent operating systems expert that he wanted to design a really good programming language. The expert told him that it would be a waste of time, that programming languages don't become popular or unpopular based on their merits, and so no matter how good his language was, no one would use it. At least, that was what had happened to the language he had designed.

What does make a language popular? Do popular languages deserve their popularity? Is it worth trying to define a good programming language? How would you do it?

I think the answers to these questions can be found by looking at hackers, and learning what they want. Programming languages are for hackers, and a programming language is good as a programming language (rather than, say, an exercise in denotational semantics or compiler design) if and only if hackers like it.

1 The Mechanics of Popularity

It's true, certainly, that most people don't choose programming languages simply based on their merits. Most programmers are told what language to use by someone else. And yet I think the effect of such external factors on the popularity of programming languages is not as great as it's sometimes thought to be. I think a bigger problem is that a hacker's idea of a good programming language is not the same as most language designers'.

Between the two, the hacker's opinion is the one that matters. Programming languages are not theorems. They're tools, designed for people, and they have to be designed to suit human strengths and weaknesses as much as shoes have to be designed for human feet. If a shoe pinches when you put it on, it's a bad shoe, however elegant it may be as a piece of sculpture.

It may be that the majority of programmers can't tell a good language from a bad one. But that's no different with any other tool. It doesn't mean that it's a waste of time to try designing a good language. Expert hackers can tell a good language when they see one, and they'll use it. Expert hackers are a tiny minority, admittedly, but that tiny minority write all the good software, and their influence is such that the rest of the programmers will tend to use whatever language they use. Often, indeed, it is not merely influence but command: often the expert hackers are the very people who, as their bosses or faculty advisors, tell the other programmers what language to use.

The opinion of expert hackers is not the only force that determines the relative popularity of programming languages-- legacy software (Cobol) and hype (Ada, Java) also play a role-- but I think it is the most powerful force over the long term. Given an initial critical mass and enough time, a programming language probably becomes about as popular as it deserves to be. And popularity further separates good languages from bad ones, because feedback from real live users always leads to improvements. Look at how much any popular language has changed during its life. Perl and Fortran are extreme cases, but even Lisp has changed a lot. Lisp 1.5 didn't have macros, for example; these evolved later, after hackers at MIT had spent a couple years using Lisp to write real programs. [1]

So whether or not a language has to be good to be popular, I think a language has to be popular to be good. And it has to stay popular to stay good. The state of the art in programming languages doesn't stand still. And yet the Lisps we have today are still pretty much what they had at MIT in the mid-1980s, because that's the last time Lisp had a sufficiently large and demanding user base.

Of course, hackers have to know about a language before they can use it. How are they to hear? From other hackers. But there has to be some initial group of hackers using the language for others even to hear about it. I wonder how large this group has to be; how many users make a critical mass? Off the top of my head, I'd say twenty. If a language had twenty separate users, meaning twenty users who decided on their own to use it, I'd consider it to be real.

Getting there can't be easy. I would not be surprised if it is harder to get from zero to twenty than from twenty to a thousand. The best way to get those initial twenty users is probably to use a trojan horse: to give people an application they want, which happens to be written in the new language.

2 External Factors

Let's start by acknowledging one external factor that does affect the popularity of a programming language. To become popular, a programming language has to be the scripting language of a popular system. Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, was Perl. Tcl is the scripting language of Tk. Java and Javascript are intended to be the scripting languages of web browsers.

Lisp is not a massively popular language because it is not the scripting language of a massively popular system. What popularity it retains dates back to the 1960s and 1970s, when it was the scripting language of MIT. A lot of the great programmers of the day were associated with MIT at some point. And in the early 1970s, before C, MIT's dialect of Lisp, called MacLisp, was one of the only programming languages a serious hacker would want to use.

Today Lisp is the scripting language of two moderately popular systems, Emacs and Autocad, and for that reason I suspect that most of the Lisp programming done today is done in Emacs Lisp or AutoLisp.

Programming languages don't exist in isolation. To hack is a transitive verb-- hackers are usually hacking something-- and in practice languages are judged relative to whatever they're used to hack. So if you want to design a popular language, you either have to supply more than a language, or you have to design your language to replace the scripting language of some existing system.

Common Lisp is unpopular partly because it's an orphan. It did originally come with a system to hack: the Lisp Machine. But Lisp Machines (along with parallel computers) were steamrollered by the increasing power of general purpose processors in the 1980s. Common Lisp might have remained popular if it had been a good scripting language for Unix. It is, alas, an atrociously bad one.

One way to describe this situation is to say that a language isn't judged on its own merits. Another view is that a programming language really isn't a programming language unless it's also the scripting language of something. This only seems unfair if it comes as a surprise. I think it's no more unfair than expecting a programming language to have, say, an implementation. It's just part of what a programming language is.

A programming language does need a good implementation, of course, and this must be free. Companies will pay for software, but individual hackers won't, and it's the hackers you need to attract.

A language also needs to have a book about it. The book should be thin, well-written, and full of good examples. K&R is the ideal here. At the moment I'd almost say that a language has to have a book published by O'Reilly. That's becoming the test of mattering to hackers.

There should be online documentation as well. In fact, the book can start as online documentation. But I don't think that physical books are outmoded yet. Their format is convenient, and the de facto censorship imposed by publishers is a useful if imperfect filter. Bookstores are one of the most important places for learning about new languages.

3 Brevity

Given that you can supply the three things any language needs-- a free implementation, a book, and something to hack-- how do you make a language that hackers will like?

One thing hackers like is brevity. Hackers are lazy, in the same way that mathematicians and modernist architects are lazy: they hate anything extraneous. It would not be far from the truth to say that a hacker about to write a program decides what language to use, at least subconsciously, based on the total number of characters he'll have to type. If this isn't precisely how hackers think, a language designer would do well to act as if it were.

It is a mistake to try to baby the user with long-winded expressions that are meant to resemble English. Cobol is notorious for this flaw. A hacker would consider being asked to write

add x to y giving z

instead of

z = x+y

as something between an insult to his intelligence and a sin against God.

It has sometimes been said that Lisp should use first and rest instead of car and cdr, because it would make programs easier to read. Maybe for the first couple hours. But a hacker can learn quickly enough that car means the first element of a list and cdr means the rest. Using first and rest means 50% more typing. And they are also different lengths, meaning that the arguments won't line up when they're called, as car and cdr often are, in successive lines. I've found that it matters a lot how code lines up on the page. I can barely read Lisp code when it is set in a variable-width font, and friends say this is true for other languages too.

Brevity is one place where strongly typed languages lose. All other things being equal, no one wants to begin a program with a bunch of declarations. Anything that can be implicit, should be.

The individual tokens should be short as well. Perl and Common Lisp occupy opposite poles on this question. Perl programs can be almost cryptically dense, while the names of built-in Common Lisp operators are comically long. The designers of Common Lisp probably expected users to have text editors that would type these long names for them. But the cost of a long name is not just the cost of typing it. There is also the cost of reading it, and the cost of the space it takes up on your screen.

4 Hackability

There is one thing more important than brevity to a hacker: being able to do what you want. In the history of programming languages a surprising amount of effort has gone into preventing programmers from doing things considered to be improper. This is a dangerously presumptuous plan. How can the language designer know what the programmer is going to need to do? I think language designers would do better to consider their target user to be a genius who will need to do things they never anticipated, rather than a bumbler who needs to be protected from himself. The bumbler will shoot himself in the foot anyway. You may save him from referring to variables in another package, but you can't save him from writing a badly designed program to solve the wrong problem, and taking forever to do it.

Good programmers often want to do dangerous and unsavory things. By unsavory I mean things that go behind whatever semantic facade the language is trying to present: getting hold of the internal representation of some high-level abstraction, for example. Hackers like to hack, and hacking means getting inside things and second guessing the original designer.

Let yourself be second guessed. When you make any tool, people use it in ways you didn't intend, and this is especially true of a highly articulated tool like a programming language. Many a hacker will want to tweak your semantic model in a way that you never imagined. I say, let them; give the programmer access to as much internal stuff as you can without endangering runtime systems like the garbage collector.

In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.

A hacker may only want to subvert the intended model of things once or twice in a big program. But what a difference it makes to be able to. And it may be more than a question of just solving a problem. There is a kind of pleasure here too. Hackers share the surgeon's secret pleasure in poking about in gross innards, the teenager's secret pleasure in popping zits. [2] For boys, at least, certain kinds of horrors are fascinating. Maxim magazine publishes an annual volume of photographs, containing a mix of pin-ups and grisly accidents. They know their audience.

Historically, Lisp has been good at letting hackers have their way. The political correctness of Common Lisp is an aberration. Early Lisps let you get your hands on everything. A good deal of that spirit is, fortunately, preserved in macros. What a wonderful thing, to be able to make arbitrary transformations on the source code.

Classic macros are a real hacker's tool-- simple, powerful, and dangerous. It's so easy to understand what they do: you call a function on the macro's arguments, and whatever it returns gets inserted in place of the macro call. Hygienic macros embody the opposite principle. They try to protect you from understanding what they're doing. I have never heard hygienic macros explained in one sentence. And they are a classic example of the dangers of deciding what programmers are allowed to want. Hygienic macros are intended to protect me from variable capture, among other things, but variable capture is exactly what I want in some macros.

A really good language should be both clean and dirty: cleanly designed, with a small core of well understood and highly orthogonal operators, but dirty in the sense that it lets hackers have their way with it. C is like this. So were the early Lisps. A real hacker's language will always have a slightly raffish character.

A good programming language should have features that make the kind of people who use the phrase "software engineering" shake their heads disapprovingly. At the other end of the continuum are languages like Ada and Pascal, models of propriety that are good for teaching and not much else.

5 Throwaway Programs

To be attractive to hackers, a language must be good for writing the kinds of programs they want to write. And that means, perhaps surprisingly, that it has to be good for writing throwaway programs.

A throwaway program is a program you write quickly for some limited task: a program to automate some system administration task, or generate test data for a simulation, or convert data from one format to another. The surprising thing about throwaway programs is that, like the "temporary" buildings built at so many American universities during World War II, they often don't get thrown away. Many evolve into real programs, with real features and real users.

I have a hunch that the best big programs begin life this way, rather than being designed big from the start, like the Hoover Dam. It's terrifying to build something big from scratch. When people take on a project that's too big, they become overwhelmed. The project either gets bogged down, or the result is sterile and wooden: a shopping mall rather than a real downtown, Brasilia rather than Rome, Ada rather than C.

Another way to get a big program is to start with a throwaway program and keep improving it. This approach is less daunting, and the design of the program benefits from evolution. I think, if one looked, that this would turn out to be the way most big programs were developed. And those that did evolve this way are probably still written in whatever language they were first written in, because it's rare for a program to be ported, except for political reasons. And so, paradoxically, if you want to make a language that is used for big systems, you have to make it good for writing throwaway programs, because that's where big systems come from.

Perl is a striking example of this idea. It was not only designed for writing throwaway programs, but was pretty much a throwaway program itself. Perl began life as a collection of utilities for generating reports, and only evolved into a programming language as the throwaway programs people wrote in it grew larger. It was not until Perl 5 (if then) that the language was suitable for writing serious programs, and yet it was already massively popular.

What makes a language good for throwaway programs? To start with, it must be readily available. A throwaway program is something that you expect to write in an hour. So the language probably must already be installed on the computer you're using. It can't be something you have to install before you use it. It has to be there. C was there because it came with the operating system. Perl was there because it was originally a tool for system administrators, and yours had already installed it.

Being available means more than being installed, though. An interactive language, with a command-line interface, is more available than one that you have to compile and run separately. A popular programming language should be interactive, and start up fast.

Another thing you want in a throwaway program is brevity. Brevity is always attractive to hackers, and never more so than in a program they expect to turn out in an hour.

6 Libraries

Of course the ultimate in brevity is to have the program already written for you, and merely to call it. And this brings us to what I think will be an increasingly important feature of programming languages: library functions. Perl wins because it has large libraries for manipulating strings. This class of library functions are especially important for throwaway programs, which are often originally written for converting or extracting data. Many Perl programs probably begin as just a couple library calls stuck together.

I think a lot of the advances that happen in programming languages in the next fifty years will have to do with library functions. I think future programming languages will have libraries that are as carefully designed as the core language. Programming language design will not be about whether to make your language strongly or weakly typed, or object oriented, or functional, or whatever, but about how to design great libraries. The kind of language designers who like to think about how to design type systems may shudder at this. It's almost like writing applications! Too bad. Languages are for programmers, and libraries are what programmers need.

It's hard to design good libraries. It's not simply a matter of writing a lot of code. Once the libraries get too big, it can sometimes take longer to find the function you need than to write the code yourself. Libraries need to be designed using a small set of orthogonal operators, just like the core language. It ought to be possible for the programmer to guess what library call will do what he needs.

Libraries are one place Common Lisp falls short. There are only rudimentary libraries for manipulating strings, and almost none for talking to the operating system. For historical reasons, Common Lisp tries to pretend that the OS doesn't exist. And because you can't talk to the OS, you're unlikely to be able to write a serious program using only the built-in operators in Common Lisp. You have to use some implementation-specific hacks as well, and in practice these tend not to give you everything you want. Hackers would think a lot more highly of Lisp if Common Lisp had powerful string libraries and good OS support.

7 Syntax

Could a language with Lisp's syntax, or more precisely, lack of syntax, ever become popular? I don't know the answer to this question. I do think that syntax is not the main reason Lisp isn't currently popular. Common Lisp has worse problems than unfamiliar syntax. I know several programmers who are comfortable with prefix syntax and yet use Perl by default, because it has powerful string libraries and can talk to the os.

There are two possible problems with prefix notation: that it is unfamiliar to programmers, and that it is not dense enough. The conventional wisdom in the Lisp world is that the first problem is the real one. I'm not so sure. Yes, prefix notation makes ordinary programmers panic. But I don't think ordinary programmers' opinions matter. Languages become popular or unpopular based on what expert hackers think of them, and I think expert hackers might be able to deal with prefix notation. Perl syntax can be pretty incomprehensible, but that has not stood in the way of Perl's popularity. If anything it may have helped foster a Perl cult.

A more serious problem is the diffuseness of prefix notation. For expert hackers, that really is a problem. No one wants to write (aref a x y) when they could write a[x,y].

In this particular case there is a way to finesse our way out of the problem. If we treat data structures as if they were functions on indexes, we could write (a x y) instead, which is even shorter than the Perl form. Similar tricks may shorten other types of expressions.

We can get rid of (or make optional) a lot of parentheses by making indentation significant. That's how programmers read code anyway: when indentation says one thing and delimiters say another, we go by the indentation. Treating indentation as significant would eliminate this common source of bugs as well as making programs shorter.

Sometimes infix syntax is easier to read. This is especially true for math expressions. I've used Lisp my whole programming life and I still don't find prefix math expressions natural. And yet it is convenient, especially when you're generating code, to have operators that take any number of arguments. So if we do have infix syntax, it should probably be implemented as some kind of read-macro.

I don't think we should be religiously opposed to introducing syntax into Lisp, as long as it translates in a well-understood way into underlying s-expressions. There is already a good deal of syntax in Lisp. It's not necessarily bad to introduce more, as long as no one is forced to use it. In Common Lisp, some delimiters are reserved for the language, suggesting that at least some of the designers intended to have more syntax in the future.

One of the most egregiously unlispy pieces of syntax in Common Lisp occurs in format strings; format is a language in its own right, and that language is not Lisp. If there were a plan for introducing more syntax into Lisp, format specifiers might be able to be included in it. It would be a good thing if macros could generate format specifiers the way they generate any other kind of code.

An eminent Lisp hacker told me that his copy of CLTL falls open to the section format. Mine too. This probably indicates room for improvement. It may also mean that programs do a lot of I/O.

8 Efficiency

A good language, as everyone knows, should generate fast code. But in practice I don't think fast code comes primarily from things you do in the design of the language. As Knuth pointed out long ago, speed only matters in certain critical bottlenecks. And as many programmers have observed since, one is very often mistaken about where these bottlenecks are.

So, in practice, the way to get fast code is to have a very good profiler, rather than by, say, making the language strongly typed. You don't need to know the type of every argument in every call in the program. You do need to be able to declare the types of arguments in the bottlenecks. And even more, you need to be able to find out where the bottlenecks are.

One complaint people have had with Lisp is that it's hard to tell what's expensive. This might be true. It might also be inevitable, if you want to have a very abstract language. And in any case I think good profiling would go a long way toward fixing the problem: you'd soon learn what was expensive.

Part of the problem here is social. Language designers like to write fast compilers. That's how they measure their skill. They think of the profiler as an add-on, at best. But in practice a good profiler may do more to improve the speed of actual programs written in the language than a compiler that generates fast code. Here, again, language designers are somewhat out of touch with their users. They do a really good job of solving slightly the wrong problem.

It might be a good idea to have an active profiler-- to push performance data to the programmer instead of waiting for him to come asking for it. For example, the editor could display bottlenecks in red when the programmer edits the source code. Another approach would be to somehow represent what's happening in running programs. This would be an especially big win in server-based applications, where you have lots of running programs to look at. An active profiler could show graphically what's happening in memory as a program's running, or even make sounds that tell what's happening.

Sound is a good cue to problems. In one place I worked, we had a big board of dials showing what was happening to our web servers. The hands were moved by little servomotors that made a slight noise when they turned. I couldn't see the board from my desk, but I found that I could tell immediately, by the sound, when there was a problem with a server.

It might even be possible to write a profiler that would automatically detect inefficient algorithms. I would not be surprised if certain patterns of memory access turned out to be sure signs of bad algorithms. If there were a little guy running around inside the computer executing our programs, he would probably have as long and plaintive a tale to tell about his job as a federal government employee. I often have a feeling that I'm sending the processor on a lot of wild goose chases, but I've never had a good way to look at what it's doing.

A number of Lisps now compile into byte code, which is then executed by an interpreter. This is usually done to make the implementation easier to port, but it could be a useful language feature. It might be a good idea to make the byte code an official part of the language, and to allow programmers to use inline byte code in bottlenecks. Then such optimizations would be portable too.

The nature of speed, as perceived by the end-user, may be changing. With the rise of server-based applications, more and more programs may turn out to be i/o-bound. It will be worth making i/o fast. The language can help with straightforward measures like simple, fast, formatted output functions, and also with deep structural changes like caching and persistent objects.

Users are interested in response time. But another kind of efficiency will be increasingly important: the number of simultaneous users you can support per processor. Many of the interesting applications written in the near future will be server-based, and the number of users per server is the critical question for anyone hosting such applications. In the capital cost of a business offering a server-based application, this is the divisor.

For years, efficiency hasn't mattered much in most end-user applications. Developers have been able to assume that each user would have an increasingly powerful processor sitting on their desk. And by Parkinson's Law, software has expanded to use the resources available. That will change with server-based applications. In that world, the hardware and software will be supplied together. For companies that offer server-based applications, it will make a very big difference to the bottom line how many users they can support per server.

In some applications, the processor will be the limiting factor, and execution speed will be the most important thing to optimize. But often memory will be the limit; the number of simultaneous users will be determined by the amount of memory you need for each user's data. The language can help here too. Good support for threads will enable all the users to share a single heap. It may also help to have persistent objects and/or language level support for lazy loading.

9 Time

The last ingredient a popular language needs is time. No one wants to write programs in a language that might go away, as so many programming languages do. So most hackers will tend to wait until a language has been around for a couple years before even considering using it.

Inventors of wonderful new things are often surprised to discover this, but you need time to get any message through to people. A friend of mine rarely does anything the first time someone asks him. He knows that people sometimes ask for things that they turn out not to want. To avoid wasting his time, he waits till the third or fourth time he's asked to do something; by then, whoever's asking him may be fairly annoyed, but at least they probably really do want whatever they're asking for.

Most people have learned to do a similar sort of filtering on new things they hear about. They don't even start paying attention until they've heard about something ten times. They're perfectly justified: the majority of hot new whatevers do turn out to be a waste of time, and eventually go away. By delaying learning VRML, I avoided having to learn it at all.

So anyone who invents something new has to expect to keep repeating their message for years before people will start to get it. We wrote what was, as far as I know, the first web-server based application, and it took us years to get it through to people that it didn't have to be downloaded. It wasn't that they were stupid. They just had us tuned out.

The good news is, simple repetition solves the problem. All you have to do is keep telling your story, and eventually people will start to hear. It's not when people notice you're there that they pay attention; it's when they notice you're still there.

It's just as well that it usually takes a while to gain momentum. Most technologies evolve a good deal even after they're first launched-- programming languages especially. Nothing could be better, for a new techology, than a few years of being used only by a small number of early adopters. Early adopters are sophisticated and demanding, and quickly flush out whatever flaws remain in your technology. When you only have a few users you can be in close contact with all of them. And early adopters are forgiving when you improve your system, even if this causes some breakage.

There are two ways new technology gets introduced: the organic growth method, and the big bang method. The organic growth method is exemplified by the classic seat-of-the-pants underfunded garage startup. A couple guys, working in obscurity, develop some new technology. They launch it with no marketing and initially have only a few (fanatically devoted) users. They continue to improve the technology, and meanwhile their user base grows by word of mouth. Before they know it, they're big.

The other approach, the big bang method, is exemplified by the VC-backed, heavily marketed startup. They rush to develop a product, launch it with great publicity, and immediately (they hope) have a large user base.

Generally, the garage guys envy the big bang guys. The big bang guys are smooth and confident and respected by the VCs. They can afford the best of everything, and the PR campaign surrounding the launch has the side effect of making them celebrities. The organic growth guys, sitting in their garage, feel poor and unloved. And yet I think they are often mistaken to feel sorry for themselves. Organic growth seems to yield better technology and richer founders than the big bang method. If you look at the dominant technologies today, you'll find that most of them grew organically.

This pattern doesn't only apply to companies. You see it in sponsored research too. Multics and Common Lisp were big-bang projects, and Unix and MacLisp were organic growth projects.

10 Redesign

"The best writing is rewriting," wrote E. B. White. Every good writer knows this, and it's true for software too. The most important part of design is redesign. Programming languages, especially, don't get redesigned enough.

To write good software you must simultaneously keep two opposing ideas in your head. You need the young hacker's naive faith in his abilities, and at the same time the veteran's skepticism. You have to be able to think how hard can it be? with one half of your brain while thinking it will never work with the other.

The trick is to realize that there's no real contradiction here. You want to be optimistic and skeptical about two different things. You have to be optimistic about the possibility of solving the problem, but skeptical about the value of whatever solution you've got so far.

People who do good work often think that whatever they're working on is no good. Others see what they've done and are full of wonder, but the creator is full of worry. This pattern is no coincidence: it is the worry that made the work good.

If you can keep hope and worry balanced, they will drive a project forward the same way your two legs drive a bicycle forward. In the first phase of the two-cycle innovation engine, you work furiously on some problem, inspired by your confidence that you'll be able to solve it. In the second phase, you look at what you've done in the cold light of morning, and see all its flaws very clearly. But as long as your critical spirit doesn't outweigh your hope, you'll be able to look at your admittedly incomplete system, and think, how hard can it be to get the rest of the way?, thereby continuing the cycle.

It's tricky to keep the two forces balanced. In young hackers, optimism predominates. They produce something, are convinced it's great, and never improve it. In old hackers, skepticism predominates, and they won't even dare to take on ambitious projects.

Anything you can do to keep the redesign cycle going is good. Prose can be rewritten over and over until you're happy with it. But software, as a rule, doesn't get redesigned enough. Prose has readers, but software has users. If a writer rewrites an essay, people who read the old version are unlikely to complain that their thoughts have been broken by some newly introduced incompatibility.

Users are a double-edged sword. They can help you improve your language, but they can also deter you from improving it. So choose your users carefully, and be slow to grow their number. Having users is like optimization: the wise course is to delay it. Also, as a general rule, you can at any given time get away with changing more than you think. Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it.

Everyone knows that it's not a good idea to have a language designed by a committee. Committees yield bad design. But I think the worst danger of committees is that they interfere with redesign. It is so much work to introduce changes that no one wants to bother. Whatever a committee decides tends to stay that way, even if most of the members don't like it.

Even a committee of two gets in the way of redesign. This happens particularly in the interfaces between pieces of software written by two different people. To change the interface both have to agree to change it at once. And so interfaces tend not to change at all, which is a problem because they tend to be one of the most ad hoc parts of any system.

One solution here might be to design systems so that interfaces are horizontal instead of vertical-- so that modules are always vertically stacked strata of abstraction. Then the interface will tend to be owned by one of them. The lower of two levels will either be a language in which the upper is written, in which case the lower level will own the interface, or it will be a slave, in which case the interface can be dictated by the upper level.

11 Lisp

What all this implies is that there is hope for a new Lisp. There is hope for any language that gives hackers what they want, including Lisp. I think we may have made a mistake in thinking that hackers are turned off by Lisp's strangeness. This comforting illusion may have prevented us from seeing the real problem with Lisp, or at least Common Lisp, which is that it sucks for doing what hackers want to do. A hacker's language needs powerful libraries and something to hack. Common Lisp has neither. A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp. If we can develop a new Lisp that is a real hacker's language, I think hackers will use it. They will use whatever language does the job. All we have to do is make sure this new Lisp does some important job better than other languages.

History offers some encouragement. Over time, successive new programming languages have taken more and more features from Lisp. There is no longer much left to copy before the language you've made is Lisp. The latest hot language, Python, is a watered-down Lisp with infix syntax and no macros. A new Lisp would be a natural step in this progression.

I sometimes think that it would be a good marketing trick to call it an improved version of Python. That sounds hipper than Lisp. To many people, Lisp is a slow AI language with a lot of parentheses. Fritz Kunze's official biography carefully avoids mentioning the L-word. But my guess is that we shouldn't be afraid to call the new Lisp Lisp. Lisp still has a lot of latent respect among the very best hackers-- the ones who took 6.001 and understood it, for example. And those are the users you need to win.

In "How to Become a Hacker," Eric Raymond describes Lisp as something like Latin or Greek-- a language you should learn as an intellectual exercise, even though you won't actually use it:

Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.

If I didn't know Lisp, reading this would set me asking questions. A language that would make me a better programmer, if it means anything at all, means a language that would be better for programming. And that is in fact the implication of what Eric is saying.

As long as that idea is still floating around, I think hackers will be receptive enough to a new Lisp, even if it is called Lisp. But this Lisp must be a hacker's language, like the classic Lisps of the 1970s. It must be terse, simple, and hackable. And it must have powerful libraries for doing what hackers want to do now.

In the matter of libraries I think there is room to beat languages like Perl and Python at their own game. A lot of the new applications that will need to be written in the coming years will be server-based applications. There's no reason a new Lisp shouldn't have string libraries as good as Perl, and if this new Lisp also had powerful libraries for server-based applications, it could be very popular. Real hackers won't turn up their noses at a new tool that will let them solve hard problems with a few library calls. Remember, hackers are lazy.

It could be an even bigger win to have core language support for server-based applications. For example, explicit support for programs with multiple users, or data ownership at the level of type tags.

Server-based applications also give us the answer to the question of what this new Lisp will be used to hack. It would not hurt to make Lisp better as a scripting language for Unix. (It would be hard to make it worse.) But I think there are areas where existing languages would be easier to beat. I think it might be better to follow the model of Tcl, and supply the Lisp together with a complete system for supporting server-based applications. Lisp is a natural fit for server-based applications. Lexical closures provide a way to get the effect of subroutines when the ui is just a series of web pages. S-expressions map nicely onto html, and macros are good at generating it. There need to be better tools for writing server-based applications, and there needs to be a new Lisp, and the two would work very well together.

12 The Dream Language

By way of summary, let's try describing the hacker's dream language. The dream language is beautiful, clean, and terse. It has an interactive toplevel that starts up fast. You can write programs to solve common problems with very little code. Nearly all the code in any program you write is code that's specific to your application. Everything else has been done for you.

The syntax of the language is brief to a fault. You never have to type an unnecessary character, or even to use the shift key much.

Using big abstractions you can write the first version of a program very quickly. Later, when you want to optimize, there's a really good profiler that tells you where to focus your attention. You can make inner loops blindingly fast, even writing inline byte code if you need to.

There are lots of good examples to learn from, and the language is intuitive enough that you can learn how to use it from examples in a couple minutes. You don't need to look in the manual much. The manual is thin, and has few warnings and qualifications.

The language has a small core, and powerful, highly orthogonal libraries that are as carefully designed as the core language. The libraries all work well together; everything in the language fits together like the parts in a fine camera. Nothing is deprecated, or retained for compatibility. The source code of all the libraries is readily available. It's easy to talk to the operating system and to applications written in other languages.

The language is built in layers. The higher-level abstractions are built in a very transparent way out of lower-level abstractions, which you can get hold of if you want.

Nothing is hidden from you that doesn't absolutely have to be. The language offers abstractions only as a way of saving you work, rather than as a way of telling you what to do. In fact, the language encourages you to be an equal participant in its design. You can change everything about it, including even its syntax, and anything you write has, as much as possible, the same status as what comes predefined.



Notes

[1] Macros very close to the modern idea were proposed by Timothy Hart in 1964, two years after Lisp 1.5 was released. What was missing, initially, were ways to avoid variable capture and multiple evaluation; Hart's examples are subject to both.

[2] In When the Air Hits Your Brain, neurosurgeon Frank Vertosick recounts a conversation in which his chief resident, Gary, talks about the difference between surgeons and internists ("fleas"):

Gary and I ordered a large pizza and found an open booth. The chief lit a cigarette. "Look at those goddamn fleas, jabbering about some disease they'll see once in their lifetimes. That's the trouble with fleas, they only like the bizarre stuff. They hate their bread and butter cases. That's the difference between us and the fucking fleas. See, we love big juicy lumbar disc herniations, but they hate hypertension...."

It's hard to think of a lumbar disc herniation as juicy (except literally). And yet I think I know what they mean. I've often had a juicy bug to track down. Someone who's not a programmer would find it hard to imagine that there could be pleasure in a bug. Surely it's better if everything just works. In one way, it is. And yet there is undeniably a grim satisfaction in hunting down certain sorts of bugs.

Six Principles for Making New Things

The fiery reaction to the release of Arc had an unexpected consequence: it made me realize I had a design philosophy. The main complaint of the more articulate critics was that Arc seemed so flimsy. After years of working on it, all I had to show for myself were a few thousand lines of macros? Why hadn't I worked on more substantial problems?

As I was mulling over these remarks it struck me how familiar they seemed. This was exactly the kind of thing people said at first about Viaweb, and Y Combinator, and most of my essays.

When we launched Viaweb, it seemed laughable to VCs and e-commerce "experts." We were just a couple guys in an apartment, which did not seem cool in 1995 the way it does now. And the thing we'd built, as far as they could tell, wasn't even software. Software, to them, equalled big, honking Windows apps. Since Viaweb was the first web-based app they'd seen, it seemed to be nothing more than a website. They were even more contemptuous when they discovered that Viaweb didn't process credit card transactions (we didn't for the whole first year). Transaction processing seemed to them what e-commerce was all about. It sounded serious and difficult.

And yet, mysteriously, Viaweb ended up crushing all its competitors.

The initial reaction to Y Combinator was almost identical. It seemed laughably lightweight. Startup funding meant series A rounds: millions of dollars given to a small number of startups founded by people with established credentials after months of serious, businesslike meetings, on terms described in a document a foot thick. Y Combinator seemed inconsequential. It's too early to say yet whether Y Combinator will turn out like Viaweb, but judging from the number of imitations, a lot of people seem to think we're on to something.

I can't measure whether my essays are successful, except in page views, but the reaction to them is at least different from when I started. At first the default reaction of the Slashdot trolls was (translated into articulate terms): "Who is this guy and what authority does he have to write about these topics? I haven't read the essay, but there's no way anything so short and written in such an informal style could have anything useful to say about such and such topic, when people with degrees in the subject have already written many thick books about it." Now there's a new generation of trolls on a new generation of sites, but they have at least started to omit the initial "Who is this guy?"

Now people are saying the same things about Arc that they said at first about Viaweb and Y Combinator and most of my essays. Why the pattern? The answer, I realized, is that my m.o. for all four has been the same.

Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

When I first laid out these principles explicitly, I noticed something striking: this is practically a recipe for generating a contemptuous initial reaction. Though simple solutions are better, they don't seem as impressive as complex ones. Overlooked problems are by definition problems that most people think don't matter. Delivering solutions in an informal way means that instead of judging something by the way it's presented, people have to actually understand it, which is more work. And starting with a crude version 1 means your initial effort is always small and incomplete.

I'd noticed, of course, that people never seemed to grasp new ideas at first. I thought it was just because most people were stupid. Now I see there's more to it than that. Like a contrarian investment fund, someone following this strategy will almost always be doing things that seem wrong to the average person.

As with contrarian investment strategies, that's exactly the point. This technique is successful (in the long term) because it gives you all the advantages other people forgo by trying to seem legit. If you work on overlooked problems, you're more likely to discover new things, because you have less competition. If you deliver solutions informally, you (a) save all the effort you would have had to expend to make them look impressive, and (b) avoid the danger of fooling yourself as well as your audience. And if you release a crude version 1 then iterate, your solution can benefit from the imagination of nature, which, as Feynman pointed out, is more powerful than your own.

In the case of Viaweb, the simple solution was to make the software run on the server. The overlooked problem was to generate web sites automatically; in 1995, online stores were all made by hand by human designers, but we knew this wouldn't scale. The part that actually mattered was graphic design, not transaction processing. The informal delivery mechanism was me, showing up in jeans and a t-shirt at some retailer's office. And the crude version 1 was, if I remember correctly, less than 10,000 lines of code when we launched.

The power of this technique extends beyond startups and programming languages and essays. It probably extends to any kind of creative work. Certainly it can be used in painting: this is exactly what Cezanne and Klee did.

At Y Combinator we bet money on it, in the sense that we encourage the startups we fund to work this way. There are always new ideas right under your nose. So look for simple things that other people have overlooked—things people will later claim were "obvious"—especially when they've been led astray by obsolete conventions, or by trying to do things that are superficially impressive. Figure out what the real problem is, and make sure you solve that. Don't worry about trying to look corporate; the product is what wins in the long term. And launch as soon as you can, so you start learning from users what you should have been making.

Reddit is a classic example of this approach. When Reddit first launched, it seemed like there was nothing to it. To the graphically unsophisticated its deliberately minimal design seemed like no design at all. But Reddit solved the real problem, which was to tell people what was new and otherwise stay out of the way. As a result it became massively successful. Now that conventional ideas have caught up with it, it seems obvious. People look at Reddit and think the founders were lucky. Like all such things, it was harder than it looked. The Reddits pushed so hard against the current that they reversed it; now it looks like they're merely floating downstream.

So when you look at something like Reddit and think "I wish I could think of an idea like that," remember: ideas like that are all around you. But you ignore them because they look wrong.

Research and Markets : Tesco Plc - SWOT Framework Analysis

DUBLIN, Ireland -- Research and Markets (http://www.researchandmarkets.com/reports/c67242) has announced the addition of "Tesco Plc - SWOT Framework Analysis" to their offering.

SWOT Analysis is a strategic planning tool used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture. It involves specifying the objective of the business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving that objective.

The aim of any SWOT analysis is to identify the key internal and external factors that are important to achieving the objective. SWOT analysis groups key pieces of information into two main categories:-

nternal factors - The strengths and weaknesses internal to the organization.

External factors - The opportunities and threats presented by the external environment.

The internal factors may be viewed as strengths or weaknesses depending upon their impact on the organizations objectives. What may represent strengths with respect to one objective may be weaknesses for another objective. The factors may include all of the 4Ps; as well as personnel, finance, manufacturing capabilities, and so on. The external factors may include macroeconomic matters, technological change, legislation, and socio-cultural changes, as well as changes in the marketplace or competitive position. The results are often presented in the form of a matrix.

SWOT analysis is just one method of categorization and has its own weaknesses. For example, it may tend to persuade companies to compile lists rather than think about what is really important in achieving objectives. It also presents the resulting lists uncritically and without clear prioritization so that, for example, weak opportunities may appear to balance strong threats.

Content Outline:

A. Executive Summary

B. A Brief Profile of the Company

C. SWOT Framework Analysis

C.1 Strengths to Build Upon

C.2 Weaknesses to Overcome

C.3 Opportunities to Exploit

C.4 Threats to Overcome

D. Glossary of Terms

For more information visit http://www.researchandmarkets.com/reports/c67242

Heat Illness - Heat Exhaustion

thletes are especially prone to heat illness such as heat stroke and heat exhaustion, especially if they are unfamiliar with the warning signs. Heat illness can be life threatening if not taken seriously. Most serious heat illness in athletes can be prevented by following these basic guidelines and heeding the warning signs and symptoms.

There are three major types of heat illness, each with specific symptoms and treatments.

Heat cramps are a type of heat injury that usually occurs after strenuous exercise or an outdoor activity. Symptoms of heat cramps are severe pain and cramps in the legs and abdomen, faintness or dizziness, weakness, and profuse sweating.

Heat exhaustion happens when one is exposed to heat for a prolonged period of time. The body may become overwhelmed by heat when its mechanism (sweating) for keeping cool breaks down. Symptoms of heat exhaustion include nausea, dizziness, weakness, headache, pale and moist skin, weak pulse, and disorientation.

Heat stroke, unlike heat exhaustion, strikes suddenly and with little warning. When the body's cooling system fails, the body's temperature rises quickly. Heat stroke can be life threatening. Signs of heat stroke include very high body temperature, hot, dry skin, lack of sweating, fast pulse, confusion, and possible loss of consciousness.

Preventing Heat Illness

• Know that once you are thirsty you probably a bit dehydrated.
• Avoid intense exercise during the hottest time of day; train closer to sunrise or sunset.
• Wear light, loose wicking clothing so sweat can evaporate. Better yet, invest in some clothes that wick, like Cool-Max.
• Use a sunscreen to prevent sunburn which can limit the skin's ability to cool itself.
• Wear a hat that provides shade and allows ventilation.
• Stay Hydrated and drink plenty of liquids (16 to 20 ounces every hour).
• If you feel your exercise performance is suffering, stop activity and try to cool off.
• Do not drink alcohol or beverages with caffeine before exercise because they increase the rate of dehydration.

Remember, it is easier to prevent heat illness than to treat it once symptoms develop.

Quotes of the day and life ------>>>

"If you are patient in one moment of anger, you will escape a hundred days of sorrow."

Famous Quotes-

I want to know God's thoughts... the rest are details.

- Albert Einstein

An eye for eye only ends up making the whole world blind.

-M.K. Gandhi


Whatever the mind can conceive and believe, the mind can achieve.

-Dr. Napoleon Hill


Neither a lofty degree of intelligence nor imagination nor both together go to the making of genius. Love, love, love, that is the soul of genius.

-Wolfgang Amadeus Mozart

Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great.

-Mark Twain

I made this letter longer than usual because I lack the time to make it short.

-Blaise Pascal

Inspirational Quote--

Whether you think you can or whether you think you can't, you're right.

-Henry Ford

You see things; and you say 'Why?' But I dream things that never were; and I say 'Why not?'

-George Bernard Shaw

There is no use trying, said Alice; one can't believe impossible things. I dare say you haven't had much practice, said the Queen. When I was your age, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast.

-Lewis Carroll

The journey is the reward.

-Chinese Proverb

People are like stained-glass windows. They sparkle and shine when the sun is out, but when the darkness sets in, their true beauty is revealed only if there is a light from within.

-Elizabeth Kubler Ross

Motivational Quote--

Always listen to the experts. They'll tell you what can't be done and why. Then do it.

-Robert Heinlein

Nothing is particularly hard if you divide it into small jobs.

-Henry Ford

Someone's sitting in the shade today because someone planted a tree a long time ago.

-Warren Buffett