First Monday

SDP-city against a vicious circle!

This paper characterizes the software development craft’s vicious circle and proposes the first steps required to get out of it. As long as future software developers have no exemplary software (with patterns, design, and documentation) to study, the present software developers will not produce exemplary software. To overcome this, the first step is to make exemplary software widely available, and help developers to produce them. Despite most open source software being accessible, finding exemplary and qualified work is hard.

A software city is proposed for teaching and learning purposes, where (1) all works are open; (2) there is a pattern repository with the most important building elements and principles; (3) the patterns are underpinned by concrete, complete, running and documented examples (Software Development Pack or SDP); and, (4) experts help builders, and qualify the works. Only quality works are easy to use and easy to reuse. Let’s build an SDP-city where, besides cathedrals and bazaars, you can also find a city hall, schools, and exhibitions!


Software development craft’s vicious circle
Step 1: Pattern use, designing and documenting is not general. The average level of software development is not satisfactory.
Step 2: Exemplary software (with patterns, design, and documentation) are of great value, hence they are kept confidential and proprietary
Step 3: There is almost no exemplary software for teaching and learning purposes
Step 4: Developers are not capable of attaining the required knowledge for pattern use, designing, and documenting
The SDP framework, and the SDP-city implementation





In 2000, before teaching my first software development course, I was searching for concrete and complete, well–documented projects developed by the Unified Process (UP). I could not find any. Books usually do not have specific software supplements. The situation is even worse in a non English–speaking country like Hungary, since we are far from big bookstores and sources of good advice. Then I began to ask several software developers whether they had exemplary software to give or sell me. Most of them told me that they do not use any specific development method, especially not the UP. One developer used UP, but he could not give me anything, since the materials (specifications, source code) were confidential. In a seemingly contradictory way, the same developers continually complain about the difficulty of hiring good developers.

Teachers usually do not have time and enough practice to develop examplary software products for teaching and learning purposes. If the software development community wants to improve the level of software development in general, they have to supply teachers and learners with a widely accessible, high quality, easy–to–use, and easy–to–reuse software repository.



Software development craft’s vicious circle

Software development craft

"[it is important] to start paying attention to the craft of software development."
(McBreen, 2002)

A craftsman usually does not solve new and difficult problems, rather he applies the proven solutions by "repeating best practice of what works" [ 1]. A good craftsman, whether a blacksmith, an organ–builder, or a software developer, before completing his first work, examines other masterpieces, and gathers exemplary solutions which he can reuse in his own work.

"Just as the modern blacksmith benefits from better tools, materials, and understanding, software craftsmanship benefits from better computers, reusable components, and programming languages."
(McBreen, 2002)

Today, in the information age, craftsmanship still exists. Software development is a craft — one of the difficult ones, in fact.

In the past, an apprentice wandered to craftsmen in other towns in order to broaden his experiences. Every craftsman tried to study the patterns and the best practices of his own craft [ 2]. Today, in the information age, craftsmanship still exists. Software development is a craft — one of the difficult ones, in fact. Like all other craftsmen, a software developer has to examine other developers’ exemplary solutions. But after years of searching, I could hardly find any concrete and complete software development masterpieces. Today, in the age of the Internet, the doors to world famous workshops are closed to future software developer craftsmen. As far as I know, no book has been published that embraces the whole development cycle and provides complete software with documentation and source code from beginning to end. The masterpieces are either secret or have never been completed.

Software Development Pack (SDP)

"Example isn’t another way to teach, it is the only way to teach."
Albert Einstein

The real software development masterpiece is software with all of its accessories for use and reuse. I call this masterpiece a Software Development Pack. Here is the definition:

The SDP (Software Development Pack) is a task to solve on a computer with working and documented solutions. An SDP has all components necessary for using and reusing software. An SDP contains:


An SDP can be an application or a general purpose component. In the latter case, a test application is needed for demonstration.

The vicious circle

Figure 1: The vicious circle (drawing by Katalin Bérczi).

