Design: the key to writing and advising a one-draft thesis (2002) [pdf]
cs.tufts.edu
cs.tufts.edu
Very broadly speaking, there are two kinds of writers: those who just start writing and go where the writing takes you, and those who develop an outline first. In the case of the first set, it is vital to do a heavy editing pass or re-write iteration.
I don't think anyone tackles a thesis without some kind of outline, but I also doubt the universality of this advice. Some people need to explore their ideas before structuring them.
All that being said, this is full of good advice, such as:
"When you write for them (the audience), you put forth effort to make your product good: neat, complete, proffed (sic), unified, cogent, etc. That is, you craft and polish a well designed product for them to read. However, if you [yourself] are the audience such effort is a waste."
The purpose of writing is to communicate. If "communicating your idea" is all you wanted to do, you could just release an outline or slide deck. Good writing makes your communication more effective, while also being more enjoyable (read: ergonomic, tailor-made, whatever your goal is) for the reader.
It's almost unimaginable to write a (PhD) thesis in computer science without an extremely detailed outline. The thesis is not some thing you come up with whole-cloth, and it is certainly not a substantial dump of novel work.
The CS PhD thesis is typically a function of between three and 10+ previously published & peer reviewed papers. The exact function used to combine these previous publications into a thesis can range from `concat` (the "big stapler" thesis) to a substantial rewriting.
The level of rewriting depends on many factors, e.g., the advisor's style, the norms in the department/country, the quality of previous published papers, and of course pedestrian things such as the student's promised start date for their first post-graduation position and/or the amount remaining grant money.
But in any case, there's going to be a rather small design space in terms of the overall high level outline. The choice of chapters -- and even the internal organization of those chapters -- will mostly match previously published work.
In some sense, CS theses are closer to an anthology than a book. There's a bit of design work you can do around the edges to make things into a coherent whole, but you're not going to be making substantial modifications to the meat of the thing.
After some false starts, I have come up with a system of designing my thesis very closely to what the author is describing here. I call sketching “free writing,” and while I often design down to the topic sentence, I don’t do this for every single paragraph. But other than that my method is uncannily similar to what is described here.
I also tend to think of paragraphs as “functions.” What are the parameters? I.e, what does the reader need to know for this paragraph to make sense, and how do I trigger those concepts. And secondly, what is the output? I.e., what is the one thing I want the reader to take from this paragraph? (...well some of my paragraphs return tuples, but that’s not ideal)