Automated Software Engineering Research Group @NCSU

Friday Nov 07, 2008

How not to keep your advisor up all night till last minute before the paper submission deadline?

I recently had been through a case where a student submitted the student's draft for my review of writing two days before a submission deadline. Since I had another more urgent task during the period, the required effort for helping improve the draft to a fine shape "forced" me to stay up the whole night till early morning 5am the submission deadline.

When I tried to recall several past submissions of this student, I found that all these submissions kept me up all night in the morning till last minute before the deadline whereas many other students' drafts were often already ready to submit the night preceding the submission deadline.

I asked myself "why would this situation happen for the student?" For this immediately past submission, in fact the student did a very good job in preparing the abstract, introduction, and approach (high level description) sections early on (for my review of ideas). But the problem is that the student submitted the draft for my review of writing late, only two days before the submission deadline. Several possible reasons may contribute to this late submission: the student might think that the student needed to finish all the sections of writing before asking peer review for writing, or the peer reviewing student needed to finish peer review of all sections of the draft before asking for my review of writing, ...

To avoid these issues (or avoid keeping me up all night till last minute before the paper submission deadline), below is a new set of advice to my students:

Please write early, ask peer review early, and ask for my review of writing early!! Here are some specific things you should do:

(1). You don't need to wait till you have a complete draft (with all sections finished) before requesting peer review. You can submit your partial draft (e.g., one or more completed sections at a time) for peer review.

(2). You don't need to wait till your peer-reviewing student finishes reviewing all the sections of your draft before requesting my review of writing. You can submit your peer-reviewed partial draft (e.g., one or more peer-reviewed sections at a time) for my review of writing. Remind you that I have a policy of being able to review your draft for writing ONLY after a peer student has finished reviewing the writing of your draft and you have fixed the issues pointed out by the peer student. But you don't need to get your peer review done before I can review your draft for the ideas described in the draft to avoid the delay on giving you feedback on the ideas in your draft.

(3). Budget your timeline to allow to ask me to review your writing for multiple iterations (instead of just one time or even 0 time iteration on any portion your writing before the submission).

Of course, it is most important for you to write early following my advice posted earlier!

Sunday Oct 19, 2008

On writing weekly lab book entries

Every week before the one-on-one meeting (if no regular one-on-one meeting arranged, then on a weekly base), a student should submit a lab book entry in our group wiki http://sites.google.com/a/ncsu.edu/ncsu-ase/Home/Labbooks for
   *. Planned activities
   *. Actual outcomes

For the "Actual outcome" category, you basically copy the "Planned activities" from the preceding week and then annotate them with the actual outcomes.

For each category, you need to organize your items in the following subcategories:

*. Tool development
          Description of your task items
          Expected artifacts: (here you put only specific tool components, with the details of the location in CVS, e.g., the genAxim method of /toolsrc/jias/jias/axioms/

Axiom.java)

*. Empirical evaluation
          Description of your task items
          Expected artifacts:(here you put only the writing portions for describing the evaluation or its results, with the details of the location in CVS, e.g., the evaluation section of /papers/icsm08-soa/)

*. Paper writing
          Description of your task items
          Expected artifacts:(here you put only the writing portions, with the details of the location in CVS, e.g., the approach section of /papers/icsm08-soa/)

  *. Misc
          Other task items not falling into the three preceding categories

Your task item's description shall be detailed enough so that I can distinguish it from a previous item in previous weeks. For example, you shouldn't put the same item description like "Preparing a Journal Version of XXXX" in multiple weeks. That is, from your description, I can tell the semantic difference of your new task item from any of your previous items in previous weeks.

Note that only recognizable artifacts are tool source code and formal writing in LaTeX being put in CVS. The artifact description shall describe enough details for me to trace down to the artifacts without further asking you. If you cannot put an artifact for a task item in one of the first three categories, you shall move the task item to the "Misc" category. For example, "Explore various tools such as XXX to use in the tool development" shouldn't be put under "Tool development" since there is no artifact (tool source code) being produced by this task item. This task item shall be put under "Misc"; just like reading research papers, you should always explore various tools along the way of your actual tool development.

For the "Actual outcomes", you copy the "Planned activities" over and annotate each item with some description of the completed portion. You also need to list "Actual artifacts" after the "Expected artifacts".

If you don't produce any portion of an expected artifact, you need to put "None produced" and color that item with the red color. If you produce only partial portions of the expected artifact, color that item with the orange color.

Saturday Dec 01, 2007

Party for NCSU software engineering people

We joined the party for NCSU software engineering people hosted by Dr. Laurie Williams
Some pictures of ASE group as follows!!
pic 1 
pic 2
pic 3

