Recently I presented to software developers / techies on writing papers and abstract in an IT company. I though this might be useful for other techies & geeks so making it publicly available.

1. For writing technical reports, white papers, research papers, …
How to write
abstracts?
Ganesh Samarthyam
Co-founder (CodeOps Tech.)
Author, writer, conference speaker
ganesh@codeops.tech

2. If you can write, you're an author!
Just like Nike’s mission statement - every one is an author!

3. If she can, you can
If she can
write, you can write
too!

4. If I can, so you can
Such 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

5. Some of my publications
https://scholar.google.co.in/citations?user=3Zksd94AAAAJ

6. Translations in other languages
https://books.google.co.in/books?id=x--MCwAAQBAJ
Korean!

7. Writing => Influence => Leadership
Grady Booch
Martin Fowler Kent Beck
Robert C. Martin

8. But I am a techie, not a writer!

9. You don't need a Ph.D to write papers !

10. Techie + Don't have a Ph.D
Grady Booch
Martin Fowler Kent Beck
Robert C. Martin

11. Writing abstracts

12. 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

13. 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

14. Title should reflect the paper’s content

15. 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

16. 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

17. Abstract: a must for any kind of technical writing
Tool demos
Technical briefings
Posters
White papers
Articles
Research papersExperience reports
Case studies

18. 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

19. 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

20. 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?

21. 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?

22. 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?

23. 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?

24. 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?

25. 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

26. 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

27. 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?

28. 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?

29. 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 exactly does
this work cover?
What is the
“contribution”?

30. 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?

31. 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?

32. 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)

33. Template to get started with
1. 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

34. Writing abstracts:
tips & best practices

35. 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]

36. 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]

37. 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]

38. 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!]

39. 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.]

40. Tip #6
Revise, Revise, Revise
Revise 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.]

41. You can write too!

42. 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)

43. ganesh@codeops.tech @GSamarthyam
www.codeops.tech slideshare.net/sgganesh
+91 98801 64463 bit.ly/ganeshsg