The motivation for writing this article is the recognition of the software development craft’s vicious circle (Figure 1), and a vision of getting out of it. The vicious circle is the following: Step 1. Pattern use, designing and documenting is not general. The average level of software development is not satisfactory. Therefore: Step 2. Exemplary software (with patterns, design, and documentation) are of great value, hence they are kept confidential and proprietary. Therefore: Step 3. There is almost no exemplary software for teaching and learning purposes. Therefore: Step 4. Developers are not capable of attaining the required knowledge for pattern use, designing and documenting. Therefore: Go to Step 1, and the circle closes.

As long as the future software developers have no exemplary software (with patterns, design and documentation) to study, current software developers will not produce exemplary software.

An explanation of the circle’s steps follows.



Step 1: Pattern use, designing and documenting is not general. The average level of software development is not satisfactory.

Developers agree, that the average level of software development is not satisfactory, and the main solution is software reuse in any form. Most developers also agree that pattern use, designing, and documenting is essential for effective reuse and maintenance. However, pattern use, designing, and documenting are not general practices.

Still in crisis?

"We’ve got big trouble in Software City."
(Gill, 2002)

Developing software is hard. User demands keep growing, and software products are getting more and more complex. A considerable percentage of projects fail, are not delivered on time, or have too many complaints after delivery. The following quotation is from Gill (2002):

"Sources such as objective statistics, self–grading, client reaction, and anecdotal experience all confirm that the rate of failed software development projects is embarrassingly high."

