Peter Naur was probably the first to realize that “computing is a human activity” and that as we program, we are not only solving problems, we are also only just beginning to understand them.
This even affects small projects like student theses. For engineering theses, i.e. theses in which some artifact is to be built, we often start with only a rough sketch of requirements and expect the student to complete them. Hence, work proceeds in cycles of planning, developing, and learning. Only at the end will the requirements have become clear.
Thus, a student should clearly separate the process from the results. Each process iteration brings new results, both in the form of better requirements, better solutions to these requirements, and new learning how better may yet not be good enough. In their final written or oral thesis presentation, a student should therefore present the results of their last iteration, including the last requirements, last solution, and final learnings.
Unless it is a meta-thesis about the evolution of the work, the initial requirements and how long a way they have come are not of interest to me. This is sometimes hard for a student to swallow, because they may have been brought up on credit for effort rather than credit for results. However, life only rewards results and for better or worse, that’s what counts.
As to recognizing the work that went into a thesis, a student doesn’t have to worry. A good professor can recognize that even if they are not presented with each and every twist along the way.
Leave a Reply