Writing a precis

The commentary or précis of a reading/article conveys what you learnt and how you might employ the knowledge. In addition you can employ a critical or analytical interpretation, i.e. what is the intention of the authors, who is the audience, how valid are the claims?

Patterns for a basic précis:

• Sentence 1:Name of author, genre, and title of work, date in parenthesis; a rhetorically accurate verb (such as "claims," "argues," "asserts," "suggests"); and a THAT clause containing the major assertion or thesis statement in the work. 
• Sentence 2: An explanation of HOW the author develops and supports the thesis, usually in chronological order. 
• Sentence 3: A statement of the author's apparent purpose, followed by an "in order to" phrase. 
• Sentence 4: A significant quote from the paper used in a sentence.

On quoting from the article you are reviewing...

Your ability to quote and properly identify text and other elements such as figures and tables from a reading/article is a basic writing skill. You should, where possible, include page numbers or page ranges. For example, use double quotation marks and page numbers to identify "the quoted text" p. 23. You will employ the conventions of whatever standard citation method you are using e.g. Harvard style:

• (Author Surname, Publication Year, p. no.)
• (Author Surname, Publication Year, pp. no-range.)

In rare cases you may need to employ combinations of single and double-quotes to delineate the original passage and its internal grammar.

In the case that you choose to cite a sub-quoted second author you should wherever possible obtain and read a copy of the second author's text. Read it. You may disagree with the first primary author's interpretation. You can then quote this secondary article in turn as a primary source. You will try to avoid quoting a primary author's quotes of secondary authors.

Fin Goulding reflecting (imo) on how we build the organisations that build software

This talk by Fin Goulding at FlowCon France 2019 has so many points of resonance with my own software practice: the value of being present with each other, allowing ourselves to be vulnerable, open to learning (by making mistakes), using Kanban, focus on process, work-in-progress, flow, and visualising everything.

Not to mention the waste of attention being devoted to meaningless strategic change. Oh! And by the way, your own organisations' leaders are struggling with understanding what strategy is too. They struggle with appearing to need to know it all. So, take the Agility fad with a hefty pinch of salt, particularly if it is being served up by consultants. 

In fact I think he is reflecting on how we build the organisations that build software. And if we take the idea far enough, all organisations are a kind of software. There are other ways, more human and humane ways to organise ourselves. 

 

For more see Fin Goulding | Enterprise Flow | https://enterpriseflow.io

Example case study research in software engineering

An approach to presenting your own research is to identify an existing academic/scholarly article that reports in some way that you find informative and that might steer your analysis of your own case study or development/maintenance management system.
The following 'convenience sample' of articles ranges over diverse perspectives but offer (in my opinion) useful and informative case studies researching empirical software engineering.

A field study of the software design process for large systems
B Curtis, H Krasner, N Iscoe - Communications of the ACM, 1988 - dl.acm.org

Ethnographically-informed systems design for air traffic control
R Bentley, JA Hughes, D Randall, T Rodden… - Proceedings of the …, 1992 - dl.acm.org

ISO9000 and the very small firm
EM Wareham - IEE Review, 1994 - ieeexplore.ieee.org

Conversational Conventions and Participation in Cross-Functional Design Teams
E Wynn, D G Novick - Proceedings of COOCS, 1995 - ACM

Flight of the Eagle: The Birthing and Life of a Super-Minicomputer.
J Faughnan, S Stevanovic - Project Management, 1996 - faughnan.com

Embracing change with extreme programming
K Beck - Computer, 1999 - ieeexplore.ieee.org

A case study of open source software development: the Apache server
A Mockus, RT Fielding… - Software Engineering, …, 2000 - ieeexplore.ieee.org

Working artefacts: ethnomethods of the prototype
L Suchman, R Trigg, J Blomberg - The British journal of …, 2002 - Wiley Online Library

Reflective Design Practices in Human Computer Interaction and Software EngineeringELC Law - Proceedings of the Workshop on Designing for …, 2004 - Citeseer

