PhD Subject in Computer Science?

Having written about how to complete your PhD (and for the balance - how to not) I still haven't touched the core which is the research subject, but here is a try.

Computer Science Research
Computer Science has a large menu with exotic sub-disciplines where many are indistinguishable from magic for most people. Several of these disciplines are hybrid, i.e. crossover with other fields (e.g. bioinformatics and environmental informatics). It also has crossover with itself, e.g. the diff between Computer Engineering and Computer Science is rather blurry (and maybe culturally dependent?), so for the sake of simplicity I will treat them as synonyms.
Research is described as "a human activity based on intellectual investigation and aimed at discovering, interpreting, and revising human knowledge on different aspects of the world. Research can use the scientific method" (Source: Wikipedia). Should you use the scientific method when doing computer science research? That is left as deductive exercise for the reader, i.e. deduction of combining "Computer Science" and "Research" in the same phrase. (hint: the answer is yes).

Purpose(Computer Science) == Automation
In my opinion the sole purpose of Computer Science is efficient automation, please don't forget that (many tend to do, even many experienced people in the field).

Why you should go back to the basics
Even though there are plenty of exotic CS sub-disciplines, one stands out as the clearly most important one, and that is software engineering (SE), which is roughly about how to create software and tools/languages supporting it. And software can make users more productive, i.e. have a multiplier effect. My guess is that few world-scale problems (e.g. related to climate) can't benefit from software, and the same goes for the long tail of problems to person-level scale.

Multiplying the multipliers
.. Now you're getting overly vague.

Thanks for reminding me, the only point I want to make is that software is extremely important :). And since software has a multiplicative effect that few other technologies can beat (e.g. 1 persons code can effect a large amount of users in a positive way), making software engineers more productive can have a massive impact on society

What to do research on in Software Engineering?
I've added some personal hypothesis to get you started.

• Hypothesis 1: The effect of (modern) development methods and processes (e.g. agile methods such as scrum) is to a large degree still unknown, and there has been done too few sufficiently realistic and large scale experiments to estimate the effect of them.

• Hypothesis 2: Test-Driven Development (TDD), and its siblings {Behavior, Domain, API} Driven Development is a step in the right direction, but needs more automation.

• Hypothesis 3: Software testing today is to a large degree a manual process (e.g. writing unit tests), that probably won't be the case in the future. Machine learning and statistics will be used ensure that.

• Hypothesis 4: Refactoring of code is today a manual process, that probably won't be the case in the future. (e.g. extract method is basically about finding the start line and end line, extract method between those lines and rename it. Automatic method naming is probably the hardest problem to solve). Machine learning, heuristics and statistics will be used to ensure that.

• Hypothesis 5: How to deal with large amounts of code is still unsolved.

• Hypothesis 6: Code metrics has a future, but which one is yet to be discovered.

• Hypothesis 7: Duplicate detection in code can be significantly improved. Current tools typically use simple syntactic approaches, they don't even do unification of names (variables and methods) or trying to rewrite the code. If you write a short-to-medium length method, chances are high that it has a clone somewhere else at least if you unify methods, and that clone might even have unit tests => productivity increase.

• Hypothesis 8: Given a sufficiently good compiler or runtime environment technology any programming language can perform well. (If it doesn't perform well then the compiler or runtime environment isn't sufficiently good enough :)

• Hypothesis 9: Domain-specific languages will flourish, but there are room for more tools supporting it.

• Hypothesis 10: Current programming languages doesn't sufficiently deal with concurrent programming (e.g. to utilize multicore and grid/cloud/web service systems) from a developer point of view. Some claim that threads are a bad idea (for most purposes). Concurrency is crucial and beneficiary in general, but the annual cost of errors in concurrent software systems in the world is not a small amount.
  

• Hypothesis 11: Abstractions currently used to represent entities in distributed programming can be improved, e.g. the master-slave/client abstraction implies that the master controls the slave, but in a distributed environment that isn't really the case. Alternatives are needed, and Agent-Oriented Software Engineering (AOSE) can be one of them, but it still needs more industry influence. A related abstraction - Mobile Agents - deals with the issue that code is less that the data, so that code should move to the data, not vice versa. The choice of abstraction also affects the complexity of reliability model.
  

• Hypothesis 12: Legacy code is still written every day (and will be for a while), and dealing with it is still largely unsolved.

How to not (or barely) complete your PhD

For the few of you who would like to decrease your chances of completing your PhD in Computer Science, here are some non-recommended suggestions:

1. Code too much
• in particular extremely polished and nice-to-have-features, can be fun, but time (and funding) flies.
  
2. Write too much
• writing is in general good, but there got to be some substance behind it and in my opinion either empirical support or proofs.
  
3. Teach and tutor too much
• Pros: Your students will love you and you will learn a lot about teaching. Cons: Your advisor or PhD committee might not. Thought about doing teaching instead of research?
  
4. Not write papers
• Paper collections has become alternative to monograph thesis in several countries, but if you are defending not writing papers because you are aiming for a monograph chances are quite good you won't make it.
  
5. Being too focused
• Being too focused prunes away a lot (which can be good), but sometimes you get ideas of fields that are slightly different from what you are researching, and if you aren't exposed to such fields you may be loosing important input.
  