Saturday Oct 13, 2007

Can we learn from Dr. "House" in doing research?

I enjoy watching Fox's House TV series.

I find the problem sovling skills and creative thinking there to be inspiring for us in doing research.:)

I enjoy watching how Dr. House advises his "students". I hope to learn the good poritions of his advising styles.:)


"

DR. GREGORY HOUSE (Hugh Laurie) is devoid of bedside manner and wouldn?t even talk to his patients if he could get away with it. Dealing with his own constant physical pain, he uses a cane that seems to punctuate his acerbic, brutally honest demeanor. While his behavior can border on antisocial, House is a brilliant diagnostician whose unconventional thinking and flawless instincts afford him a great deal of respect. An infectious disease specialist, he thrives on the challenge of solving medical puzzles in order to save lives.

For the past three seasons, House has shepherded an elite team of young experts who helped him unravel diagnostic mysteries. In addition, he has a good friend and confidant in oncology specialist DR. JAMES WILSON (Robert Sean Leonard). There?s some volatile chemistry between House and DR. LISA CUDDY (Lisa Edelstein), the Dean of Medicine and hospital administrator; the two are in constant conflict over House?s duties and unconventional behavior, but even she would admit that his brilliance is worth the trouble.

In the Season Three finale, the set-in-his-ways House was confronted with a series of major changes to his team. Neurologist DR. ERIC FOREMAN (Omar Epps) left Princeton Plainsboro because he didn?t want to turn into House; House randomly fired old-money intensivist DR. ROBERT CHASE (Jesse Spencer), claiming he learned everything he?s going to learn in the past three years, or nothing at all; and immunologist DR. ALLISON CAMERON (Jennifer Morrison) resigned, knowing House will be completely unaffected by her decision.

As Season Four opens, House is without a team to contribute to the perplexing medical cases he undertakes, and Cuddy and Wilson are adamant that he recruit new fellowship candidates. After 40 applicants applied for the newly vacated spots on his team, a group of five doctors -- played by Olivia Wilde, Kal Penn, Peter Jacobson, Anne Dudek and Edi Gathegi -- have emerged as finalists vying for the coveted and hotly contested openings."





Thursday Oct 11, 2007

Reading papers - 5 line summaries!

Dr. Xie maintains a very nice bibliography on Mining Software Engineering. We read lot of papers, but with time, tend to forget them. How about having a 5 line summary for each of the paper we read as a part of literature survey? I actually maintain a document which does exactly this and find it very useful. So next time I forget whats in a paper, I go to my document and look for the 5 line summary, and I immediately know what the paper talks about. I dont need to read the paper again. Another useful side-effect of this exercise is when you write related work for any of your papers or thesis.  In conferences, when you talk to other researchers, they usually ask - "Have you seen paper X? How is your work different from paper Y?" and its bad not to know some really relevant related work!

Most well written papers, can be read in about 15-30 mins and summarized in about 5 lines. In my field, most papers have a motivating example after introduction. For a well written paper, a reader should get the idea of the whole paper when he completes reading the Example section! So the way I read a paper is - read abstract, look at the conclusion, then read introduction (very fast), and then the example section. This process takes about 15 mins. Then I skim through the framework, implementation, and evaluation details. I spend further time on the paper, only on need basis. Then I summarize the whole paper in about 5 lines! During early years of PhD, it might be beneficial to read the whole paper to learn the art of writing papers... but after getting a hang of writing papers, quick paper reading will be a useful skill!

Comments?

Saturday Oct 06, 2007

Promoting Research Group Spirit and Peer Student Support

Earlier I didn't emphasize much on research group spirit. Recently I realized its importance and tried some measures to promote research group spirit.

I found that UIUC's Prof. Jiawei Han's several measures in his data mining research group could be valuable to borrow. I borrowed them recently in my group.

1. Allow students to volunteer to take on some services in the group.  In the past, I  (as the advisor) took on most of the services  in the group  including maintaining the group web pages, coordinating the group meetings, etc. Then students might feel like being managed without feeling to own the research group. In addition, I am too busy in doing these types of things and the students don't learn how to organize things or manage things: an important skill in their future career.

In the research group, early this semester I asked students to volunteer to take on various roles in the group:

*. Group Webmaster (news, group Web page, pictures, etc)
*. Group meeting coordinator
*. Server system administrator
*. Industry/visitor coordinator
*. Conference and journal review coordinator
*. Research proposal coordinator
*. Social activity coordinator