On the Software Engineering Institute’s (SEI) Web site (at we find:

"Data indicate that 60–80% of the cost of software development is rework — that is, fixing defects that are found during testing."

According to Gibbs (1994), the biggest problem is in the knowledge of software developers and their lack of quality training. He interviewed Brad J. Cox, who remarked:

"If we are ever going to lick this software crisis, we’re going to have to stop this hand–to–mouth, every–programmer–builds–everything–from–the–ground–up, preindustrial approach." [ 3]

Because of momentary performance expectations, developers have no time to search for patterns, to design or document.

"Most software development is a chaotic activity, often characterized by the phrase ‘code and fix’. The software systems are built without designing, on the basis of short–term decisions. ... As the system grows it becomes increasingly difficult to add new features to the system, ... bugs become increasingly difficult to fix, ... debugging is impossible to schedule"
(Fowler, 2003b)

Software reuse

"Good programmers know what to write. Great ones know what to rewrite (and reuse)."
(Raymond, 1998)

The software industry tries to ease the software crisis by software reuse. By using ready–made components and applications, well–tried solutions and patterns, a product has more chance to be user–friendly, reliable, maintainable, and ready on time. "If the average professional is asked what the principal benefit of object technology is, the answer is almost always reuse." [ 4]. Researchers generally agree that short–term investment into software reuse is refunded over the long term (Booch, 1994).

Karlsson (1995) classifies the reuse activities into two categories: (1) for reuse: developing and managing assets; (2) with reuse: developing and managing products. There are routine products which are new only for newborn babies, and there are innovative products, which must be created for a specific solution as a non–series case. Karlsson argues that at the moment most developers create routine products by themselves, perpetually reinventing the wheel. Jacobson, et al. (1997) say that theoretically, reuse could provide solutions to a large number of problems, but, in practice, organizations do not take advantage of it.

Every part of software development is reusable: design, use case, user interface, component, documentation, source code, and advice. Today, however, reuse mostly focuses on source code and technical solutions, and ignores the human aspects of software development. Until now, reuse technology has not been not in general practice.

Software pattern reuse

"... a pattern is a repeating best practice of what works — in any domain." [ 5]

Pattern use is a well–known technology of the last decade. Creating and using software patterns is a new way to reuse technology.

A software pattern (briefly pattern) is a general and documented solution of a frequently occurring problem, in a given software environment, which was tried by more than one person, more than one time. The pattern describes everything required for understanding a problem and solution, and for solving another, similar problem.

Larman points out: "patterns attempt to codify existing tried–and–true knowledge, idioms, and principles; the more honed and widely used, the better." [ 6] According to Gamma, et al. (1995), expert designers do not solve every problem from "first principles." Ralph Johnson remarks in Fowler (1997): "one of the biggest advantages of patterns is that they help us communicate better."

Well–known patterns are, for example, the GOF (Gang Of Four) patterns (Gamma, et al., 1995), Analysis patterns (Fowler, 1997), and the Patterns of Enterprise Application Architecture (Fowler, 2003b). A patterns library can be found at

Why do developers fail to design and document?

The problem is that patterns are not widely used. According to Manns (2002), organizations do not use patterns. Manns points out that pattern use is significantly influenced, among others, by the following factors: training, visibility (developer sees others using patterns), pattern repository, and an opinion leader. However, Manns does not examine the concrete values of these factors in organizations in general, i.e. whether developers are trained, whether pattern use is visible for them, whether they have pattern repository, or whether there are opinion leaders who try to show the advantages of pattern use. You can easily conclude: if these factors were improved, pattern use would increase. In my research, I found more factors influencing pattern use: teaching materials (e.g. books, e–learning materials), SDP repository and forum (e.g. workshops, e–mail lists) — but that’s another story.

Is design and documentation important?

"We can reduce test and rework costs significantly if we use better design and implementation practices."
SEI Web site, at

"Unfortunately, there is a gap between the state of the art and the state of the practice of software engineering" (SEI, 2004). Perhaps the reason is that "Designing object–oriented software is hard, and designing reusable object–oriented software is even harder" (Gamma, et al., 1995). In theory, developers know that a certain amount of design and documentation is an integral part of software development, and they are refunded in the long term. Before constructing software, it is essential to gather the main requirements, to define a clear architecture, and to give a broad outline of the reused parts. Larman argues that "knowing an object–oriented language is a necessary but insufficient first step to create object systems. Knowing how to ‘think objects’ is also critical." [ 7] Cooper (2003) complains that "most contemporary programmers work only from a list of features and a deadline." The Director of SEI (2004) states: "Commercial software products today are often riddled with defects — commonly known as "bugs" — that are introduced in the software’s design and development."

Why do developers fail to design and document? Because like other craftsmen, they want to work on the basis of patterns, concrete examples, and simple guidance; they cannot find them easily.

I argue that today there are mainly two kinds of developers: the big up–front designers and the coders:

Thus, these are the developing "patterns" today. Developers can find theories with no practical examples, or practical examples with no theory. However, it proves to be true that too much design and no design equally hinder the work. Probably the golden mean is a better way. The effort of agile methods is keeping design and documentations in ideal proportions, which unambiguously helps users and developers. In agile methods, design and documentation are people–oriented. Larman notes that: "Choose to create only those [documents] that really add value for the project, and drop them if their worth is not proved." [ 11] Gill writes the following about under– and over–planning: "Bad plans tend to make up for their lack of quality with sheer volume. The key concern should be quality, not size, and conciseness is a key metric of quality. Don't be fooled by size!" [12] An agile method, and so extreme programming [ 13], rejects the "significant effort in up–front design, in favor of a more evolutionary effort" (Fowler, 2003b).

In summary, design is important, but as Fowler (2001) notes, the design "provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style." Documentation is also important, but it must be simple, people–oriented and easy–to–produce. Developers need guidance and practical examples for simple but effective development strategies.



Step 2: Exemplary software (with patterns, design, and documentation) are of great value, hence they are kept confidential and proprietary

The practice of pattern use, designing and documenting is not prevalent. The average level of software development is not satisfactory. Therefore, developers and organizations usually do not make well–documented, "shop–window" software (SDPs). Since exemplary patterns and SDPs are rare, they are of great value. Exemplary software (with patterns, design, and documentation) are the intellectual jewels of an organization, hence they are kept confidential and proprietary. The problem is that only open source software is accessible, and often this software is not well designed and well documented. Searching and finding exemplary and qualified works is hard.

Open source

"Given enough eyeballs, all bugs are shallow."
Linus’s Law

Collaboration within the open source community (developers and end–users) promotes a higher standard of quality, and helps to ensure the long–term viability of both data and applications [ 14]. Raymond (1998) remarks that "it’s almost always easier to start from a good partial solution than from nothing at all."

Developers can find theories with no practical examples, or practical examples with no theory.

Just as technical equipment needs technical documentation and circuit diagrams for repairing it, software needs documentation and source code. Repair services for equipment must have at least some sort of documentation. It is not a safe situation if only the manufacturer owns a detailed description about how something works — what if you cannot get in touch with the manufacturer for any reason? It is the same situation with software: you need documentation and source code to have a chance to correct or improve software.

Open source software gives freedom, safety and even a certain degree of serenity to a distributor, developer, consumer and user: (1) It is good for the distributor because she has work: the distributor monitors the Internet, assembles, installs, and maintains software packages for consumers. (2) It is good for the developer because she reuses other developer’s works and asks for help; if the developer works on request, she is paid for correcting, completing, refactoring, developing new features, or for creating new software. (3) It is good for the customer because she can control the development process. So the developer’s work is more transparent and the future of the software is safer; software can be completed in shorter time, presumably with better quality; and, the software will be much more compatible with other programs. Smaller adjustments are much cheaper than doing it from scratch. (4) It is good for the user because she can use ready–made software at no charge; and, she can easily try them out. If the user is a helper (hacker), she can size up and show her programming skills, gain a new reputation, and can influence development.

I think that the main point of open source development style is that developers always add value to the top, continuously improving the well–tried best solutions. Developers can be paid for this addition. This way we have the chance for a better software world.

Closed documentation — trade secrets

"You can’t reuse it if you can’t see it."
(Larman, 2002)

Open source is good, but open source with open documentation is even better. Unfortunately, presently accessible open source software projects usually do not have adequate design and documentation. However, "free software needs free documentation" (GNU, 2003). On the great open source sites, such as Sourceforge or Freshmeat, some developers have proper documentation, but they make only the basic artefacts public. They often provide a statement like: "Basic documentation is available in ..."

There are a huge number of public sites dedicated to patterns all over the world. However, they are not well organized, and there are no effective searching possibilities. The best patterns are spread out in many expensive books. Buschmann, et al. (1996) notes:

"... most domain–specific patterns are confidential — they represent a company’s knowledge and expertise about how to build particular kinds of applications, so references to them are not available. We believe however, that more and more of this knowledge will become public over time. In the long term, sharing experience is usually more effective for everyone than trying to hold onto secrets."

Meszaros, et al. (1998) provide an explanation of a pattern:

So patterns are prepared in the first place for internal use. Although one of the desired criteria for software patterns is popular acceptance: "it is desirable for all software patterns to be published and publicly available ..." (Brown, et al., 1998).

The Open Group’s (2003) mission is to drive the creation of "boundaryless information flow" achieved by (among others): working with customers and sharing best practices; and working with suppliers to evolve and integrate specifications and open source technologies [ 15]. I hope that in the world of "boundaryless information flow" usable documentation will also flow.



Step 3: There is almost no exemplary software for teaching and learning purposes

Exemplary software (with patterns, design and documentation) are of great value, hence they are kept confidential and proprietary. Therefore, there is almost no exemplary software for teaching and learning purposes.

Concrete examples are needed

"It is easier to exemplify values than teach them."
Theodore M. Hesburgh

At ECOOP (European Conference on Object–Oriented Programming [ 16]) 2003 there was a one–day workshop with the title "Patterns in Teaching Software Development" (Angster, et al., 2004). The goal of the workshop was to discuss ideas about how to teach software development. Participants were encouraged to submit a small but concrete project (documentation and running application) developed by students. The workshop presenters were encouraged to submit a paper based on a given project. There were a number of valuable presentations and good ideas at the workshop. However, not one participant submitted a complete project to the workshop. Why? Is it too easy? Is it too hard? Is it secret? Does anyone need concrete SDPs (all documentations and source code)? Can we find any on the market? Discussion at the workshop definitely showed that there are problems with software development learning support.

Patterns are usually not underpinned by concrete, running examples, although they would be much more understandable and hence reusable with them. One of the desired criteria for software patterns is a solid solution: "it comprises substantial and valuable technical content. It provides substantial value to new software practitioners or experts not practicing this solution. A formal pattern presentation defines the solution from both abstract and concrete perspectives. In other words, there is an abstract description as well as a specific example... " (Brown, et al., 1998).

As Gamma, et al. note: "To reuse the design, we must also record the decisions, alternatives, and trade–offs that led to it. Concrete examples are important too, because they help you see the design in action." [ 17] Gamma, et al. (1995) present a case study, but their work has no concrete software supplement. This is badly needed, however, since "it’s very difficult to see what value a software feature has until you use it for real" (Fowler, 2003b).

Schneider and Winters’ (2001) excellent Applying use cases begins with a case study, but it stops at about a third of its development, leaving some questions for the reader. Schneider and Winters do not give a whole SDP as a supplement. It is fascinating because the authors argue for the value of practical examples in an earlier white paper (Schneider and Winters, 1999): "Designers trying to apply the UML are confused. It is large, and there are few guidelines as to how to apply the UML to solving problems ... Designers want less theory and more practical guidelines ... Consultants fill some of that need. Having examples of realistic problems would be better, but they need to be complete solutions from beginning to end." So even developers do not get adequate guidance; what then about instructors? As Fowler (1997) remarked:

"Most of the books concentrate on teaching a notation, suggesting a simple process of modeling, and illustrate it with a few examples."

Fowler’s pattern books are excellent and useful. But they are incomplete.

"This book is an incomplete but (I trust) useful compendium of advice on enterprise application architecture" [ 18].

"A second reason for describing highlights rather than complete models is client confidentiality" [19].

Concrete and complete examples (SDPs) and a comprehensive pattern repository are essential for teachers and learners. I have been searching for concrete examples for years, interpreting and complementing "half–baked" ones. I could not compare my creations to the great ones; they are flickering as a phantom behind theories.



Step 4: Developers are not capable of attaining the required knowledge for pattern use, designing, and documenting

There is almost no exemplary software for teaching and learning purposes. Therefore, developers are not capable of attaining the required knowledge for pattern use, designing, and documenting.

"We must reverse the decline in the quality of developer training."
(McBreen, 2002)

Organizations struggle because of a lack of quality software developers. Why?

Since we cannot do too much about the talent of developers in general, I think that the only solution is to train future developers and managers at a high level and help them in any way.

The Software Engineering Institute’s core purpose is to help others make measured improvements in their software engineering capabilities (SEI, 2004). Their vision document points out: "To be successful, integrated teams of developers, acquirers, and software users must have the necessary software engineering skills and knowledge to ensure that the right software is delivered to end users."

For this, the key solution would be the adequate education, continuous training, and accessible masterpieces (patterns and concrete examples) for all developers.

Developers are not capable of attaining the required knowledge for pattern use, designing, and documenting. Therefore, pattern use, designing, and documenting are not general. The average level of software development is not satisfactory. This is Step 1, so the vicious circle closes.



The SDP framework, and the SDP-city implementation

"Hidden knowledge decreases, but published knowledge increases."
Latin wisdom

To break the vicious circle, it is important to provide sufficient learning support to future developers. Giving elite training is not enough; as good sports results are impossible without massive participation in sports, good software development results are impossible without teaching the masses interested in programming. If patterns and concrete examples are not easily accessible, or they are too difficult to understand and use, teachers and learners will not bother with them. Teachers will teach and learners will learn with a minimum of effort. They will not use patterns, they will not design and document. After all, it is not instructors, but software corporations and other organizations who need well–trained, quality developers. I have a vision of an SDP framework which probably could help.

The SDP framework is a concept which can have any number of implementations. Thinking in objects, if the SDP framework is a class, the implementations are the instances. Organizations and schools can have their own instances, although open source and open documentation are recommended. The SDP-city will be an instance of the SDP framework.

SDP framework

The SDP framework is a conceptual framework for software development teaching purposes. It is an organization and repository which

The SDP framework contains as many "trademarked" works as possible. To achieve this, experts help and qualify works. On request, an author gets a shepherd [ 21], who directs him in creating a specific work, until the work achieves a proper level of quality. Searching is much more effective if works are filtered by quality.

The SDP framework’s mission is

Figure 2: Relationship between SDP and pattern repository.

The SDP framework is designed with the following main features:


The SDP-city is a concrete implementation of the SDP framework. It is an organization and Web site with working software; see The city is under construction. The SDP-city’s SDP will be put into the SDP-city’s SDP repository.




Experts agree that there are problems with the practice of software development. They also agree that pattern use, designing, and documenting are essential for effective reuse and maintenance. However, pattern use, designing, and documenting are not in general use. We can only in part blame developers for a lack of talent, for in fact developers do not get sufficient help from experts. Providing elite training is not enough; improved software development can only occur when proper training reaches large groups of students. Software development is a craft, and like all other craftsmen, a software developer has to work with other developers’ exemplary solutions. However, the value of exemplary software means that they are kept confidential and proprietary. There is almost no exemplary software for teaching and learning purposes. The essence of the vicious circle is that as long as the future software developers have no exemplary software (with patterns, design and documentation) to study, present software developers will not produce excellent new programs.

If it is in all of our common interests to train quality developers, it is vital to provide excellent examples in the education of future developers. We need a "boundaryless information flow" in the field of software development.

The SDP framework could be a first step to free ourselves of a vicious circle. The mission of the SDP framework is to foster and spread pattern use; to support new developers with basic practical material; and, to improve the quality of software development education. The SDP-city contains as many "trademarked" works as possible. To achieve this, experts will help and identify quality programming. Programmers in turn will receive assistance in the form of a shepherd, who directs efforts until programs have attained a sufficient level of quality. Searching will be much more effective if all of the works are filtered for quality. End of article


About the author

Erzsébet Angster is head of the Programming Department at Dennis Gabor College, Hungary. She has written ten books in the field of programming, in Hungarian. Her latest two–volume book is Object–Oriented Design and Programming, Java. In 2003 she was the "Informatics Teacher of the Year," awarded by the Hungarian Chief Information Officers’ Association.
E–mail: angster [at] sdp-city [dot] hu



1. The phrase is from Larman, 2002, p. 218.

2. My great–grandfather, József Angster, an organ builder, learnt his craftsmanship through 10 years of wandering in Europe in the nineteenth century.

3. Gibbs, 1994, p. 86.

4. Fowler, 1997, p. 11.

5. Larman, 2002, p. 218.

6. Ibid.

7. Larman, 2002, p. 3.

8. Rembrandt, Harmensz van Rijn. Dutch painter, 1606–1669.

9. See, accessed 10 April 2004.

10., accessed 10 April 2004.

11. Larman, 2002, p. 38.

12. Gill, 2002, Chapter 2.

13. See, accessed 28 November 2004.

14., accessed 10 April 2004.

15., accessed 10 April 2004.

16., accessed 28 November 2004.

17. Gamma, et al., 1995, p. 6.

18. Fowler, 2003a, Preface.

19. Fowler, 1997, p. 8.

20. Gill, 2002, Chapter 2.

21. The concept of shepherding comes from the pattern domain. The pattern community uses the shepherding process to improve the pattern quality; see, accessed 10 April 2004.



Erzsébet Angster, Joe Bergin, and Marianna Sipos, 2004. "Patterns in Teaching Software Development," In: Frank Buschmann, Alejandro P. Buchmann, and Mariano Cilia (editors). Object–oriented technology: ECOOP 2003 Workshop Reader. Berlin: Springer–Verlag, Lecture Notes in Computer Science, volume 3013, pp. 130–142.

Grady Booch, 1994. Object–oriented analysis and design with applications. Second edition. Redwood City, Calif.: Benjamin/Cummings.

William Brown, Raphael Malveau, Hays McCormick, and Thomas Mowbray, 1998. "The software patterns criteria. Proposed definitions for evaluating software pattern quality," version 10.2 (2 June), at, accessed 10 April 2004.

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal, 1996. Pattern–oriented software architecture: A system of patterns. Chichester: Wiley.

Alan Cooper, 2003. "The craft of programming," Visual Studio Magazine (June), at, accessed 10 April 2004.

Martin Fowler, 2003a. Patterns of enterprise application architecture. Boston: Addison–Wesley.

Martin Fowler, 2003b. "The new methodology," at

Martin Fowler, 2001. "Is design dead?" at

Martin Fowler, 1997. Analysis patterns: Reusable object models. Menlo Park, Calif.: Addison Wesley.

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, 1995. Design patterns: Elements of reusable object-oriented software. Reading, Mass.: Addison–Wesley.

W. Wayt Gibbs, 1994. "Software’s chronic crisis," Scientific American volume 271, number 3 (September), pp. 72–81.

Tyson Gill, 2002. Planning smarter: Creating blueprint–quality software specifications. Upper Saddle River, N.J.: Prentice Hall PTR.

GNU, 2003. "GNU free documentation license," at, accessed 10 April 2004.

James Hobart, 1995. "Principles of good GUI design," UNIX Review (September), and at, accessed 28 November 2004.

Ivar Jacobson, Martin Griss, and Patrik Jonsson, 1997. Software reuse: Architecture and organization for business success. New York: ACM Press.

Even–André Karlsson, 1995. Software reuse: A holistic approach. Chichester: Wiley.

Craig Larman, 2002. Applying UML and patterns: An introduction to object–oriented analysis and design and the unified process. Second edition. Upper Saddle River, N.J.: Prentice Hall PTR.

Hairy Larry, 2000. "The document is the program," at, accessed 15 February 2003.

Mary Lynn Manns, 2002. "An investigation into factors affecting the adoption and diffusion of software patterns in industry," Ph.D. dissertation, De Montfort University (Leicester, U.K.), at, accessed 10 April 2004.

Pete McBreen, 2002. Software craftsmanship: The new imperative. Boston: Addison–Wesley.

Gerard Meszaros and Jim Doble, 1998. "A pattern language for pattern writing," In: Robert C. Martin, Dirk Riehle, and Frank Buschmann (editors). Pattern languages of program design 3. Reading, Mass.: Addison–Wesley, pp. 527–574.

Eric S. Raymond, 1998. "The cathedral and the bazaar," First Monday, volume 3, number 3 (March), at, accessed 10 April 2004.

Geri Schneider and Jason P. Winters, 2001. Applying use cases: A practical guide. Second edition. Boston: Addison–Wesley.

Geri Schneider and Jason P. Winters, 1999. "A Review of the Current State of Practice," UML World DesignFest, White paper,, accessed 20 May 2003.

SEI (Software Engineering Institute), Carnegie Mellon University, 2004. At, accessed 20 September 2004.

Bruce F. Webster, 1996. "The real software crisis: The shortage of top–notch programmers threatens to become the limiting factor in software development," Byte (January), at, accessed 28 November 2004.

Editorial history

Paper received 11 May 2004; accepted 5 November 2004.
HTML markup: Edward J. Valauskas; Editor: Edward J. Valauskas.

Contents Index

Copyright ©2004, First Monday

Copyright ©2004, Erzsébet Angster

SDP-city against a vicious circle! by Erzsébet Angster
First Monday, volume 9, number 12 (December 2004),