6. Being too unfocused
• Is never a great idea, but you might learn a lot of other stuff (e.g. getting involved in system administration at university level can be useful).
  
7. Have an obsolete research subject
   
• Several research fields in CS can be considered retro, this can cause problems when trying to publish papers, what are the primary events and research communities?
• The field might be exhaustively studied, and can be extremely hard to contribute to.
  
8. Have a boring research subject
• If you think it is boring, chances are that most reviewers will think it at least as boring as you do, and reject all of your papers.
  
9. Do a startup
• I don't necessarily think that doing a startup is a bad idea (why? left as an exercise for the reader, you might actually end up with honorable doctorates instead, and that is probably at least as good, but different and less probable), but for PhD productivity it might not be the greatest idea.
  
10. Never finish anything
    
• If you mainly have started-on-but-never-at-submittable-quality papers chances are your thesis will be of similar quality.
  
11. Have an advisor that doesn't publish actively or interact with research community
    
• I personally believe if your advisor doesn't publish actively, chances are higher that you won't either. Choose your advisor with care.
  
12. Read too much
    
• I have seen people who have an exhaustive-read-approach to PhD, e.g. attitudes like "I have to read all the references of this seminal survey paper". It usually didn't serve them well (in particular if they use this rule recursively..). Reading is good, but it has to be targeted, and doing something is better than only reading.

Disclaimer: This approach isn't recommended, but if recognize some of the above approaches as yours, then you should perhaps consider reading this.

How to complete your PhD

Shane Lindsay writes about how to complete your PhD (or any large project) which is to use hard deadlines (externally determined), soft deadlines (your own) and the Martini method (write at least X words per day, e.g. between 500 and 1000)

My take on how to complete a PhD (in Computer Science):

1. Learn and use a version control system for everything you do (code, datasets, text etc.)
   
• Useful for backup
• Useful for versioning
2. Learn statistics and experimental method (e.g. factorial design)
   
• Universally useful, and makes you critical to what you read
  
• T-tests seems to popular in CS-papers :)
• Prefer confidence intervals over "significantly different" and p-values
  
• Be aware that the difference between significant and not significant is not statistically significant :)
  
• It isn't embarrassing to read the cartoon guide to statistics!
3. Learn scientific writing, take a course!
• Always, and I do mean always support your claims when writing (e.g. with references proofs, empirical support or good rhetoric writing). Consider dangling claims in papers as paper-eating bugs, if you don't feed them with support they will eat your paper. And argumenting why the research you are presenting is important doesn't hurt.
  
4. Submit papers early and often (to conferences, workshops and journals)
   
• The likelihood that external reviewers provide complementary input on your work compared to your advisor and grad student colleagues is probably significantly close to 100%
• Demand to be a "slave" co-author for your advisor on the first paper, e.g. do all ground work (experiments etc.), but you learn the skill of writing and review process.
• As my father advised me half-seriously: "even write on the toilet"
• Figure out the most important research events in your field
  
• Do at least 1 unlikely-to-get-accepted submission in order to get a reject early just to get heat. It is way better to get a reject (with explanation why it was rejected) from a great conference or journal the first year, than getting it for the first time from a medium quality conference a few months before you are going to defend your thesis.
  
5. Submit code early and often.
• Writing code keeps you sharpened. Spending several years developing some kind of framework, model or algorithm sketch (without any implementation) and then try to implement it in order to evaluate is likely to cause trouble. By then your coding skills are about as sharp as a spoon, and the model or whatever you are trying to evaluate with implementation is probably way too abstract and requires a lot of massage in order to be implementable. And if that isn't enough, you probably are about to run out of funding.
• You are way more marketable when you are finished than if you don't write code
  
• Learn at least 1 new language that is not too close to those you know during your PhD
• The fundamentals of Computer Science is still software (and hardware).
  
6. Least Publishable Unit papers are not bad because:
• It is like code, concise and and shorter methods that do one thing well are preferred over longer methods that try to a lot of stuff, don't get me started on testing.
  
7. Try to get involved in the research community as a reviewer (probably not the first year)
• You'll be surprised how unpolished submitted papers actually are, and how different the first submit and the final polished,.. eh published paper actually is.
8. Learn at least 1 drawing, 1 presentation, 1 word processor and 1 statistics tool
   
• Leslie Lamport knew what he was doing..
• Google Docs&spreadsheets for notes and calculations
9. Teach!
• Being thrown in front of hundreds of students with the expectancy that you are going to teach them something useful and interesting is an extremely valuable lesson (and quite scary too I must admit). And this can save your career if you forgot to code (read 5.) ;-)
  
10. Oh wait, create interesting MSc topics and get MSc students
• The payoff can be great (e.g. get you more productive by helping you concretize your ideas into code and get them to do experiements).
• There is usual an at least linear (probably exponential) relationship on the PhD relevant output you get and the input/support you provide the MSc students.
11. My experience is that "doers" are more likely to finish their PhD than "smarties".
    
• Thinking doesn't create your thesis, but writing might!
• Hopefully you are both a "doer" and a "smartie" :)

Hm, can't think of anything else, and no guarantees about that you will manage to complete your PhD if you follow these advice :)

Note: I don't think these approaches will help you complete any large project (as Shane Lindsay's recipe claims to), but it probably won't hurt either.