What Is a Model?

A model is a simplified, abstracted representation of an object or system that presents only the information needed by its user. For example, the plastic models of aircraft I built as a kid abstract away everything except the external appearance, a mathematical model of a system shows only those dimensions and relationships useful to the model's users, a control system is a model of the relationships between the stimuli and the response desired by the designer and user of the larger system being controlled (evolution as designer and organism as user in biological analogy). A control system doesn't make a model of a system, to a large degree it is the designers' model of the system it controls.

At the simplest end are one-dimensional models, that we call measurements.

The most complex models are not explicit, they are too complex to be explicitly known, much less communicated; the model of the world that each person carries within his own mind.

The Relationship of Software Engineering, Computer Science, and Programming

Computer science underlies programming rather like physics underlies engineering. You can do some programming or practical engineering with rules of thumb and copying from references, but they will ony take you so far.

What is needed for software engineering to become a reality, rather than a glorified name for programming, is a set of reliable principles for designing and building effective software, that is software that works as expected. Prototyping is the currently most effective way of building software, but it is not software engineering; it is an admission that there is not yet a discipline of software engineering.

From what I have read, even the large scale, high reliability programs are built more by careful programming, testing, and debugging than by detailed up-front design, the way large scale engineering projects are.

The main reason is the incredible complexity of software projects. The only physical products that approach software in complexity are large scale integrated circuits.

Software engineering will be an engineering discipline when the development of a new operating system, the associated utilities, and APIs is as predictable and stable as the design and construction of a new skyscraper.

This is all from general reading and memory, if you agree or disagree with me, please leave links to any sources you may have in comments.

Trial and Error Problem Solving

The most basic requirement of successful use of trial and error is all too often forgotten - you must keep track of what you have tried.

Systemic trial and error is based on a mutually exclusive and exhaustive listing of all possible solutions. In many real world problems this isn't possible, but it works in some areas such as mathematics and some areas of engineering. Even just attempting an exhaustive listing of solutions can help you find possible solutions that you may have overlooked otherwise, even if a truly exhausitve listing is not possible.

General Method of Problem Solving

1. Become conscious of problem
Identify opportunities to improve situation.
Identify opportunities for innovation.

2. Recognize and define problem.

3. Define the goal.

4. Search for and develop alternative solutions.
Explore possible strategies for achieving goals.
Formulate hypotheses.

5. Select alternative solution or strategies. Anticipate the precise outcome. Choose the hypothesis to test.

6. Implement solution or strategy. Act on it. Commit through action. Test the hypothesis (do the experiment).

7. Gain feedback and compare to anticipated outcome. Refine the solution.


Trying too hard to avoid complications often creates them.

When in total ignorance, try anything, at the least you will learn something that doesn't work. And watching how it fails should teach you a lot more than that. Seeing to what extent it looked like it could work before it finally failed should reveal interesting data also.

Edited to Add References: I was in a hurry yesterday when I posted the above and didn't have time to lokk these up in Amazon.

The greatest source for the above is The Ideal Problem Solver: A Guide to Improving Thinking, Learning, and Creativity by John D Bransford and Barry S Stein. The IDEAL in the title is an acronym for a five-step process, similar to the 7 steps I listed above.

Next was Wayne A Wickelgren's How to Solve Mathematical Problems, the most complete view of problem solving techniques and heuristics I have seen. Some of the techniques don't work well on less well defined types of problems, but most do.

Polya's How to Solve It: A New Aspect of Mathematical Method (Princeton Science Library) had a significant impact when I read it, but that was more than 15 years ago. I strongly recommend this to anyone interested in math or general problem solving, before reading Wickelgren's book.

Two more books that made a significant impression on me at the time I read them, but that I didn't actually refer to for this are Thinking Better by David Lewis and James Greene and an earlier edition of Problem Solving & Comprehension.

I am currently reading Thinking and Deciding by Jonathan Baron. It is a more difficult read, and more psychologically oriented than the others. The author's claim that effectively all thinking, deciding, problem solving, creativity are a combination of search and selection is interesting and looks very useful.