When software engineers met research scientists: A case studyJ Segal - Empirical Software Engineering, 2005 - Springer

Sociomaterial practices: Exploring technology at work
WJ Orlikowski - Organization studies, 2007 - oss.sagepub.com

Scrum in a multiproject environment: An ethnographically-inspired case study on the adoption challenges
A Marchenko, P Abrahamsson - Agile, 2008. AGILE'08. …, 2008 - ieeexplore.ieee.org

Collaboration and co-ordination in mature eXtreme programming teams
H Sharp, H Robinson - International Journal of Human-Computer Studies, 2008 - Elsevier

The influence of organizational structure on software quality: an empirical case study
N Nagappan, B Murphy, V Basili - … conference on Software engineering, 2008 - dl.acm.org

Successful knowledge transfer within offshore supplier networks: a case study exploring social capital in strategic alliances. 

Rottman, J. (2008), Journal of Information Technology, 23, 31–43.

Distributed Communication as Collective Socio-material Sensemaking in Global Software WorkS Vidolov, S Kelly - 2009 - aisel.aisnet.org

Guidelines for conducting and reporting case study research in software engineering
P Runeson, M Höst - Empirical Software Engineering, 2009 - Springer

Understanding project survival in an ES environment: a sociomaterial practice perspective
EL Wagner, S Newell, G Piccoli - Journal of the Association for Information …, 2010 - Citeseer

Scrum+ engineering practices: Experiences of three microsoft teams
L Williams, G Brown, A Meltzer… - … Software Engineering …, 2011 - ieeexplore.ieee.org

Sociomaterial bricolage: The creation of location-spanning work practices by global softwaredevelopers
A Johri - Information and Software Technology, 2011 - Elsevier

Entanglements of creative agency and digital technology: a sociomaterial study of computer game development
NS Panourgias, J Nandhakumar… - … Forecasting and Social …, 2013 - Elsevier

The validity of case study research is often called into question by asserting that the findings from single cases cannot and should not be generalised beyond the specific contexts and events of the case's empirical setting. However, the criticism ignores our human ability to generalise and glean learning ourselves when we hear stories of others' experiences. You could call it vicarious learning, looking over someone's shoulder, it exemplifies our innate ability to juxtapose and translate learning from one context and apply it to a different context. Furthermore human activity systems, of which software engineering is but one example, are intrinsically 'in vivo' settings. They are open and transparent to  sociological enquiry insofar as its actors participate reflexively within a wider social world. The reflexivity of human actors is present in so far as we, as protagonists, are aware of and take account of ourselves in terms of our behaviour, actions, and agency.

I adopting a stance that human activity systems diverge from the usual notions of functional science and therefore argue for the value of learning gained from cases. Rather than extrapolating from the specific to the general, cases encourage us to reflect on and relate learning from the specifics of cases to other contexts or situations.

---

Footnote: The field you address will relate to the findings you arrive at from your analysis of the data you gather, which of course is influenced by the access you have to an empirical case study site.

empirical case + access levels -> data gathered -> analysis -> findings -> audience / field

The field or conference you publish in will have its own format template that is simply adapted for the write-up.

Help with the structure of a research paper

Structure of a typical journal style paper - not all sections may be needed

Title and Abstract

Both the title and abstract should both capture the essence of the study.

Introduction / Literature (positioning)

Give a brief introduction to the literature and positioning for the study.

Research Design / Methods / Context

An outline of the general research approach, how you obtain your data, research method(s) protocol/recipe etc.

Data / Findings

Tell the story, provide the evidence, findings, account or narrative.

Analysis / Discussion

This is where draw out the significance of what you have discovered. You employ arguments, apply models or produce your own interpretation of the data, in order to better understand the evidence.

Conclusions

Conclusions summarise the findings concisely, perhaps half a page. Offers an overall synthesis distilling your analysis and its relevance to theory and the literature.

Bibliography/References

