In K-12, the difference was always distinguishable.
In college, that difference was no longer clear. In a quarter system where “midterms” happen every week for four out of a total of ten weeks, it was one of many terms that no longer made sense from their old definitions and environments.
Projects used to be a big deal, something that would happen once or twice a year, and took up a significant portion of your grade. Now, in a non-insignificant proportion of classes, it seems like it’s just an arbitrary decision that assignments are called projects rather than homework. Projects also used to be fairly open ended, everyone’s favorite examples being something along the lines of gluing macaroni onto popsicle sticks and decorating them with glitter. They were, so long as you did them, essentially free points, as you can’t be criticized for something open-ended. That went away too, when projects were suddenly gradable on a various number of items. So what’s the bother? Are they now simply called projects the same reason why many minimum-wagers are called “sales associates”?
I have found at least one legitimate reason why they are different.
This past quarter I took a class in Space Mission Design. The first half was subsystems focus, and the second half was constructing a preliminary design. For various reasons I signed up to be on the Mission Concept/Manager team, which for the first half would actually design the mission and then for the second half, formulate the architecture of a mission that would fulfill those requirements. This sounds like an open and shut thing, “design something simple, and then you already know what goes into it so that’s that”.
The only part that was as simple as you’d think was the initial research. The professor told us was what the topic of the mission had to be about, and what he wanted to see from us by the end of the quarter – that was it. Researching was just starting at google and wikipedia and going wherever the links or interesting phrases took us. Actually designing the mission was a pain, and not because the designing was hard. From the standpoint of a fourth year undergraduate engineering student who’s only ever done assignments based on theories or equations from textbooks, having an idea of even what kind of scale would be reasonable or acceptable for a space mission in general, much less a scale for a space mission for a fourth year undergraduate class is a completely different kind of problem.
What makes something reasonable? What makes something unreasonable? Why should the mission have these kinds of requirements, rather than something else? Largely, the research did not help us narrow down any options at all. Certainly the laws of physics and bounds of 2013 engineering have constraints, but that’s still a very vast solution space. We know certain things we need to have in our mission, but it was a list of 10 or 12 things long. At most we’ve been trained to think about things in 3 variables and 3 equations so there’s a single solution by the end, but we can’t hold 10 variables in our head and couldn’t determine any sort of 10 equations to either write down or code into a computer. How do we start?
Where do we start?
What the mission concept team turned in at the end resulted from one idea thought up arbitrarily and iterated two or three times total. One member had a random idea, and the rest of us noted that certain things had to happen, so he added more detail and changed a couple of things around so everything would seem more cohesive… and that was that. The mission requirements we came up with were barely if at all informed by any of the classes we’ve taken from whatever prestigious professors under this accreditation by some prestigious organization in our four years at our supposedly prestigious university. There was a total of two instances in which we used equations in those four weeks, and the important thing was not so much that we knew what equation it was or were able to use our calculators correctly, but that we knew that the mission should have those parameters. In other words, we were aware that the problem existed, and what order of magnitude it was on, +/- 1. The other 10 things were all from the research we did ourselves those four weeks. We didn’t know how important which one was, we had no experience – and this was a field where no one had done a mission yet. None of us liked the fact that we didn’t know really what was going on or what should happen. That one idea that one member came up with was the only one that we had though, and survived any kind of question we were able to articulate, so we had to run with it.
This problem did not simplify in the second half.
Now that I was a mission manager, I had to organize and put together the subsystems that’d go into whatever my new team thought would be the best idea to complete the mission specs by. I had some idea of what I wanted, but nowhere near the accuracy I’d need to put together what we needed to have in five weeks. We had to have numbers for power, mass, and volume, and specific choices for most of our components i.e. which solar panel made by which company has how much lifetime and power supply under what conditions, etc. Each item only has six or so variables to worry about (power, mass, volume, feasibility, robustness, primary criterion for that part), but this is impossible to visualize all at once even if you only have twenty different components on your spacecraft. A hundred and twenty interacting variables? Good luck doing that by hand, and even better luck to you if you want to code that into a program with any sort of accuracy. What program would you even use? How would you do it? This isn’t as simple as a 120×120 matrix and then doing RREF, a wattage requirement and a feasibility assessment aren’t stuff which have an international standard converter for units inbetween them.
The solution, however, was the same as the first half.
Pick one thing, then run it through all the hoops.
If it doesn’t survive, change the part that looks like the problem.
If that seems like too much work, go back to the first step and pick something else.
Repeat until it can survive all the hoops.
“But it can’t possibly be that simple”?
There’s no magic to it. The only differences between someone who hasn’t taken any engineering and someone who’s able to complete a class like this is 1) a sense of scale, 2) knowing what to look for, and 3) persistence. This is true in general. The difference between an artist and a non-artist, for example, is that one 1) knows what scale of piece can be produced given whatever relevant constraints, 2) the abilities and resources currently available and where to obtain or search for more, and 3) the first stroke. Paintings are not magic; just go to youtube and type in “speedpaint”. Buildings are not magic, again look up timelapses of skyscraper construction. Resources and knowledge are the separators, not some sort of unobtainable thought process that is magically bestowed upon you after some class.
The third is the difference between a “homework” and a “project”.
In “homework”, you know that the lesson this past week or lesson was from whatever chapter for whatever theory, meaning that your homework must be under that domain and the questions are designed so that simply having that theory in mind will result in fairly clear-cut answers.
In “projects”, you have to guess what theories apply, and how those theories interact with each other. Not “figure out”. Guess.
Perhaps some of the other things you’ll figure out later, but how do you figure out anything at the start? “Figuring” is the colloquial term for “solving”, and in mathematical terms that means “determining a single solution”. In other words, there are no degrees of freedom left. When you first approach a project, or more broadly, a problem, all you know is that something is bugging you. How it’s bugging you may or may not be clear. How you go about solving that is definitely not clear in the slightest. How do you start it?
“How do you start it?” is not a valid question. “How” is a method, a style, an error-correction or editing mechanism. In spacecraft, “How” would Guidance/Navigation/Control. “Start” is a concept of a different sort. In spacecraft, “Start” would be filed under Propulsion, specifically under the ignition mechanism. There is no GNC in the ignition, just as much as steering wheels don’t affect spark plugs, or your keyboard affecting your power supply’s on-off button. It is also an incorrect question because the assumption is that you only start once. Who said you’ll finish it all perfectly and completely in one go? Does your car engine always start on the first spark?
Projects require you to project, and the very idea of projecting a smaller object into a larger space should even to the least physics-inclined mind be obvious that it’ll be impossible to fill it all completely and that’s that. Maybe there are errors in the expansion, maybe there are anomalies in the space, maybe something broke and didn’t work. These are all potential problems. Maybe they don’t occur and you’re lucky, but they are potential problems.
The best thing you can do is “just do it“, and take it as fast as you can – namely, one at a time. No point in worrying about “if you could”; you can’t. If there are no solid absolute rules to begin with, you must make them up, because you must start. Deride them for being “assumptions” later, and justify them after that. Deny even the first starting point and you fall into the abyss.
Homework you can do or envision all at once, at least per problem. This is because you are told to accept a large number of thing as true, with only a handful of degrees of freedom to worry about – more often than not, only one. Projects, you cannot.
Life and real problems, you cannot.
A godfather of the modern study of problem solving is economist and polymath Herbert Simon (1916-2001). Simon, recipient of the 1978 Nobel prize in economics, spent most of his career at Carnegie Mellon University, a school with strong computer and robotics programs. He was one of the many economists of his day making use of computer models.
Simon was so taken with the computer that he examined how people solve problems as a means of exploring how computers might be programmed for similar tasks. In Human Problem Solving (1972), Simon and colleague Alan Newell published results of studies in which volunteers performed a variety of number or word puzzles. A later publication, Scientific Discovery (1987), attempted to reconstruct, through historic accounts, the individual reasoning behind a number of celebrated scientific breakthroughs.
In both humble puzzle solving and great scientific advances, Simon found nothing fundamentally mysterious. People parlayed justifiable hunches into testable hypotheses, negotiated a few false turns, and ultimately arrived at a “right answer”. Never did a puzzle’s solution or a scientific advance depend on a totally out-of-left-field “inspiration.”
Simon and colleagues popularized a number of terms that are now in wide use. One is “solution space.” This means roughly the set of all potential solutions to a problem. When a computer program plays chess, it “searches a solution space.” It examines all possible moves (and countermoves, and counter-countermoves, as far ahead as is practical) in order to find the most advantageous ones.
Simon believed that searching a solution space was a model for how people solve puzzles or even how scientists such as Kepler and Planck achieved great breakthroughs. The notion of a solution space has been hugeely influential. When you are trying to program a computer to solve a problem, identifying a solution space is extremely desirable. Then the software can search the set of solutions, using the impressive speed advantages that computers have.
There are a number of limitations to this approach. Many problems have solution spaces that are too astronomically large for even the fastest computers to run a brute-force search. (Computers can’t play “perfect” chess for this reason, even though they can beat human grand masters.) Equally vexing is the possibility that the solution space may be ahrd to define and/or irrelevant. Solution spaces often seem to have little to do with the way that people actually solve problems.
“Which way should a key turn in a car door?” In a narrow sense, you might say the solution space consists of two possible answers: “clockwise” and “counterclockwise.” That’s missing the spirit of this question. Microsoft’s little riddle is really asking you to give a good reason for your answer. The number of possible reasons for turning a key clockwise or counterclockwise is bigger than two! It’s more realistic to say that the ensemble of possible reasons is the real solution space (and this ensemble defies accounting).
In general, puzzles and riddles have solution spaces that are difficult to define. It is not immediately clear what the scope of the problem is or what types of solutions might be legitimate, much less right. This is what makes AI such a formidably difficult enterprise. On a much more modest level, it is what makes certain questions so difficult to answer in job interviews.
Much recent work in cognitive psychology has pulled back from Simon’s optimistic view of rational problem solving. Some recent analyses send the message that no one knows how to solve a problem until he or she solves it. In contrast to Simon’s solution space, Harvard psychologist David Perkins speaks of a “clueless plateau.” If the space of possible solutions is a landscape, and the right solution is somewhere on a big plateau over there, then you’ve got to search the whole plateau (and are clueless about where to start).
Perkins likens the solvers of puzzles to prospectors looking for gold in the Klondike. There is not much rhyme or reason to where the gold is. You might say that prospecting is pure luck (“the luck of the Klondike”). At a deeper level of analysis, some prospectors are better at finding gold than others. That is because they accept the “randomness” and deal with it. Their search for gold is not random, it is a methodical survey in which they are sensitive to such geologic clues as do exist.
This view of problem solving is neatly captured in Microsoft’s weird puzzle (or antipuzzle?) that asks how you would find a book in a library. Zen master Shin’ichi Hisamatsu said that all koans (Zen riddles) really boil down to “Nothing will do. What do you do?” This is Microsoft’s version of that. There’s no way of locating a book – how do you locate the book? People are baffled, not because this is a hard question but because it offers so little purchase to logic.
Obviously, the answer can’t be something such as “I’ve memorized the Dewey decimal system, and the book is on the nineteenth shelf, three aisles over to the left.” You haven’t been told what the book is, the library may or may not use the Dewey decimal system, and even if it did, the books could be laid out any which way on a floor plan that could be anything. There is no way of deducing the book’s location, ALl you can do is “search the solution space” – the library itself – as efficiently as possible.
- p.92 – 94, William Poundstone, “How Would You Move Mount Fuji?”
There has to be an answer. You must not doubt that.
If you can’t believe that, why don’t you cry yourself to sleep, and then just give up and die?
- Eva Ushiromiya, Umineko no Naku Koro Ni: End of the Golden Witch