Problem Solving

1
Problem Solving

• A Critical Skill for the
• Construction Phase
• of Software Development

2
NOT Problem Solving for Dummies!

• This is a selective school training people for a
  demanding profession. The average SAT score for
  CIS undergrads is over 1400 out of 1600. The
  grad school is even tougher.
• If you think a tough decision is whether to have
  Pizza or a Hamburger for lunch, you are in the
  wrong profession.

3
American History - Incident 1

• During the American Revolution in 1776, the
  British invaded Boston. Paul Revere became a
  hero by riding out through the countryside and
  alerting the colonial militia that The British
  are coming!

4
American History - Incident 2

• During the war for Texas independence in 1846, a
  small band of about 150 Texans defended a fort
  called the Alamo against an army of 5,000
  Mexicans until every one of the Texans was
  killed. One of the American heroes of that
  battle was Davy Crockett.

5
Asking for Help

• A Texan was bragging about Davy Crockett and the
  Alamo when someone from Massachusetts said But
  you dont have anyone like Paul Revere.
• The Texan said You mean that guy who rode all
  over the countryside yelling for help? No we
  dont have anyone like that!
• Asking for help is a valuable skill.

6
Introduction

• This lecture will look briefly at
• Decision Making
• Problem Solving
• Process
• These are critical skills in software development
  that are often neglected in concept based courses.

7
Definition Decision Making

• Decision Making is choosing between alternative
  courses of action

8
Definition Problem Solving

• Problem Solving is identifying and correcting
  deviations between what you wanted to happen and
  what actually happened.
• In simple terms, it is explaining the difference
  between what you wanted and what you got.

9
Definition Process

• Process is approaching problems and tasks in a
  standardized way.
• Process is mainly about avoiding undesired
  outcomes. (Dont repeat your mistakes!)

10
Tying them together

• Unless we take pains to do every step differently
  every time, our software development methodology
  is a process. It may be a good process or a bad
  process.
• The key activity during requirements, analysis
  and design is decision making.
• The key activity during construction is problem
  solving. (This course is mostly construction.)

11
Why Decision Making?

• One of the skills that you will be expected to
  develop in this course is the selection of
  appropriate configurations and middleware for
  Client Server computing.
• Since you will have taken the course, you may be
  the logical person in your organization to make
  recommendations for a project.

12
Decision Making Process

• There is a best way to do decision making
• Define the question
• Identify Alternatives
• Evaluate Alternatives
• Select an Alternative
• Manage Risk
• Implement the Alternative

13
Define the question

• If you dont know where you are going, all roads
  are the same.
• The first step in Decision Making is clearly
  stating your goal, usually in a simple, clear
  sentence.
• This is usually called a Decision Statement

14
Identify Alternatives

• Once you know what you want to do, you have to
  think of ways to accomplish that. This may
  involve research, brainstorming, consultation
  with experts, sending out requests for proposals,
  looking at other projects or many other
  activities.
• You should continue to look for alternatives
  until you are sure that you have some good ones.

15
Evaluate Alternatives

• To evaluate alternatives, look at your Decision
  Statement. Then generate lists of
  characteristics that are necessary (Must Haves)
  and desirable (Wants) to meet your goals.
• Compare each of your alternatives against the
  lists of Musts and Wants.

16
Mandatory Characteristics

• If a decision alternative does not meet one of
  your Must Haves, it is not a valid alternative,
  and cannot be selected.
• For example, if your goal is to get a Master of
  Science degree from an accredited University,
  NJIT is a valid alternative. Joes Barber
  College is not a valid alternative. Eliminate it
  from your list.

17
Optional Characteristics

• Your decision alternative will meet different
  wants to different degrees. A good way to
  evaluate them is to rank your Wants from most
  important to least important, and score each
  alternative against each Want.
• You could assign weights to each Want and
  quantitatively evaluate each Alternative, or you
  could do it less formally.

18
Optional Characteristics (2)

• For example, my wife and I wanted to go somewhere
  during Spring break. We wanted to spend less than
  1000, and go somewhere we havent been before.
  I prefer to take my vacations in Europe.
• We found a fare of 500 for two people on
  Icelandair, and then had to choose between
  London, Rekyavik, Copenhagen, Stockholm and
  Amsterdam.

19
Select an Alternative

• Once you have eliminated alternatives that fail
  to meet one or more of your Musts, and rated
  the rest of your alternatives against your wants,
  you select the best alternative.
• My wife and I chose Copenhagen, because we
  havent been there, and it was a good choice for
  a short visit in early Spring.

20
Manage Risk

• Once you have a tentative decision, you make a
  potential problem analysis and ask what could go
  wrong. Based on this, you might decide to select
  a different alternative, or take steps to
  minimize the risks.
• For example, Copenhagen has a very high rate of
  property theft. We did not take any valuables.

21
Implement the Alternative

• Finally, you put the selected alternative into
  action, following your risk plan.
• My wife and I enjoyed our vacation in Copenhagen,
  but we left our best cameras behind.

22
Problem Solving

• Decision Making focuses on selecting an
  alternative before you do something. Problem
  Solving focuses on things that go wrong while you
  are doing something.
• Since problem solving is concerned with the
  difference between what you wanted and what you
  got, it concentrates on finding the deviation.
  This can be looked at graphically.