The bibliography/reference section is crucial to get right as it is the index to prior research and literature that you have referred to previously.

Appendices (if needed)

Use appendices to provide additional detail if necessary. Usually data samples, or intermediate representations, for example a sample of the data analysis process, coding frames, stages in the coding and summary or intermediate categories from data.

Some questions to ask yourself when reviewing your own paper

• For the research design did you identify one or more research methods to use? 
• For each method did you reference literature/source material inspiring the method?
• Have you described your protocol/method instructions used to apply the method?
• 
  
• For the data/findings section, have you show that you applied the methods and gathered evidence/data/findings?
• Is evidence of actual data presented (selected extracts, images etc)? Whole data sets can be included in the appendix and/or your research repository (fancy name for folders).
• 
  
• Is the discussion structured as a discussion (claim, critique, thesis, antithesis, synthesis)?
• (can use objective voice)
• An opening statement to remind us of the context?
• Claims from the literature of the gap or for/against different understandings?
• Commentary on the evidence gathered, offering an interpretation of that evidence?
• Relating the interpretation back to prior literature?
• Comment on gaps, problems, shortcomings?
• Does it avoid straying into the final conclusions?
• 
  
• Does the conclusions section actually state conclusions?
• (can use objective voice)
• Sets out the claims that are supported (and not supported) by the evidence?
• Mention made of possible future research addressing shortcomings, gaps, problems, criticisms?
• 
  
• The abstract is short and succinct (1/4 to 1/2 page) and sets the scope for the entire paper.
• After reading the title and authors names the abstract is the single strongest hook you have to encourage someone to actually read more of your paper.
• It uses clear simple language explaining the gap/relevance/need for the study - usually couched in questions.
• The last paragraph will often declare the most significant conclusion(s) of the paper - although your reader will have to go deeper to discover the why.
• You wouldn't normally use citations in the abstract.

On the subject of Writing

A couple of general points may be useful.

Working Title: Initially, phrase a research question as the title of the paper (you can change it later).
Abstract: Restate and expand on the research question in the abstract (you can change it later when you have analysed your findings).

Research Access: Make good use of your personal access to your contacts, projects or companies, past or present for providing data.

Gather data and working backwards:
What I mean by this is that you will almost certainly end up changing/revising the research question as you go along, and the abstract will need to be revised at the end. The working title and abstract written at the beginning was just a first stab at the paper.
A research question is a prerequisite and precursor to a research project. Having a question puts the focus on a few things; the kinds of data you might expect to gather which could be anything from interviews, observations, documentary/documents, to literature review/desk research etc. etc.
A (tentative) research question usually implies particular kinds data, so ask, what kind of data does the question imply? What constitutes evidence for the phenomena under investigation? What data will (or might) provide the kinds of evidence that could be used to make justifiable statements about the research context?
A clear idea of the kind of evidence and data sought leads us to consider the types of data capture methods (research methods) that can be used to produce data or the evidence sought. This in turn indicates a typical overall research model, research design and research approach. Sometimes a programme of research will involve many of these approaches. For example, literature review, a distinctive family of desk based text research, is generally a prerequisite for all other research activities; evident in an introduction or positioning section of a paper, or constitute the whole research project itself. In very general terms, the gamut of research designs or models includes - but is not limited to:

Essay: Purely theoretical, elaborating a conjecture, speculation, conceptual, philosophical argumentation, thought experiment, word games, word play, rhetoric, logicism, formalism, constructionism.
Review, meta-analysis of prior research, selective literature review, systematic literature review.
Empirical: descriptive, idiosyncratic, case-study, naturalistic observation, questionnaire survey.
Correlational-causal: studies adopting systems model views, inputs factors, outcomes, case-control study, observational study, survey, structural equation modelling.
Statistical meta-analytic: research derived from other research, findings based on aggregations of other research.
Semi-experimental: research styled on intervention in settings, field experimentation not amenable to laboratory control, quasi-experiment, trials, living labs.
Experimental: classical closed system model of scientific discovery, reproducible experiment, blind experimentation, random assignment experiments.

