A good thesis in Software Design and Software Engineering builds an innovative artifact, evalutes it with users and reports on it. A few good examples here are:
In recent years 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.