A short time-line

The first programmable computers were set to use in the mid-twentieth century. In the early stage of computing computers were used as large programmable calculators, set to solve complex mathematical problems. Hardware was initially the limiting factor, but the hardware was rapidly improving, though. With improved hardware the appliance of software grew, leading to increased complexity in software. Already in the early 1960s computer professionals warned about these problems. "A combination of increasing complexity of systems and the relative inexperience of systems development staff led to late deliveries of systems, escalating costs and failed software projects" [FRIEDMAN1989](Friedman 1989, p. 99). Another pertinent issue was the increased cost and problems with maintaining existing software systems. The limiting factor was shifting from software to hardware. Some came to call this shift of emphasis the software crisis.

By the late 1960s the problems cause by this shift were becoming apparent. The computer industry as a whole increased focus on how they developed software. A turning point came at the Garmisch Conference of 1968. Addressing these problems, the conference participants agreed that the solution would be to apply tried and tested methods of traditional engineering to software development. Calling this software engineering, they recommended that by standardizing the program structure through modularization, and to order the systems development process, their problems would be solved. "These recommendations would increase the observability and measurability of systems development and thereby increase management control" [FRIEDMAN1989] (Friedman 1989, p. 106).

In Fredrick Brooks [BROOKS1995](1975) argues that software engineering was not the silver bullet to solve the problems facing software systems developers. During the 1970s it was becoming apparent that software engineering had its limitations. There were still problems left to be solved. Different responses to this failure were suggested. One of them, as drawn up by Claudio Ciborra, explains the problem accordingly:

Information systems development often does not lead to a more effective and human organization … because systems designers do not apply structured methods or organization … [CIBORRA1987](Ciborra 1987, p. 2).

The answer to the problem is not Ciborra's but rather his recounting of the arguments of software engineering's proponents. For these the response to the short-comings was to continue the quest for a better methodology. During the late 1970s and early 1980s a new methodology emerged—object-orientation. With its roots in a programming paradigm from the early 1970s of collecting data and their operations into objects, practitioners saw the possibility of transferring the basic principles of object-orient programming into the domain of software engineering. By the 1990s this approach would be embraced by the computer industry as a whole as the silver bullet to solve all problems of software engineering. While it is apparent that object-orientation did help bridge the gap between systems modeling and realization and proved itself an invaluable tool for conceptualizing software systems, did it really address the underlying problems of classic software engineering or was it simply yet another methodology in a long line of succession?

As Miller observed in 1992, despite the efforts of the software engineering community "an increasing number of practitioners are beginning to realize that old approaches are not appropriate any more" [MILLER1992](Miller 1992, p. 93). Since the early 1970s, a group of researchers and practitioners have argued that neither software nor hardware are the limiting factors in software systems development. They argue the short-comings are human. Software engineering has eased issues like schedule slippage, bugs, and failure to stay within budget, but do they address the source of the problem? As early as the late 1960s and early 1970s software systems developers note the discrepancy between users requirements and software systems [BOGUSLAW1965](Boguslaw 1965) [MUMFORD1972](Mumford 1972). It is argued that software "systems has to be useful in terms of allowing users to do their jobs better" [FRIEDMAN1989](Friedman 1989, p. 175). Software constraints are no longer the sole limiting factor; user relations constraints are also a limitation. Not only computer professionals admitted human-computer interaction was poor, studies shows developers have problems understanding the users' needs and requirements for software systems.

For those subscribing to this new view of software systems development it was no longer a question of producing the software system right, but producing the right software system to meet its users' needs. This strain of software systems development is sometimes called the alternative approach. The alternative approach springs forth from as varied fields as linguistics, psychology, and sociology. Their only common denominator is that they seek alternative ways to those of software engineering. An implication of the shift of focus from producing the software systems right to producing the right software was a shift of attention towards the users' needs and requirements came into focus. With this shift came an appreciation that there were conflicting interests between participants in the software systems development process—especially users and management [BANSLER1989](Bansler 1989).

With its roots in technical communities of the 1960s, hacking has been a strain of software systems development running in parallel with software engineering for the past 30 odd years. Hacking is not to be confused with its malicious cousin, cracking, which aims at breaking into software systems. An entire mythology has been spun around hacking over the past three decades. The first written accounts on hacking is the Jargon File, an inside view of how the hacker community wants to view itself. The Jargon file was later published as The New Hacker's Dictionary [RAYMOND1998](Raymond 1998). The Jargon File was a collection of jargon from early technical communities in the United States, the first hacker communities. The Jargon File became, quite typical of the culture, a shared repository of technical slang being updated by a great number of people during its almost thirty year lifespan.

The hacker is "a person who enjoys exploring the details of programmable systems and how to stretch their capabilities" [RAYMOND1998](Raymond 1998, p. 233). The hack is "an incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed" [RAYMOND1998](Raymond 1998, p. 231). Hacking is consequently the activity a hacker undertakes to produce a hack. Hackers like to see themselves as computer experts pushing the limits of technology. Writing about the early hackers by MIT's AI Lab, Steven Levy identified six principles he coined the hacker ethic, of which the the hands-on imperative, the principle that all information should be free, and to distrust authority and promote decentralization are those that rings through all literature on hacking.

At the core of hacking lies key values as openness, sharing, freedom and cooperation. Its practitioners considered hacking a community based approach to software systems development. As an approach to software systems development, hacking has produced viable systems in wide-spread use. Examples include the Unix operating system, the Internet standards, the GNU project, and more recently the Linux operating system and Apache Web server.