(partially derived from the Wikipedia article on Research Design):

These various research models involve or require differing philosophical commitments and assumptions or beliefs around the nature reality and the world (worldview, ontology), and of the nature of knowledge (epistemology is the theory and nature of knowledge; objective, subjective, social). Usually it is sufficient to simply acknowledge the stance adopted for the purpose of the research, be it: interpretive, critical, critical realism, naive realism, post-modern, deconstruction, construction, positivist, aesthetic, utilitarian, speculative, qualitative, quantitative.

Improve the draft:

Commence your paper with an introductory/positioning piece that incorporates a short selective review of relevant recent literature critically addressing the topic areas you are working with.

Provide a presentation to peers or colleagues if possible, talking through your ideas, the data, your analysis and findings. Doing so will inevitably help refine how well you communicate the story, your message, convincing evidence, the key points, highlight your contribution and findings.

Template

Start using a scientific conference template for writing up. I recommend using the LaTeX or Word template from the ECIS 2015 conference (http://www.ecis2015.eu/participation/submissions.html)

Further reading

Links to various related conference templates below:
A LaTeX and a Word version of an ECIS Template - from Muenster 2015 - recommended!!
A LaTeX version of an ICIS Template - Ryan Schuetzler - a bit gnarly. A Word version of an ICIS Template - it's Word :-(

Respect for rigour in software development

Overview: 

While this is a magazine report rather than a research article, story itself is a rarity, a compelling published account of how high reliability software is reportedly developed. This team was one of the inspirations for the creation of the SEI CMM/CMMI standards approach to controlling software systems development.

The story: 

The way to software you can trust your life with is through rigor and control. In Fishman's (1996) report we are provided with something of an overview of the situation, the resources, the working environment and the demands being satisfied by a software team responsible for developing the on-board flight control programs for the Space Shuttle. 

"Consider the stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors." (Fishman,1996)

"the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI) a measure of the sophistication and reliability of the way they do their work. In fact, the SEI based it standards in part from watching the on-board shuttle group do its work. (Fishman,1996)"

But if rigor can be good, why do CMM, CMMi and other control frameworks have such a bad reputation in the profession?

"I am convinced that most organizations using the CMM are still entrenched in a default waterfall model mentality. I won't lay blame on the model itself, for I am aware of some process improvements made within a CMM context that were very much based on a modern, iterative approach to development. But this enlightened interpretation is not the norm." (Royce, 2002)

Is rigor only possible with frameworks and management control? Are other kinds of rigor and control possible? If there is a common problem what is it? At what point does more 'stuff' become the problem rather than the solution to the problem?

Commentary on 'the Right Stuff' on the C2 wiki (link).
And the backstory to waterfall, Winston and Walker Royce (link).


References
1. Fishman, C. (1996) They Write the Right Stuff.
2. Royce, W. (2002) CMM vs CMMI: from conventional to modern software management.

Use the template for the term paper

Please use the specified scientific conference template for the term-paper. 

Copies are available on (Google Drive link).

https://drive.google.com/drive/u/1/folders/0Bz8LaXpGlA4ucXoyYXRQYUpJSTg

Choose between either the LaTeX or Word template from the ECIS 2015 conference.

By using and sticking with the ECIS template your paper will automatically conform with the scientific format guidelines for that conference.

Big Ball of Mud

It might be said that any software codebase and architecture initially resembles spaghetti code by being incomprehensible at first to any but an acolyte deeply familiar with its design.

The Big Ball of Mud architecture pattern was proposed by Foote and Yoder (Foote et al. 2000) as an 'anti-pattern' in software design and an inevitable consequence of the forces experienced by development. Development takes place within an environment of contrary forces and time pressure that imposes restrictions, constraints etc. on 'proper' design. For example, foundational design concepts such as coupling and cohesion of code modules are gradually broken and so architectural integrity degrades over time due to the ad hoc nature of evolving needs, requirements, and bug fixing. Boehm claimed that both ends of the lifecycle spectrum, ‘Code and Fix’ and Stagewise models end up producing unmanagable code or programs that fail to address the customer's goals (Boehm 1988). Foote and Yoder take an alternate view, that life cyle isn't the problem, the problem is intrinsic to code that succeeds and therefore needs to be maintained over a long time. They suggest that the BBM pattern is present as entropy, an attractor to disorder that imposes a constant tension on code but one that can be resisted through the practice of Refactoring.
"A certain amount of controlled chaos is natural during construction, and can be tolerated, as long as you clean up after yourself eventually. Even beyond this though, a complex system may be an accurate reflection of our immature understanding of a complex problem." (Foote & Yodder, 2000)


On the mysterious mound builders of Mountain View.

Brian Foote observes that in the years since he and Yoder wrote the article, "that no one has ever challenged our premise. No one has ever said 'no it isn't the most frequently deployed architecture out there', 'it isn't what we're all doing'" (Foote, 2007: 17'29")

One of the dynamics that produces BBM is turnover. "All too many people get onto projects, beat the heck out of the code, and move onto the next project. The code 'dies', the code is unmaintainable, nothing else can grow there, the enterprise founders, the end of the story." (Foote, 2007: 30'35")

The messiness of the relationship between code, architecture, and design may again be an intrinsic facet of software. Richard P. Gabriel (link) is credited with the counter-intuitive adage that 'worse is better' to characterise the dynamics of software acceptance. Subtly it can be understood from two perspectives, the developer and the user. From the developer's perspective worse code may produce better results for the user. From the user's perspective less features (worse) may be better because simplicity is what the need rather than what they want.

REFERENCES
Big Ball of Mud: Foote, B. & Yoder, J. (2000) Big Ball of Mud. IN HARRISON, N., FOOTE, B. & ROHNERT, H. (Eds.) Pattern languages of program design 4. Addison Wesley. (version online)
A wiki discussion on one of BBM's topics at Ward Cunningham's c2.com (link) - photo credit JohnLennon shovels on the spaghetti in cover art from the Magical Mystery Tour.
Foote, B. (2007) Big ball of Mud. Google Tech Talks.

MIS40850 The Term Paper Guideline

MIS40850 The Term Paper Guideline

``A case study of software engineering. ''

 Write an 8 page research paper. This page count includes the References section. Graphs, images, tables are not included in the 8 pages and so are indicated by caption and cross-reference text only e.g. <<Table 1 goes here >> or << Figure 1 goes here>>. Copies of the actual tables, figures, images will go into the appendix after the 8 pages. There is no page limit on the appendix.

Please acknowledge and reference all third party material, copyright etc. University College Dublin policies on plagiarism apply.

Scope:

The paper is written in an academic style, including references, bibliography etc.

An original descriptive case study of organisational aspects of your work environment or dealing with a project that you are/were involved in, applying theories and ideas discussed in lectures to illustrate and critique the challenge of designing, managing, controlling various aspects of software development. Alternatively a desk investigation (e.g. focused literature review, industry data analysis) may be agreed.

The subject matter should be of interest to anyone who wants to find out more about current software development practices. Indicative topics or subject areas may include:

• Software methodology (how you would characterise it e.g. in-house, waterfall/staged, agile/XP/iterative)
• Technology stack (a list/functional view of actual tools used to design/code/build/release)
• Issue tracking (bugs, support, features etc.) How it relates to daily dev activities?
• Design approaches; do you have a distinctive approach to designing? Where is design done? Who by?
• Deployment; how you deploy builds or packages, or operate if a service. How customers get and use it. DevOps.
• Code reviews, bench checks, pair programming. Practices around code and design reviewing.
• Approach to testing, Unit Tests, TTD, how testing is done during dev, before a release, for each build etc.
• Build; your policy for build/release, i.e. how you package, version, stage.
• Feature request/development life cycle.
• Quality Management Systems. What management system is in place? How it relates to Software methodology?
• Team environment, numbers of people in typical team, typical daily interactions, how interactions captured?
• Management challenges: knowledge management, career development, maintenance versus new product dev.
• Software Process Improvement (differences if any between maintenance versus new product dev.)

Suggested outline structure

Abstract: A brief summary of the context and contribution in easy to digest words. 

Introduction and Literature: Use the introduction to set the stage and survey the literature. Explain/critique the current state of knowledge and drawing upon relevant/similar research publications.

Research method: A short statement of the research design and research methods employed.

Case description/context: A readable descriptive account of the salient features of an important period, project, episode based on your own development experience and your view of what it is/was really like (insider's view).

Analysis: Interpret a concise selection of representative case data findings. Employ relevant theories or models to help explain the findings. 

Discussion: Relate the findings to the literature, to current professional practice. Seek to generalise findings for wider application. 

Conclusions: An overall synthesis.

(the following are not included in the page count)

References: A bibliography of references cited in the report; use the template reference style or Harvard equivalent. 

Appendices: Diagrams, figures, tables, and additional relevant material may be included in appendices.

Grading Criteria

Grading will consider the following:

1. The research project (motivation and goals) is clearly explained.
2. Critical positioning in literature.
3. Empirical work, data and evidence presented.
4. Contributions are clear.
5. Overall quality of the document as a finished product.

And so; questions the examiner will ask when reading the paper will be:

• Is the research project (motivation and goals) clearly explained?
• How is it positioned in the literature?
• Is empirical work, data and evidence presented?
• Are the findings, conclusions, contributions clear?
• Overall quality, how does the document look and read?

A brief explanation of letter grade descriptors is provided below.

---

Modular (letter) grades.

A+/A

• The report is complete and covers all important topics.
• Appropriate significance is attached to the information presented.
• There is a compelling logic to the report that reveals clear insight and understanding of the issues.
• Analytical techniques used are appropriate and correctly deployed.
• The analysis is convincing, complete and enables creative insight.
• The report is written in a clear, lucid, thoughtful and integrated manner-with complete grammatical accuracy and appropriate transitions.

A-/B+

• The report is complete and covers all important topics.
• Appropriate significance is attached to the information presented.
• There is a clear logic to the report that reveals insight.
• Analytical techniques used are appropriate and correctly deployed.
• The analysis is convincing, complete and enables clear insight.
• The report is written in a clear, lucid, and thoughtful manner-with a high degree of grammatical accuracy.

B/B-

• The report is substantially complete, but an important aspect of the topic is not addressed.
• The report used information in a way that was inappropriate. 
• There is a clear logic to the report.
• Analytical techniques are deployed appropriately.
• The analysis is clear and the authors draw clear, but not comprehensive conclusions for their analyses.
• The report is written in a clear, lucid and thoughtful manner, with a good degree of grammatical accuracy.

C

• The report is incomplete, with important aspects not addressed.
• The report frequently used information that was substantially inappropriate or inappropriately deployed.
• The report’s analysis is incomplete and authors fail to draw relevant conclusions.
• The report is poorly written.

D

• The report is substantially incomplete.
• Whatever information provided is used inappropriately.
• There is little analysis and the report is inconclusive.
• The report is poorly written and presented.

A Powerpoint slide - the first homework deliverable

Submit via Brightspace > Assessment > Assignment 

Requirement: Create a powerpoint slide titled "How we build Software: A case of software engineering/project practice" based on a case from your own personal experience/company.

• The slide will be used to help you speak about or present a workplace, from the perspective of your professional capacity as an experienced technologist commenting on standard work practices.
• You may obscure or anonymise details if needed.
• Please include speech notes in the notes section of the slide.
• We will use these slides to form pairs or groups to record podcast interviews (held on Thursday afternoons during term).