Design of Interventions for Instructional Reform in Software Development Education for Competency Enhancement
Further, the conceptions related to programming languages grow in sophistication from simplest
levels of viewing a programming language as a utility program that enables programs to be
written, to the second level of code as a set of instructions, commands, symbols, and constructs.
The third level in this order is viewing programming language as a means of communication
between programmer and computer to enable communication between computer and user. The
highest level views programming language as a medium of expression for the programmer to
express solutions.
In our 2009 survey on required competencies for software developers, twenty software
professionals assigned ‘problem solving ability’ an average rating of 3.2 on a scale of 0-4. A
large majority these respondents (80%) recommended it to be a critical or very important
competency with respect to the requirements of software developers' multi-faceted professional
activities.
With reference to Appendices A2 and A3, complex problem solving of software developers also
relates to the following:
1 Ability to convert ill-defined problematic situations into software solvable
problem
2 Problem orientation, problem definition and formulation, generations of
alternatives
3 Emphasis on elegant and simple solutions
4 Ability of infusing different thinking patterns developed through their experience
in other domains
5 Inclination for reuse and synthesis by integration
6 Solution implementation and verification
7 Project planning and management
8 Sense of urgency and stress management
Good Solutions
Conceptualizing programming to become part of the programming community and
conceptualizing programming language as a medium of expression of solution are indicators of
the possibility of multiplicity of solutions for the same problem. The solutions may suffer from
113
shortcomings like over-simplification, over decomposition, under-decomposition, or disordered
management of complexity in a disordered manner. It is not sufficient to somehow solve
complex problems. The need of elegance, i.e., ordered management of complexity, increases
with increasing number and diversity of items, relations, correlations, and systems of relations.
Elegant management of complexity affords overall comprehension and continuous orientation.
Like good literature, architecture, or some other work of art, elegant software exhibits clarity,
simplicity, precision, minimized interfaces, orderliness, coherence, and consistence, without
compromising on integrity and performance. Avoiding unnecessary complications is a necessary
requirement for elegant solutions. Software developers’ aesthetical sense, urge for elegance,
patience, and systems–level perspective are necessary driving force for imbibing elegance in
their solutions.
Developing elegant software also requires good understanding of the specific problem and also
its context. Multidimensional complexity of application domains has to be registered, facilitated,
and expressed in software constructs. Hence, not just technical and computational thinking
competence, but domain competence is also necessary for developing elegant software.
Good software also includes defense, error-handling, and recovery mechanisms for various kinds
of errors: hardware-level, programming, or user induced. It also affords testability and
portability.
Problem Solving
In a study [191], almost unanimously, i.e., 97.7% of 1023 experts rated ‘problem solving’ as an
important element of human intelligence. In its most simplistic interpretation, a problem is
something that cannot be solved in a single, obvious step. Gomes and Mendes also provide some
of the following interesting definitions of problem and problem solving:
Pérez et al. - problem is a situation for which there isn’t an evident solution.
Perales - problem is any situation that produces, on one hand, a certain degree of uncertainty
and, on the other, behavior in search of a solution.
114
Gagné - problem solving is a process where the apprentice/learner discovers a combination of
rules previously learned that he/she can apply to reach a solution for a new problematic
situation.
Nickols [192] opines that what characterizes a problem is uncertainty about action, having a goal
and not knowing how to achieve it. Problem solving depends upon cognitive processes of
problem anticipation and identification, problem understanding, problem definition, problem
formulation, problem representation, generations of alternatives, decision making and planning,
implementation and integration, monitoring, evaluation, improvisation, and solution
communication.
Jonassen [193] has proposed a taxonomy of problems based on variations in problem types and
representations. The problem types vary in a three dimensional continuous space of three factors:
structured-ness, complexity, and degree of domain specificity. Software problems are domain
specific, complex, and ill structured. Based on the cognitive task analysis of various kinds of
problems, Jonassen has identified eleven different kinds of problems. Software developers
typically deal with all these kind of problems. Nickols’ typology of problem solving approaches
[198] comprises of (1) repair approach, (2) improvement approach, and (3) engineering
approach. Software developers mainly adopt the later two approaches, because seemingly, repair
problems in software systems are actually improvisation problems. Annexure AN6 gives more
details of these models.
Expert programmers are found to be good at logical thinking; many of them also enjoy puzzlesolving
[194]. Metzger [157] has viewed debugging as a search problem like mathematical
problem solving that is solved using a variety of search strategies like binary search, greedy
search, depth-first search, and breadth-first search. In his classic, ‘How to solve it,’ famous
mathematician Polya [195] listed four phases of problem solving: (i) understand the problem,
(ii) plan the solution, (iii) execute the plan, and (iv) review the results. More details are given in
Annexure AN6.
Drawing analogies between debugging and mathematical problem solving, Metzger [157]
explains many heuristics for solving debugging problems: (1) stabilize the problem, (2) create a
115
standalone test case, (3) categorize the problem with reverence to correctness, completion,
robustness, and efficiency, (4) describe the problem according to a standard methodology, (5)
explain the problem to someone else, (6) recalling a similar problem, (7) drawing diagrams like
control flow graph, data flow graph, and complex data structures with pointers, and (8) choosing
a hypothesis from historical data. Further, he has also suggested some strategies like program
slice strategy, deductive reasoning strategy, and inductive reasoning strategy for debugging.
Cognitive psychologists have studied problem solving methods for the last few decades. Galotti
collates some general domain independent techniques for puzzle-like problems [196]. These
include: generate and test, means-ends analysis, working backward backtracking, reasoning by
analogy. Annexure AN6 gives more details of these.
Creative Problem Solving
Stoycheva and Lubart [197] have elaborated upon a creative problem solving process. This
process involves five main activities of data finding and mess finding, problem finding, idea
finding, solution finding, and acceptance finding. The first activity of data and mess finding is
carried out by collecting data from the senses, experiences, knowledge, feelings, opinions,
emotions, memories, fantasies, future projections, interaction with others, information on the
social roles, and situation. Data collection can also be purposefully unstructured, random, and
divergent. Data and mess finding also involves evaluation of relevance, interconnectedness, and
importance of collected data. Through the analysis of this data, mess is discovered, created, or
recreated.
The second activity of problem finding (or problem defining) is most creative in the problem
solving process. Creative people try out many formulations and interpretations until one is found
that best fits the data and offers the best opportunities for solving the problem. In this reference,
Nickols [198] insists on defining the problem and also the solution state. He recommends to
clearly detailing out the boundaries, distinguishing characteristics, the nature, and meaning of
solution state. He [199] also insists on defining objectives and goals through inquiring about
what are we trying to achieve, preserve, avoid, or eliminate?
116
The third activity of creative problem solving, idea finding, aims to filter out the most promising
options which are identified for further elaboration. It involves multi-perspective thinking about
concepts and experience. The fourth activity of solution finding is about examining selected
alternatives from multiple perspectives for their pluses, minuses, and other interesting aspects. It
involves exploring and finalizing the criteria for evaluation of alternatives. Further, alternatives
are evaluated using the chosen criteria, and the most appropriate is chosen for implementation.
Finally, the activity of acceptance finding is about successful implementation. It also requires
envisaging how different stakeholders will react to the innovation.
With reference to abovementioned creative problems solving process, we recently conducted a
LinkedIn Poll among software professionals. Seventy-six software professionals responded to
this poll. The respondent professionals were well distributed in terms of age and job functions. In
all, 7% respondents were older than 55 year, 33% were in the age group of 35- 54, 47% were in
the age group of 25- 34, and 13% belonged to the age group of 18-24 years. In terms of job
function, their distribution was: 13% in consulting, 38% in engineering, 38% in product, and
13% in creative functions. All respondents belonged to large or enterprise organizations.
With respect to the problem solving skills for software work, the respondents identified the most
serious weakness of Indian engineering graduates as follows:
a. Idea and/or solution finding (36%),
b. Problem (re)formulation (22%),
c. Implementing (18%),
d. Mess identification (12%), and
e. Stakeholders’ acceptance (12%).
Some respondents also commented as follows:
“…engineers tend to assume the cause of the problem and jump to solutioning. This usually leads to
compounding the situation. Engineers tend to overlook the importance of problem assessment,
analysis and ascertation.”
“…our grads are enthusiastic and want to provide a quick fix to the problem, which is preventing
them from thinking in terms of the "5 Why's"…”
It shows the importance of creativity with reference to problem solving through software development.
This issue is discussed in details again in Section 5.3.
117
Section 4.5.1: Expert problem Solvers
Research on expertise has shown that it takes approximately ten years to turn a novice into an
expert. Hence, the four year undergraduate education needs to prepare the student to make the
rest of the progress. In early 1970s, Gordon Institute proposed a famous four-stage conscious
competence theory. As per this theory, the competence has four stages: unconscious
incompetence, conscious incompetence conscious competence, and unconscious competence.
Nonaka added a fifth stage to this and called it reflective competence [200].
Winslow [201] refers to the five levels of expertise as suggested by Dreyfus and Dreyfus in
1985. These are the levels of novice, advanced beginner, competence, proficiency, and expert.
In the specific context of computing professionals, Denning [202] has refined Dreyfus levels, has
added two more levels (master and legend) after expert. We have merged Gordon Institute’s and
Denning’s levels into a single ladder. The merged levels are shown in Table 4.7. First seven
levels of this are included in our proposed framework of pedagogical engagements in software
development education (ref: Table 8.2, first column).
118
Table 4.7: Competency ladder (Integrating the ladders by Gordon Institute, Dreyfus and Dreyfus, and Denning)
Level
1 Unconscious
incompetence
2 Conscious
incompetence
3 Novice
(beginner)
4 Advanced
beginner
5 Entry-level
Professional
(competent)
6 Proficient
professional
Description with respect to software professionals
Does not recognize the competency deficit, nor desires to learn.
Recognize the competency deficit, without addressing it.
Aims to learn objective facts, features, and rules for determining actions without being context
sensitive. Focus on syntax etc. Learn through memorization and drill.
Recognizes common situations that help in recalling which rules should be exercised, starts to
recognize and handle situations not covered by given facts, features and rules Learns through
problem solving and repeated practice with common situations.
Performs most standard actions without conscious application of rules after considering the
whole situation. Handles new situations through appropriate application of rules, can design
systems. May lead. Learns through advanced problem solving, projects, extensive practice in
common and exception situations, and participation in professional networks.
Effortlessly deals with complex situations, no longer has to consciously reason through all the
steps to determine a plan, appropriate actions come from experience and intuition. Design and
mange complex systems, ingenious solutions. Learns through apprenticeship to experts,
coaching, putting self into wide range of situations, membership and contributions to
professional networks. Teaches others.
7 Expert Consistently inspiring and excellent performance. An expert generally knows what to do, base
upon mature and practical understanding. Performance standards are well beyond those of
most practitioners. Extensive experience with large systems, appreciate subtle and indirect
design issues and customer concerns, leads well. High productivity. Learns through
apprenticeship to masters, advanced coaching, and development of breadth. Years/decades of
experience.
8 Master Capacity for long range strategic thinking and action. Sees historical drifts and shifting
clearings. Has developed a distinctive style. Has produced innovations, altered the course of
history in the field. Teaches others to be experts and masters. Develops new methods, admired
for long. Learning by working with other masters. Creates and leads professional networks.
9 Legend Has attained high standing. Work has widely accepted impact. Shapes directions of the field.
Costa and Kallick [203] have identified sixteen characteristics of what intelligent people do
when they are confronted with problems, the resolution to which is not immediately apparent.
These are listed in Annexure AN6.
Problem solving requires cognitive and meta-cognitive processes and also affective and conative
elements of self-confidence, perseverance, open-mindedness, motivation, and mindful effort.
Meta-cognitive aspects have been discussed under ‘critical and reflective thinking.’ The
affective and conative elements are elaborated in sixth chapter.
Galotti [196] describes some findings related to factors that hinder problems solving. Mental set
is the tendency to adapt a certain framework, strategy, or procedure, or more generally, to see
things in a certain way instead of another. It causes people to make certain unnecessary
119
assumptions even without awareness. Incomplete or incorrect representations make problems
solving much harder.
Jonassen [193] and Galotti [196] have discussed the individual differences in problem solvers.
The prior experiences of problem solvers enrich their mental corpus of problem schemas,
enabling them to recognize different problem states, and move faster towards implementation.
Expert programmers have been found to have this characteristic [204]. They are persistent, and
their mental models of their program comprehension exhibit the following five characteristics:
hierarchical and multilayered, explicit mapping between layers, recognition of basic patterns,
well-connected internally, and well-grounded in the program text. They also choose and mix
their richer mental models in an opportunistic way [201].
Experts in any domain are able to more easily pick up more perceptual information, recognize
more patterns, create more hypotheses, perform skills, and also represent the problems at more
deeper and abstract levels. Expert programmers have good problem solving skills,
determination, and persistence. They gather clues, in the form of facts and information to help in
problem solving, and are also efficient planners [194]. They are also more likely to reflect and
check errors in their thinking. Expert programmers have the habit of breaking down the problems
into minor sub-problems [205].
Problem solvers with higher cognitive flexibility [206] and cognitive complexity can consider
more alternatives, and hence, are better experts. The epistemological beliefs of the problem
solvers about the nature of problem solving also affect their natural ways of approaching the
problems. The stages of cognitive development discussed later in Section 6.1 effect these beliefs.
Pedagogic Implications
Jonassen [193] and Linda S. Gottfredson [207] have consolidated earlier research on problem
solving and highlighted the distinctions between academic and practical problems. These
differences are given in Table 4.8.
120
Table 4.8: A Comparison of typical academic and real life problems
Academic Problems Real life practical problems
1. Tend to be formulated by other people
2. Well-defined or well-structured
3. Tend to be complete. Presented with all the
parameters and constraints. Usually consist of
a well-defined initial state, a known goal state,
and a constrained set of logical operators.
4. Typically posses only a single answer
5. Tend to encourage single method of obtaining
a correct answer
6. Require application of a finite number of
concepts, rules, and principles
7. Divorced from ordinary experience
8. Tend to be of little or no intrinsic interest
1 Require (re)formulation.
2 Ill-defined or ill-structured
3 Require information seeking. One or more elements of the
ill-defined problem are unknown or not known with
certainty. The goals of real-life practical problems are
usually vaguely defined with unstated constraints.
4 Usually possess multiple acceptable solutions.
5 Allow multiple paths to solution.
6 Present uncertainty about useful and usable concepts, rules,
and principles as well. Further, in case of ill-defined
problems, the relationships between concepts, rules, and
principles may be inconsistent between cases.
7 Embedded in and require prior experience. This requires the
problem solver of ill-structured problem to distinguish
important from irrelevant, and construct a problem space for
generating solutions.
8 Require motivation and personal involvement
Real-life ill-defined problems are not constrained by the content domain, may require the
integration of several content domains, their solutions are not predictable or convergent, possess
multiple criteria for evaluating solutions, and no explicit means for determining appropriate
action. They require the solver to express personal opinion or belief, make judgments, and also
defend them. Earlier it was believed that experiences with well-defined problem solving easily
transferred to solving ill-defined problems. However, research in problem solving has
demonstrated that performance on well-defined problems is not correlated with performance on
ill-defined problems.
In our recently concluded survey, “Software developers - (How) Did your college help you in
your development?” (Table A10.2 (i) part-II, Appendix A10), a large fraction felt that as
compared to all other kind of academic engagements, their student projects (78%) did much
better to develop their problem solving skills. This was followed by laboratory work (59%),
thinking oriented lectures (51%), discussions with other students (49%), homework (37%),
research literature survey (36% each), industrial training (33%), and discussions with faculty
(31%). Discussions with others and traditional knowledge transmission oriented lectures were
found to be least effective in this regard by the respondents.
121
Complex Problem Solving Techniques
Literature on ill-defined problem solving offers some excellent general purpose techniques that
have been used in various professions, especially management and design. These techniques
essentially help in analysis of complex ill-defined problems. Some of these techniques are given
in Table 4.9.
Table 4.9: Some techniques for solving complex ill-defined problems
1. Flow charts (understanding how a process works)
2. Concept mapping
3. Systems diagrams (understanding the way factors affect one-another)
4. SWOT (Strength, Weakness, Opportunity, and Threat) analysis
5. Appreciation (extracting maximum information from facts by repeatedly asking ‘so what?’)
6. 5 Why’s (asking "Why?" five times, successively, to understand the ultimate root cause),
7. Cause and effect diagram (identifying possible causes of problems)
8. Affinity diagrams (organizing ideas into common themes)
9. Appreciative inquiry – 4D approach (solving problems by looking at what's going right in four
phases of problem solving: Discovery, Dream, Design, and Deliver)
Many of these techniques, especially, flow chart, system diagram, 5 why’s, and cause and effect
diagram are already being used by many software developers in the industry. Flow chart and
systems diagrams are already being used in some computing courses. Various kinds of
conceptual modeling diagrams, especially UML diagrams are used by software designers.
Metzger [157] recommends the usage of Nassi-Shneiderman diagram and Warnier-Orr diagrams
for program design conception stage. Most of the other techniques in above list can also be very
effectively used by all software developers for various activities of software development.
Hence, computing students should be well exposed to these techniques through their curriculum.
Integration of these and some other similar techniques in software development education is on
our future agenda. Active engagement in our proposed framework of pedagogic engagements
incorporates using these techniques in various problem solving activities (ref: Table 8.5).
Further, they should also need to learn to adapt existing techniques, and if required, also develop
new techniques especially diagrammatic techniques.
Further, with reference to software development, analyzing and solving complex ill-defined
problems usually requires approaching problems and solution from a systems-level perspective.
The details of systems-level perspective are discussed in Section 6.3. Evolutionary nature of
software development also makes it necessary to continuous reflect upon the problem and iterate
122