A good thesis in Software Design or Software Engineering builds an innovative artifact, evalutes it with users and reports on the lessons learned. The main scientific contribution are the lessons learned, and answering an important research question with the help of the artifact. Not the artifact itself. However, if you don’t build a sufficiently powerful artifact, then your study might be endandered.
When it comes to writing, I ask students to choose one of the two forms:
It is in recent years that I started offering students the chance to write shorter theses, but with more attention to detail.
This is because many of the students I see have no experience with scientific writing and allowing them to write a 60 pages thesis will very likely result in a document that has too many weaknesses. And because writing shorter forces you to think about what’s essential. Nobody needs to read filler text that can be written by ChatGPT.
Moreover, I believe that if you have something to say, that you can’t say in 10 pages, it’s unlikely that you’ll be able to say it in 40.
Finally, if we write a shorter report, there’s a higher chance that we can do a few iterations, and learn a little bit the art of scientific writing and of attention to detail.
There is one more reason actually. The software engineering students and the software design students often write theses where one builds a software artifact that they have to evaluate. So a good part of their work is in engineering. But they also have to evaluate. And they also have to write. Thus, something has got to give, and the extent of the report is a very good candidate of something that is not that important. The other one that one has to reduce is usually evaluation. It’s unlikely that they will have time to do a quantitative evaluation, so students will often do a qualitative evaluation of the artifact that they have created.