For writing technical reports, white papers, research papers, …
How to write abstracts?
Ganesh SamarthyamCo-founder (CodeOps Tech.)Author, writer, conference speaker [email protected]
If you can write, you're an author!
Just like Nike’s mission statement - every one is an author!
If she can, you can
If she can write, you can write
too!
If I can, so you canSuch poor
background where I started from, I see myself
as a success!
I am second from left (wearing glasses)
“Success is relative, individual and personal”
- Wilfred Peterson
Some of my publications
https://scholar.google.co.in/citations?user=3Zksd94AAAAJ
Translations in other languages
https://books.google.co.in/books?id=x--MCwAAQBAJ
Korean!
Writing => Influence => Leadership
Grady Booch
Martin Fowler Kent Beck
Robert C. Martin
But I am a techie, not a writer!
You don't need a Ph.D to write papers !
Techie + Don't have a Ph.D
Grady Booch
Martin Fowler Kent Beck
Robert C. Martin
Writing abstracts
General structure of a paper❖ Title❖ Abstract
❖ Introduction
❖ Motivation & background* ❖ Related work (state of the art)
❖ Methods / main contribution
❖ Results / evaluation ❖ Discussion*
❖ Conclusion & future work
❖ References (bibliography)
* optional parts
Example: MIDAS paper
“MIDAS: A Design Quality Assessment Method for Industrial Software”,
Ganesh Samarthyam, Girish Suryanarayana, Tushar Sharma, Shrinath Gupta,
Proceedings of the International Conference on Software Engineering,
San Francisco, 2013
Title should reflect the paper’s content
Why care about the title?
❖ Title: the “name” of your work
❖ Try to make it “pithy”, “catchy”, “attractive”, or “memorable” ❖ Avoid overly short (~2
words) or excessively long (> 10) words
Why care about the abstract?
❖ Abstract: the “face” of your work
❖ Reviewers and readers read the title and abstract to decide if they want to read it further or not ❖ Publicly available for free
access in sites like dl.acm.org and scholar.google.com
Abstract: a must for any kind of technical writing
Tool demos
Technical briefings
Posters
White papers
Articles
Research papers Experience reports
Case studies
Title example: Smells paper
Towards a Principle-based Classification of Structural Design Smells
“Towards” indicates that it is a relatively early work
The paper is about classification of smells that is based on design principles
Download here: www.jot.fm/issues/issue_2013_06/article1.pdf
Abstract example: Smells paper
Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
211 words
Abstract example: Smells paper
Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our
study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
Why care about this topic?
Abstract example: Smells paper
Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and
address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In
order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
What “gap” or “whitespace” does this
work fill or address?
Abstract example: Smells paper
Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an
effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To
evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
What is the “contribution” of the work?
Abstract example: Smells paper
Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a
novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for
design smells and also highlight several interesting observations and insights that result from our work.
What is the evidence that this approach works? How can you
substantiate your claims?
Abstract example: Smells paper
Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about
their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
What exactly does this paper cover?
Title example: MIDAS paper
“MIDAS: A Design Quality Assessment Method for Industrial Software”
Acronym: can refer to it as “MIDAS” paper
Name could imply “MIDAS touch” => transform your software to “gold” quality!
The paper is about a method for assessing design quality of
software developed by IT companies
Abstract example: MIDAS paper
Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
185 words
Abstract example: MIDAS paper
Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
What is the context of this paper?
Why this work is important in this
context?
Abstract example: MIDAS paper
Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software
design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
What “gap” or “whitespace”
does this work fill or address?
Abstract example: MIDAS paperSiemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA
and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We
believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
What exactly does this work cover?
What is the “contribution”?
Abstract example: MIDAS paper
Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-
specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the
insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
What does this paper (not the overall work)
cover?
Abstract example: MIDAS paper
Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to
three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
Why should you care?
Who should read this?
Which one is a better abstract?Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.
Smells paper MIDAS paper
• Effective motivation and background • Cute acronym (helps cite, recall, or refer)• Mentions who this paper is for and
benefits of reading it (target audience)
Template to get started with1. What is the context of this paper?
2. Why this work is important in this context?
3. What “gap” or “whitespace” does this work fill or address?
4. What exactly does this overall work (not the paper) cover?
5. What exactly is the “contribution” of your paper?
6. What does this paper (not the overall work) cover?
7. What is the evidence that this approach works? (substantiate your claim)
8. Why should someone care about your work or paper?
9. Who should read this? (target audience)
Marked in bold are the key parts of the paper and the abstract
Writing abstracts: tips & best practices
Tip #1
Ensure the title and abstract are free of
“grammatical errors”
Reflects poorly on the quality of the rest of the paper
[Embarrassing to have typos or grammatical errors in the title or abstract]
Tip #2
Write abstract after you have written the paper
Once you completed writing the paper, it is easier to summarise it (abstract is a summary!)
[of course, you can start with a rough abstract but make sure you revisit it after completing the paper]
Tip #3
Write “self-contained” abstracts
Abstract should not refer to tables, figures, or cite other papers
[of course, there are exceptions; consider this as a rule of thumb]
Tip #4
Abstract must be short and effective; try to “arouse
curiosity” to read the full paper
The abstract should be a single paragraph; be creative in encouraging reader to read the whole paper
[most papers are “write-only” papers - try writing a paper that people would like to read!]
Tip #5
Do not copy paste abstract from conclusion section!
Abstract and conclusion have distinct purposes
[Of course there will be some overlaps between abstract and conclusion, but they should not be clones.]
Tip #6
Revise, Revise, ReviseRevise the abstract multiple times to improve it
[Even the best writers revise their writing multiple times to get it to publishable quality text. So, don't hesitate to revise.]
You can write too!
Further reading
❖ Writing Research Papers (Rice University)
❖ How to Write Research Papers? (Tao Xie)
❖ “Writing Good Software Engineering Research Papers” (Mary Shaw)
❖ How to Write a Great Research Paper (Simon Peyton Jones)
[email protected] @GSamarthyam
www.codeops.tech slideshare.net/sgganesh
+91 98801 64463 bit.ly/ganeshsg