I found this mechanism works pretty well. For example, recently when a visitor from industry gave a guest lecture in my course when I was out of town, I asked the industry/visitor coordinator to organize student meetings with the visitor by introducing our research and doing demo; the whole process was organized by the coordinator with help from other students. The process went well and the students can also improve their independent skills: when the advisor is not around (in the future after they graduate, their advisor won't be around!), they can still successfully carry out things.

But I still need to figure out a way to encourage students to send emails in our group mailing list, whose emails are primarily sent by myself.

2. Acknowledge and honor those students who made great achievements in research so that these students can feel being recognized and other students can learn from these students and try to catch up. Jiawei Han's group honors the best-performing students each semester after students submit their research performance summary for the semester. Recently our research group also held voting among students (each one vote) and myself (with two votes, as suggested by one student, saying that my judgment would be more comprehensive). In the end, we voted one golden award winner and two silver award winner (with the same number of votes).

3. Besides borrowing Jiawei Han's measures, I also tried to promote peer support among the students in the group. Earlier the whole group activities centered around me, including reviewing their paper drafts, giving feedback on their research, etc. I would hope to set up a peer support system so that students can help each other and learn from doing so. Since some time ago I encouraged students to do proof reading each other's papers, and help each other. I will think of more other measures in promoting peer support.

4. As a routine practice in many research groups, asking students to present their own work or other related work by other researchers is quite valuable. Earlier I used the group meeting time slots to go round-table debriefing and I found it not that worthwhile in spending time. Nowadays, instead, in each group meeting, each student makes a presentation and then other students and I give feedback either on the content or presentation skills. Again, in this way, the group meetings shift from being dominated or driven by myself to being managed by students themselves.

I will think of more other measures in promoting peer support and group spirit. If you have any comments, you are welcome to discuss here.

 

Monday Jun 04, 2007

SE conference map came alive

Check out the Upcoming Software Engineering Conference Map created and maintained by Sung Kim and Tao Xie!

It came alive several days ago!

Monday Apr 30, 2007

The year-end picnic (Pig Pickin')

Dr. Tao Xie, Mithun, Yoonki, and JeeHyun joined the 'Pig Pickin' picnic as of 04-27-2007.
We had great food and enjoyed meeting with other students. The followings are the picture of us !!
pic 1
pic 2

Friday Apr 27, 2007

Answers to Global Educator Magazine, Student Section

The Global Educator magzine addresses students of science and engineering. The focus of the magazine is to provide information to students about educational institutions (specifically focusing on engineering and technology) in India and overseas, inform them about developing opportunities in engineering, offer practical tips on how to manage education abroad, carry interviews and profiles of achievers in the field of science, technology, engineering and business as role models.

Below are the answers to the interview questions posed by the Global Educator to me. They will be published in a future issue of the magzine.

1. Could you tell us about your career so far?

I am currently a PhD candidate in the Department of Computer Science at North Carolina State University, Raleigh, North Carolina. I completed my Master of Science degree from the same university in 2003, and Bachelor of Engineering degree from National Institute of Technology - Karnataka (previously KREC), Surathkal, India, in 2001, all in Computer Science. During my graduate studies, I have interned at NEC Europe Network Laboratories, Heidelberg, Germany and IBM T J Watson Research Center, New York. In 2007 summer, I will intern at Microsoft Center for Software Excellence, Seattle.  

2. How did Software Engineering interest you?

I like exploring research ideas that have immediate practical applications; innovations that create impact and are adopted by a very large community. Specifically, my interests in Software Engineering lie in the area of Automated Software Testing and Verification. It is indeed a very satisfying experience to come up with research methodologies that ultimately improve the developer productivity in the software industry. I was introduced to this fascinating world of Software Engineering through the Automated Software Engineering research group (http://ase.csc.ncsu.edu/) led by my advisor Dr. Tao Xie, of which I am currently a part of.

3. What is your doctoral research concentrating on?

In simple words, my doctoral research focuses on developing efficient techniques to automatically find bugs in software programs. Bugs can have serious implications ? illegal access to a personal computer, failure of a life-saving medical device managed by software, complete network shut down of a large organization, to name a few. Bugs are mainly caused when programmers fail to adhere to certain application-specific, non-syntactic rules in the code that they write. These rules, when documented and available, can be checked against a given program using sophisticated software verification tools such as model-checkers. So far, my doctoral thesis focuses on addressing two problems. (a) Writing rules formally for software verification is hard and error-prone (b) Application-specific rules may not be documented, hence being unavailable. I have proposed and implemented a framework that makes specifying rules for software verification easy. Furthermore, I apply data mining techniques to automatically extract such rules directly from program source code or program execution runs. These rules can then be used to find bugs.

 4. Through your doctoral thesis what would you contribute to the software engineering field?

 The research methodologies that I develop will aid developers in the software industry to adopt sophisticated software verification techniques in their coding cycle effectively, with minimum efforts. Software verification techniques such as model checking can assure total absence of certain classes of bugs. However, developers need to specify property rules formally in order to apply verification tools. Most developers find this specification task a hindrance to their coding efforts as specifying rules formally requires knowledge of the rules themselves (which might not be documented and available) and the formal rule language. Furthermore, specifying rules also requires the knowledge of the internal details of the components used in the software and their source code details. The techniques that I develop in my thesis partly automate the process of finding rules and specifying them for the verification tools. This research result ultimately leads to higher confidence in the software being developed and better quality assurance standards.

5. How has your experience been studying and conducting research in US university?

 Excellent! North Carolina State University has an excellent Computer Science program for students. Students are allowed to choose from a wide variety of courses preparing them to address research problems in different areas of Computer Science. There is an open environment for collaboration within the department and students are given great freedom and guidance to choose research problems that interest them. The curriculum also encourages students to get practical experience outside academia. To my research field, this is an integral component, as we get exposed to real problems that software developers face. The Automated Software Engineering research group, of which I am a part of, has ties with researchers from other universities and industrial research labs around the world. I have been very fortunate to work in few of the leading research labs in my doctoral career so far.

 6. Could you share your experience in technical conferences and during paper presentations?

 Our research group actively publishes in leading Software Engineering conferences. I have been fortunate to attend and participate in a few of them and it is a very rewarding experience. A student needs to have very good communication and presentation skills to get the best out of such conferences. It is about effectively and clearly presenting months or years worth of research work in less than half an hour and getting the audience interested. Leading experts in the field attend these conferences and it is very useful to get constructive feedback from them. Discussion with other conference attendees aid students in identifying problems in their research and also defining newer research problems to solve. This conference interaction leads to collaborations among researchers with similar interests. One also gets to learn about the most current research problems in the field by attending other presentations and key note talks. Conferences are also a great venue to meet with your prospective employers and discuss mutual interests. In summary, meet and talk to as many people you can in such conferences to ?sell? your research and also know about the latest in the field.

7. What innate skills do you feel essential for a PhD aspirant?

 In short, systematic problem solving skills are the most important requirement for a PhD aspirant. There are various components in productive problem solving. The first component is gathering the background knowledge required to conduct research. A PhD student has to know what has been done so far in his field and the emerging trends. A student gathers this knowledge by taking relevant courses and conducting extensive literature survey. A student should be very good at extracting relevant information for the research from the vast body of existing work quickly and effectively. The second component is identifying an interesting problem worthy of solving. This is a major component and takes time. Having a good advisor greatly helps here. The third component is excellent writing and communication skills. These skills are required to effectively publish the research findings and to get constructive feedback from advisors, mentors, and leading experts. In my field it also helps to possess good software development skills, the fourth component. We propose research solutions, implement them as tools, and test their effectiveness on real software subjects. Finally, a student needs to be self-motivated, passionate about the research problem, and dedicated to perform productive research. Some valuable advice on conducting research given by my advisor can be found at:

http://www.csc.ncsu.edu/faculty/xie/advice/

 8. What are your future aspirations?

 My immediate plan after graduation is to work as a software engineering researcher for an industrial research lab with strong publication culture. In my area, research problems are usually motivated by industry needs. After a few years of experience in the industry, I would like to apply for a tenure-track faculty position in reputed universities. As an academician, one has greater freedom in choosing the research problems and collaborations. My prior exposure to the software industry should enable me to address practical problems, the solutions of which would fundamentally advance the field of Software Engineering.

 9. Any comments on the software industry in India?

 The prospects for software industry in India are very bright. Leading software companies such as Microsoft and IBM have set up research labs in India recently. These research labs have strong collaborations with universities all over India. Most software development giants such as Infosys have research wings in house. These collaborations and industrial investment for research tie up practice and research promoting fundamental advances in the field of Software Engineering.  With its man-power and skill, India is soon going to be a software super power, contributing fundamentally to the field of Software Engineering and Computer Science in general. To this end, I personally feel that the government should increase funding grants and support for major universities such as Indian Institute of Technologies (IIT), apart from spawning newer universities for higher education. Graduate-level education in India for engineering and physical sciences is still not up to the mark and a substantial investment here would help transforming India to a knowledge super-power.


Thursday Apr 19, 2007

The birth of the blog for our NCSU ASE group

I created this blog to foster discussion and collaboration among our NCSU ASE group members and share our thoughts and experiences with people outside of our group. The main topic of the group will be about research but can be about anything related to NCSU ASE group:
http://ase.csc.ncsu.edu/ 


Archives
Links