23
Deviation
You begin with a specific goal in mind
You get a different result
You find the deviation
You analyze and correct the deviation
24
Deviation Analysis

• To analyze a candidate defect, ask
• Does it explain the deviation?
• Does it explain the timing of the deviation?
• If the answer to either of these questions is NO,
  that is not the defect.
• If both answers are YES, that may be the defect.
• If either answer is UNKNOWN, investigate further.

25
Explain the full problem

• I cannot overstress the importance of asking if
  the candidate defect explains the whole problem.
  A partial explanation is not enough.
• As an example from this course, I had a problem
  with cheating on the final exam. Twenty students
  gave the identical wrong answer to a question.

26
The wrong answer

• ANT JBOSS SET DEFAULTTOMCAT5
• The above command was on all twenty answers
  although I neither asked for or expected any
  code. Note especially the first and last
  character, which are not part of the code.

27
A candidate answer

• Six students sent me emails claiming that they
  had been studying together and had gotten that
  answer from a friend of theirs in the class.
• That was a plausible reason for this part of the
  wrong answer
• ANT JBOSS SET DEFAULTTOMCAT5

28
Did not explain timing

• I did not accept that explanation because it did
  not fit the timing.
• If twenty students had (1) the wrong answer for
  JBoss using (2) wrong commands for ANT before the
  test, then someone who knew the right answer
  would have seen it and corrected them.
• An answer that bad had to be done during the test

29
Did not explain extra chars

• Also, if twenty students learned a command before
  the test, they would not all have put the shell
  prompt and carriage return symbol on their
  answers.
• Details like that could only come from a document
  that was passed during the test.

30
Did not explain full problem

• If six students studied together, that does not
  explain why twenty had the same answer. Never
  accept a partial solution.

31
The true story

• My grading assistant, who was helping me proctor
  the exam, was noticing which students had trouble
  and showed them a piece of paper that had the
  answer on it.
• Conclusive proof was that he was the only one who
  had access to give the answer to that many people
  during the exam.

32
Logging

• When I was writing business solutions (custom
  software), I always put a logging function in my
  my software, such as storing every procedure call
  with its parameters in a file. Sometimes I
  included the ability to turn this on or off, but
  it was always there. It was the most valuable
  support tool I had. That is how I found my
  deviations.

33
Defects

• Defects are not random Acts of God.
• Software defects are context sensitive. They
  usually occur when the machine is in a particular
  state and receives a specific request. Analysis
  of the timing can reveal the state and the
  request.
• The two questions help eliminate time wasted
  looking at things that are not defects.

34
Eliminate Defects

• Once you have a candidate defect that meets both
  criteria, correct that defect and determine
  whether that solves the problem. If it does not,
  repeat the process.
• Software engineers are notorious for hoping a
  problem will go away without making a change.

35
Brake Problem

• A Manager is driving a Software Engineer and a
  Hardware Engineer down a steep hill when the
  brakes fail. By steering the car off the road
  and up an embankment through some heavy brush,
  the Manager manages to get the car stopped
  without killing them.

36
Solutions

• The manager says One of us will have to go for
  help!

The Hardware Engineer crawls under the car and
says Let me check the brakes.
The Software Engineer says Lets get back in and
see if it happens again.
37
Relevance to this course

• Client/Server programming largely concentrates on
  the construction phase. The principal activity
  is problem solving. If you expect the examples
  in this course to go smoothly, you will not be
  prepared for the real world.

38
Documenting a Problem

• If you are going to answer the question, Does
  this potential defect explain the problem?, you
  are going to have to gather information. That is
  why I require so much documentation with your
  projects, and concentrate mainly on your
  environment and the problems encountered. It is
  also why I expect you to solve your problems.

39
The Nature of C/S Problems

• Problems during Client/Server development are
  usually either problems understanding the
  middleware or problems getting different
  components to work together. This ignores simple
  mistakes, which are also common. We all make
  stupid mistakes, which is why we invented code
  inspections, and why we work in teams.

40
Problems in Assignments

• Figuring out how to use compiler and link options
  and configure the environment and middleware is
  not an incidental obstacle to completing the
  assignments. It is the whole point of the
  assignments.
• Real world software development is more about
  problem solving than programming.

41
What if you cant do it?

• We are looking at many technologies in this
  course, and dont have the time to ensure that
  everyone has success in every environment on
  every example.
• Document how far you got, and how you dealt with
  your problems, and you will get partial credit.
  Since there are several assignments, a few
  problems will have only a minor grade effect.

42
Specific Problem Solving Skills

• The problem solving skills required in the
  business world are deviation analysis,
  documenting and explaining defects, researching
  documentation, and consulting with colleagues to
  solve problems. We will practice all of them in
  this course.

43
Process

• If you make the same mistake frequently, there is
  a problem with your process. Dont just fix the
  problem fix the process.
• A managers main job is fixing processes.
• The following slide hung on the wall of my
  office

44
Fix the ProblemThen Fix the ProcessDont Fix
the Blame
45
A Simple Example

• A program that I use has a lot of dialog boxes.
  Some of them have positive answers on the right
  and negative ones on the left. Some are
  reversed. Some of them put positive answers in
  the middle.
• That is a bad process that guarantees frequent
  mistakes.

46
Reference

• Charles H. Kepner, The New Rational Manager,
  Princeton Research Press, 1981 ISBN 0936231017