Thursday 30 June 2011

Advice to PhD students #1: know your customer

One week ago, on Thursday 23rd of June, I submitted my PhD thesis. By now, any current PhD students would have thoroughly scoured the Internet in search of comforting advice about the long and hard road to a doctoral degree, so my own advice may not be entirely original. However, I felt that there were a number of things that I had learned. I'll roll them out over a series of posts. This advice is primarily aimed at computer science doctoral students, but it could possibly be applied to other fields as well.

My first piece of advice is this: know your customer.

So, as a doctoral student, who is your customer? Fundamentally, your customer is your supervisor and thesis committee for the duration of your research, and your internal and external examiners afterwards. By the same logic, your customers are also the reviewers of any conferences and journals that you submit your work to. Institutions vary, but there is an important point that comes from this observation: your achievements and progress will be judged by words on paper, not by what is on your computer screen.

This can come as a surprise, especially to doctoral students who have spent a lot of time in industry beforehand. As a doctoral student, you are not creating a software product. There is no software deliverable. Instead, the software you write is merely a tool for performing experiments and getting results. This way of thinking is not always apparent, and I have seen many doctoral students spend a lot of their time trying to make an implementation perfect, trying to make it run more and more efficiently, and continuing to add new tweaks and features that would certainly impress an end user. But there is no end user.

Most, if not all, computer science doctoral students will have to write code while working on their thesis. However, how much code you write can be controlled if you have your priorities straight before starting. The following points should be considered:
  1. How will this piece of software help my research? Is creating this software essential for me to obtain the results I want?
  2. How much of this code has been written before? Are there existing libraries or software tools that do a lot of the grunt work for me? 
  3. Am I tied to any particular language? If not, which language will get the job done most quickly? 
  4. What is the bare-minimum interface to this software? Can I get away with command-line input and output?
  5. How long am I willing to spend attempting this implementation before I reconsider other avenues?
During my own thesis, I had to write a lot of code. Most of it was in C++. I don't really enjoy writing in C++ all that much. Like everyone else, I get tired as the day goes on, and the sloppier my coding gets, the more segmentation faults I have to deal with. With the complexity of the algorithms that I was implementing, debugging often became a nightmare. Often I would wake up in the morning in a stink knowing that I had an entire day of complicated debugging ahead. 

Now, why was I writing in C++? Originally, I was writing in C++ because I thought that I was going to eventually incorporate my code as optimisation passes inside the LLVM compiler, and this is also written in C++. However, by the end of my thesis, I was generating LLVM bitcode (a text representation) as output, and then using this in order to generate code. The short story is that I could have used any programming language at all in order to do this. I didn't need C++ at all. The slightly longer story is that my stubbornness prevented me from rectifying this much earlier on, and then starting again using Java or Python, or something similarly more programmer-friendly than C++. I wasted a lot of time debugging memory errors that I could have avoided completely if I had used a different language. My stubbornness also made me create my own graph libraries from scratch, rather than using the excellent graph libraries that come with Boost, or similar. 

From my customer's perspective, they don't care how I created my software, or how long it took. They probably won't ever use the software at all. Their interest is in the results that came from my work, and these are written on paper in my thesis. So don't be like me. Save yourself as much time as possible when it comes to implementation. Write good quality software that does as little as is required to demonstrate your ideas and the subsequent results, and make sure it can be expanded upon in the future if needs be. But, if you're sitting there wondering what the best colour is for your GUI, or whether the command line output could be spaced more nicely, then you're not actually doing research - which is what you're meant to be doing. 

3 comments:

  1. Amen. I couldnt agree anymore. From my experience, with the submission of source code or executables, reviewers/examiners/supervisors will always choose pages upon pages of explanatory text and figures over having to download and setup your implementation. No matter how simple it is. Not that I mind though. My prototype was not the most "handsome" of the bunch :)

    ReplyDelete
  2. That last paragraph is a profound kick up the arse, with an analogy that can definitely be applied in any discipline. I'm thinking about printing it out and sticking it on my wall as some sort of mantra!

    ReplyDelete
  3. Hi there, awesome site. I thought the topics you posted on were very interesting.
    I tried to add your RSS to my feed reader and it a few. take a look at it, hopefully I can add you and follow.


    Know Your Customer

    ReplyDelete