Is teaching software design a ‘wicked’ problem too?

  • David Budgen
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 895)


The creative act of design has been described as being a wicked or ill-structured problem, in which finding a solution to one aspect may only serve to reveal a more complex problem. The task of designing software offers additional dimensions to this, in that the media is invisible, is capable of almost infinite variations of form, and has both dynamic and static properties. These characteristics provide difficulties when teaching our students about software design, and our ideas about how to do this also tend to be coloured by our experiences in teaching them how to program. In this paper we argue that an approach based on a ‘programming’ metaphor is inadequate for teaching students about designing software, and that the activity of teaching design is not readily amenable to the use of highly structured teaching practices. Indeed, we can therefore identify this too as being an example of a wicked problem.


Mental Model Software Engineer Software Design Design Idea Teaching Design 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [1]
    David Budgen. Software Design. Addison-Wesley, 1993.Google Scholar
  2. [2]
    J P Jacquot and J Guyard. Seven Lessons to Teach Design. In J E Tomayko, editor, Software Engineering Education: SEI Conference 1991, Lecture Notes in Computer Science No 536, pages 195–204. Springer-Verlag, 1991.Google Scholar
  3. [3]
    Frederick P Brooks Jr. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, pages 10–19, April 1987.Google Scholar
  4. [4]
    H J Rittel and M M Webber. Planning problems are wicked problems. In N Cross, editor, Developments in Design Methodology, pages 135–144. Wiley, 1984.Google Scholar
  5. [5]
    B Adelson and E Soloway. The role of domain experience in software design. IEEE Transactions on Software Engineering, SE-11(11):1351–1360, November 1985.Google Scholar
  6. [6]
    Barbara Hayes-Roth and Frederick Hayes-Roth. A Cognitive Model of Planning. Cognitive Science, 3:275–310, 1979.Google Scholar
  7. [7]
    Raymonde Guindon and Bill Curtis. Control of Cognitive Processes during Software Design: What Tools are needed? In Proceedings of CHI'88, pages 263–268. ACM Press, 1988.Google Scholar
  8. [8]
    Bill Curtis, Herb Krasner, and Neil Iscoe. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31(11): 1268–1287, November 1988.Google Scholar
  9. [9]
    Bill Curtis and Diane Walz. The Psychology of Programming in the Large: Team and Organisational Behaviour. In J-M Hoc, TRG Green, R Sumurcay, and D J Gilmore, editors, Psychology of Programming, pages 253–270. Academic Press, 1990.Google Scholar
  10. [10]
    Willemien Visser and Jean-Michel Hoc. Expert Software Design Strategies. In J-M Hoc, TRG Green, R Samurcay, and D J Gilmore, editors, Psychology of Programming, pages 235–249. Academic Press, 1990.Google Scholar
  11. [11]
    Simon P Davies and Adrian M Castell. Contextualizing design: narratives and rationalization in empirical studies of software design. Design Studies, 13(4):379–392, 1992.Google Scholar
  12. [12]
    Iris Vessey and Sue A Conger. Requirements Specification: Learning Object, Process and Data Methodologies. Communications of the ACM, 37(5): 102–113, May 1994.Google Scholar
  13. [13]
    M Page-Jones. The Practical Guide to Structured Systems Design. Yourdon Press, 2nd edition, 1988.Google Scholar
  14. [14]
    John Cameron. JSP & JSD: The Jackson Approach to Software Development. IEEE Computer Society Press, 2 edition, 1989.Google Scholar
  15. [15]
    Grady Booch. Object-Oriented Analysis and Design. Benjamin/Cummings, 1994.Google Scholar
  16. [16]
    David Budgen, Mustafa Marashi, and Andrew Reeves. CASE Tools: Masters or Servants. In Proceedings 1993 Software Engineering Environments Conference, pages 156–165. IEEE Computer Society Press, July 1993.Google Scholar
  17. [17]
    David Budgen. Some Conclusions about the Evolution of Software Design Practices. Technical report, Department of Computer Science, Keele University, 1994. (In preparation).Google Scholar
  18. [18]
    M J King and J P Pardoe. Program Design Using JSP: A Practical Introduction. Macmillan, 1985.Google Scholar
  19. [19]
    Downs E., P. Clare, and I. Coe. SSADM: Structured Systems Analysis and Design Method: Application and Context. Prentice Hall, second edition, 1992.Google Scholar
  20. [20]
    I Hayes, editor. Specification Case Studies. Prentice Hall, 1987.Google Scholar
  21. [21]
    D Garlan, M Shaw, C Okasaki, C M Scott, and R F Swonger. Experience with a Course on Architectures for Software Systems. In C Sledge, editor, Software Engineering Education: SEI Conference 1992, Lecture Notes in Computer Science No 640, pages 23–43. Springer-Verlag, 1992.Google Scholar
  22. [22]
    Stuart Pugh. Total Design: Integrated Methods for Successful Product Engineering. Addison-Wesley, 1991.Google Scholar
  23. [23]
    Grant Friel and David Budgen. Design Transformation and Abstract Design Prototyping. Information and Software Technology, 33(9):707–719, November 1991.Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 1995

Authors and Affiliations

  • David Budgen
    • 1
  1. 1.Department of Computer ScienceKeele UniversityStaffordshireUK

Personalised recommendations