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!
Contents
Introduction
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
Conclusion
Introduction
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
(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.
(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)
Albert EinsteinThe 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:
- Vision (short, overall description of the task)
- Technical documentation (requirements, logical design, implementation design etc.)
- User’s guide
- Source code (with comments)
- Running code (deployment pack, test data)
Optionally
- Supplementary files (e.g., CASE models, project files)
- Development history (sequencing, milestones, preceeding documents and models, successes, misleads, lessons learnt)
- Teaching materials, which help in understanding the pack
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?
(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):
On the Software Engineering Institute’s (SEI) Web site (at http://www.sei.cmu.edu/director/aboutSEI.html) we find:
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:
Because of momentary performance expectations, developers have no time to search for patterns, to design or document.
(Fowler, 2003b)Software 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
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 http://hillside.net/patterns.
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?
SEI Web site, at http://www.sei.cmu.edu/director/aboutSEI.html"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:
- Big up–front designers invest a huge amount of energy into design before construction (Fowler, 2003b). During iterations, they continuously try to synchronize design and code. Raymond (1998) compares this style to building cathedrals. It turned out that these engineering (or heavy) methodologies do not work well. The most frequent criticism of these methodologies is that they are bureaucratic and predictive rather than adaptive (Fowler, 2003b). Additionally they are difficult and have no adequate learning support. Most developers cannot afford even to study these methods due to their complexity. And there is another important thing to consider: designing cannot survive long without practice. Let’s quote Rembrandt [8]: "Try to put well in practice what you already know. In so doing, you will, in good time, discover the hidden things you now inquire about." In addition, big up–front designers’ works, due to their great value, are usually not public, they are kept confidential and proprietary.
- Coders jump into coding without much design. Unfortunately, in the open source community there are many coders. On open source sites such as Freshmeat [9] and Sourceforge [10] technical documentation is not general. The source codes are generally well documented, and certain projects have user guides and database design documents, but they do not have requirements documentation, software architecture documentation, domain– or use case model documentation. In the open source world the project’s documentation menu is usually empty. As a contradiction, I found several articles and comments that claim design and documentation. On Freshmeat, Larry (2000) writes about the types and importance of documentation. He argues that developers neglect even user documentation. According to Larry, most developers lack writing and communication skills. Ironically, on Freshmeat there are more than 50 projects implementing a UML modelling CASE tool, but only a few have UML designs at all!
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
Linus’s LawCollaboration 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
(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:
Meszaros, et al. (1998) provide an explanation of a pattern:
- Problem: How do you share a solution to a recurring problem with others so that it may be reused?
- Solution: Write down the solution using the pattern form ... Distribute the resulting pattern to the largest audience you feel it could help that does not compromise your competitive advantage. Often, this means publishing your patterns exclusively within your company via Intranets or company journals.
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
Theodore M. HesburghAt 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:
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.
(McBreen, 2002)Organizations struggle because of a lack of quality software developers. Why?
- Some argue that there simply are not enough talented individuals around. For example, Webster (1996) states that great programmers are "getting really hard to find ... Excellent developers, like excellent musicians and artists, are born, not made. The number of such developers is a fixed (and tiny) percentage of the population."
- Others blame a lack of adequate training. Gill [20] remarks "the bad practices that programmers can adopt are truly astounding." Gill presses for training, and hiring "talented, experienced developers with good programming standards and coding reviews." According to Hobart (1995) "good designs don’t happen naturally. They require that the developer learn and apply some basic principles..."
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
Latin wisdomTo 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
- gives an opportunity to store and retrieve software development works (patterns, SDPs, teaching materials, articles, antiworks, and books); and,
- provides a home for forums (mailing lists, workshops, training sessions).
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
- to diffuse pattern use, and to reduce the developer’s degree of novelty in it;
- to support new developers with a basic practical material; and,
- to improve the quality of software development education.
Figure 2: Relationship between SDP and pattern repository. The SDP framework is designed with the following main features:
- Pattern repository: In the framework there is a pattern repository. This repository is simple, but as complete as possible. It contains patterns for every frequently used domain (business, database, gui, documentation) on every level (architectural, design, code).
- SDP repository. In the framework there is an SDP repository. A tight relationship exists between pattern and SDP repositories (Figure 2). If possible, every pattern is demonstrated by at least one SDP. SDPs are built from patterns in the repository. The number of patterns used in an SDP can vary, the sufficient condition is set by the shepherd or the jury individually.
- Teaching materials: In the SDP framework there are teaching materials. It is recommended that there are teaching materials for most of the patterns and SDPs, and that all practical examples are taken from the SDP repository.
- Training: In the SDP framework there is training. The training materials are mostly from the SDP framework.
- Quality control: The SDP framework achieves quality by professional coordination. With the assistance of a jury and shepherds, all works are qualified. A shepherd is a consultant, who helps an author create her work. Every author can ask for a shepherd under certain rules. The jury ensures a consistent level of quality.
- Design and documentation: The ambition of the SDP framework is that all works (especially the SDPs) are well–designed and well–documented. It is recommended to keep design and documentations at an ideal size, which unambiguously helps users and developers.
- Developer involvement: Developers are involved in building the framework, i.e. making works (patterns, SDPs), and to criticize and improve the work of others. In this way developers become more interested in learning tricks and practices in software development.
- Forum: In the SDP framework there will be opportunities where you can express your opinion, hear from others, ask questions, and participate in digital and face–to–face forums.
- Ease of use: The SDP framework is easy to use. The works are easy to find, easy to use, and easy to reuse.
- Openness: All works are accessible to anyone following the principles of open source and open documentation.
SDP-city
The SDP-city is a concrete implementation of the SDP framework. It is an organization and Web site with working software; see http://sdp-city.hu. The city is under construction. The SDP-city’s SDP will be put into the SDP-city’s SDP repository.
Conclusion
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.
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.
Web: http://www.gdf.hu/progtanszek/angster
E–mail: angster [at] sdp-city [dot] hu
Notes
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.
8. Rembrandt, Harmensz van Rijn. Dutch painter, 1606–1669.
9. See http://freshmeat.net, accessed 10 April 2004.
10. http://sourceforge.net, accessed 10 April 2004.
13. See http://www.extremeprogramming.org/, accessed 28 November 2004.
14. http://sourceforge.net, accessed 10 April 2004.
15. http://www.opengroup.org, accessed 10 April 2004.
16. http://www.ecoop.org/, accessed 28 November 2004.
17. Gamma, et al., 1995, p. 6.
21. The concept of shepherding comes from the pattern domain. The pattern community uses the shepherding process to improve the pattern quality; see http://hillside.net/patterns, accessed 10 April 2004.
References
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 http://www.antipatterns.com/whatisapattern/, 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 http://www.fawcette.com/vsm/, accessed 10 April 2004.
Martin Fowler, 2003a. Patterns of enterprise application architecture. Boston: Addison–Wesley.
Martin Fowler, 2003b. "The new methodology," at http://martinfowler.com/articles.html.
Martin Fowler, 2001. "Is design dead?" at http://www.martinfowler.com/articles/designDead.html.
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 http://www.gnu.org/copyleft/fdl.html, accessed 10 April 2004.
James Hobart, 1995. "Principles of good GUI design," UNIX Review (September), and at http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm, 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 http://freshmeat.net/articles/view/140/, 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 http://www.cs.unca.edu/~manns/, 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 http://www.firstmonday.org/issues/issue3_3/raymond/, 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, http://books.txt.com, accessed 20 May 2003.
SEI (Software Engineering Institute), Carnegie Mellon University, 2004. At http://www.sei.cmu.edu/, 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 http://www.byte.com/art/9601/sec15/art1.htm, accessed 28 November 2004.
Editorial history
Paper received 11 May 2004; accepted 5 November 2004.
HTML markup: Edward J. Valauskas; Editor: Edward J. Valauskas.
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 - 6 December 2004
https://firstmonday.org/ojs/index.php/fm/article/download/1195/1115
