Abstract: Technical debt represents the situation in a project where developers accept compromises in one dimension of a system in order to meet urgent demands in other dimensions. These compromises incur a “debt”, on which “interest” has to be paid to maintain the long-term health of the project. One of the elements of technical debt is documentation debt due to under-documentation of the evolving system. In this exploratory study, our goal is to examine the different aspects of developers' motivation to document code. Specifically, we aim to identify the motivating and hindering aspects of documentation as perceived by the developers. The motivating aspects of code documenting we find include improving code comprehensibility, order, and quality. The hindering aspects include developers’ perception of documenting as a tedious, difficult, and time consuming task that interrupts the coding process. These findings may serve as a basis for developing guidelines toward improving documentation practices and encouraging developers to document their code thus reducing documentation debt.
To document or not to document? An exploratory study on developers' motivatio...Hayim Makabee
Abstract: Technical debt represents the situation in a project where developers accept compromises in one dimension of a system in order to meet urgent demands in other dimensions. These compromises incur a “debt”, on which “interest” has to be paid to maintain the long-term health of the project. One of the elements of technical debt is documentation debt due to under-documentation of the evolving system. In this exploratory study, our goal is to examine the different aspects of developers' motivation to document code. Specifically, we aim to identify the motivating and hindering aspects of documentation as perceived by the developers. The motivating aspects of code documenting we find include improving code comprehensibility, order, and quality. The hindering aspects include developers’ perception of documenting as a tedious, difficult, and time consuming task that interrupts the coding process. These findings may serve as a basis for developing guidelines toward improving documentation practices and encouraging developers to document their code thus reducing documentation debt.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Technical debt is a metaphor for the gap between the current state of
a software system and its hypothesized ‘ideal’ state. One of the significant and
under-investigated elements of technical debt is documentation debt, which
may occur when code is created without supporting internal documentation,
such as code comments. Studies have shown that outdated or lacking
documentation is a considerable contributor to increased costs of software
systems maintenance. The importance of comments is often overlooked by
software developers, resulting in a notably slower growth rate of comments
compared to the growth rate of code in software projects. This research aims to
explore and better understand developers’ reluctance to document code, and
accordingly to propose efficient ways of using persuasive technology to
encourage programmers to document their code. The results may assist software
practitioners and project managers to control and reduce documentation debt.
The Role of the Software Architect (short version)Hayim Makabee
Talk at the First Israeli Conference on Software Architecture
http://www.iltam.org/sw-arch2014/
Abstract:
In this talk Hayim will present the practical aspects of the role of the Software Architect, including the architect's contribution at the diverse stages of the software development life cycle, and the cooperation with the diverse stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.
Bio: Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Research Engineer at Yahoo! Labs Haifa. He is also a co-founder of the International Association of Software Architects in Israel.
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Software engineering practices and software quality empirical research resultsNikolai Avteniev
This presentation summarizes empirical research findings in software engineering practices including test driven development, peer code reviews, and defect prediction.
To document or not to document? An exploratory study on developers' motivatio...Hayim Makabee
Abstract: Technical debt represents the situation in a project where developers accept compromises in one dimension of a system in order to meet urgent demands in other dimensions. These compromises incur a “debt”, on which “interest” has to be paid to maintain the long-term health of the project. One of the elements of technical debt is documentation debt due to under-documentation of the evolving system. In this exploratory study, our goal is to examine the different aspects of developers' motivation to document code. Specifically, we aim to identify the motivating and hindering aspects of documentation as perceived by the developers. The motivating aspects of code documenting we find include improving code comprehensibility, order, and quality. The hindering aspects include developers’ perception of documenting as a tedious, difficult, and time consuming task that interrupts the coding process. These findings may serve as a basis for developing guidelines toward improving documentation practices and encouraging developers to document their code thus reducing documentation debt.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Technical debt is a metaphor for the gap between the current state of
a software system and its hypothesized ‘ideal’ state. One of the significant and
under-investigated elements of technical debt is documentation debt, which
may occur when code is created without supporting internal documentation,
such as code comments. Studies have shown that outdated or lacking
documentation is a considerable contributor to increased costs of software
systems maintenance. The importance of comments is often overlooked by
software developers, resulting in a notably slower growth rate of comments
compared to the growth rate of code in software projects. This research aims to
explore and better understand developers’ reluctance to document code, and
accordingly to propose efficient ways of using persuasive technology to
encourage programmers to document their code. The results may assist software
practitioners and project managers to control and reduce documentation debt.
The Role of the Software Architect (short version)Hayim Makabee
Talk at the First Israeli Conference on Software Architecture
http://www.iltam.org/sw-arch2014/
Abstract:
In this talk Hayim will present the practical aspects of the role of the Software Architect, including the architect's contribution at the diverse stages of the software development life cycle, and the cooperation with the diverse stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.
Bio: Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Research Engineer at Yahoo! Labs Haifa. He is also a co-founder of the International Association of Software Architects in Israel.
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Software engineering practices and software quality empirical research resultsNikolai Avteniev
This presentation summarizes empirical research findings in software engineering practices including test driven development, peer code reviews, and defect prediction.
Overview of the paper "Visual Software Evolution Reconstruction" by Marco D'Ambros and Michele Lanza presented at Oregon State University for "Information Visualization" class on May 12th 2014. Presentation time: 15 min
Introduction to Software Engineering for Undergraduate students. it relates SW Engineering topics to actual work environment, with an example of job announcement for software engineer
Testing a software product is an essential part of the development process. The tests have the goal to improve/optimize defined quality attributes of the product. Unfortunately, sometimes software is developed based on the needs of a single programmer or just because a recent technology enables new product developments, and later—once a prototype is available—the question arises for whom this product might be interesting. In such cases, it is difficult to develop the appropriate requirements that best fit the needs of the final user.
In this talk we describe a personas-driven testing approach, which derives personas based on an initial product idea. Based on the derived personas, we define requirements and tests to guide the further development of the product.
The talk will present a case study in which we applied the method: from the initial prototype, we derive four personas that use the prototype in various ways, we extract requirements and tests.
When you work in a small collocated team many engineering practices and approaches are relatively easy to use and adapt. In large project with many teams working on the same product this task is not so simple. I want to share experience report in implementing Code Review practice in big product development team (more than 150 people, 10+ feature teams). In this talk we will review what approaches works in such setup and what don’t work, what tools and additional practices are needed to support Code Review and make it more effective, what difficulties and blockers will you probably see in the real life cases, what useful metrics could be produced by this practice.
E Roger Pressman Bruce Maxim Software Engineering_ A Practitioner's Approach 8e.
Chapter 5:
5.1 What is Agility?
5.3 What is an Agile Process?
5.3.1 Agility Principles.
5.3.2 The Politics of Agile Development
5.4 Extreme Programming
5.4.1 The XP process
5.5 Other Agile process Models
5.5.1 Scrum
Test-Driven Development in the Corporate WorkplaceAhmed Owian
What is TDD, and why is it giving traditional software development practices a run for their money? This presentation answers these questions, while focusing on a popular agile methodology, Extreme Programming (XP). It places a particular emphasis on the exploratory programming nature of XP and its testing practice, TDD. The paper also summarizes prior research on TDD and includes the results from a research survey conducted to compare TDD with traditional testing practices.
Reducing Technical Debt: Using Persuasive Technology for Encouraging Software...Hayim Makabee
Technical debt is a metaphor for the gap between the current state of a software system and its hypothesized ‘ideal’ state. One of the significant and under-investigated elements of technical debt is documentation debt, which
may occur when code is created without supporting internal documentation, such as code comments. Studies have shown that outdated or lacking documentation is a considerable contributor to increased costs of software
systems maintenance. The importance of comments is often overlooked by software developers, resulting in a notably slower growth rate of comments compared to the growth rate of code in software projects. This research aims to explore and better understand developers’ reluctance to document code, and accordingly to propose efficient ways of using persuasive technology to
encourage programmers to document their code. The results may assist software practitioners and project managers to control and reduce documentation debt.
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
Overview of the paper "Visual Software Evolution Reconstruction" by Marco D'Ambros and Michele Lanza presented at Oregon State University for "Information Visualization" class on May 12th 2014. Presentation time: 15 min
Introduction to Software Engineering for Undergraduate students. it relates SW Engineering topics to actual work environment, with an example of job announcement for software engineer
Testing a software product is an essential part of the development process. The tests have the goal to improve/optimize defined quality attributes of the product. Unfortunately, sometimes software is developed based on the needs of a single programmer or just because a recent technology enables new product developments, and later—once a prototype is available—the question arises for whom this product might be interesting. In such cases, it is difficult to develop the appropriate requirements that best fit the needs of the final user.
In this talk we describe a personas-driven testing approach, which derives personas based on an initial product idea. Based on the derived personas, we define requirements and tests to guide the further development of the product.
The talk will present a case study in which we applied the method: from the initial prototype, we derive four personas that use the prototype in various ways, we extract requirements and tests.
When you work in a small collocated team many engineering practices and approaches are relatively easy to use and adapt. In large project with many teams working on the same product this task is not so simple. I want to share experience report in implementing Code Review practice in big product development team (more than 150 people, 10+ feature teams). In this talk we will review what approaches works in such setup and what don’t work, what tools and additional practices are needed to support Code Review and make it more effective, what difficulties and blockers will you probably see in the real life cases, what useful metrics could be produced by this practice.
E Roger Pressman Bruce Maxim Software Engineering_ A Practitioner's Approach 8e.
Chapter 5:
5.1 What is Agility?
5.3 What is an Agile Process?
5.3.1 Agility Principles.
5.3.2 The Politics of Agile Development
5.4 Extreme Programming
5.4.1 The XP process
5.5 Other Agile process Models
5.5.1 Scrum
Test-Driven Development in the Corporate WorkplaceAhmed Owian
What is TDD, and why is it giving traditional software development practices a run for their money? This presentation answers these questions, while focusing on a popular agile methodology, Extreme Programming (XP). It places a particular emphasis on the exploratory programming nature of XP and its testing practice, TDD. The paper also summarizes prior research on TDD and includes the results from a research survey conducted to compare TDD with traditional testing practices.
Reducing Technical Debt: Using Persuasive Technology for Encouraging Software...Hayim Makabee
Technical debt is a metaphor for the gap between the current state of a software system and its hypothesized ‘ideal’ state. One of the significant and under-investigated elements of technical debt is documentation debt, which
may occur when code is created without supporting internal documentation, such as code comments. Studies have shown that outdated or lacking documentation is a considerable contributor to increased costs of software
systems maintenance. The importance of comments is often overlooked by software developers, resulting in a notably slower growth rate of comments compared to the growth rate of code in software projects. This research aims to explore and better understand developers’ reluctance to document code, and accordingly to propose efficient ways of using persuasive technology to
encourage programmers to document their code. The results may assist software practitioners and project managers to control and reduce documentation debt.
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
EMPLOYERS’ NEEDS FOR COMPUTER SCIENCE, INFORMATION TECHNOLOGY AND SOFTWARE EN...ijcseit
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
EMPLOYERS’ NEEDS FOR COMPUTER SCIENCE, INFORMATION TECHNOLOGY AND SOFTWARE EN...ijcseit
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
EMPLOYERS’ NEEDS FOR COMPUTER SCIENCE, INFORMATION TECHNOLOGY AND SOFTWARE EN...ijcseit
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
Requirement engineering is a key ingredient for software development to be effective. Apart from the
traditional software requirement which is not much appropriate for new emerging software such as smart
handheld device based software. In many perspectives of requirement engineering, traditional and new
emerging software are not similar. Whereas requirement engineering of traditional software needs more
research, it is obvious that new emerging software needs methodically and in-depth research for improved
productivity, quality, risk management and validity. In particular, the result of this paper shows that how
effective requirement engineering can improve in project negotiation, project planning, managing feature
creep, testing, defect, rework and product quality. This paper also shows a new methodology which is
focused on users work process applicable for eliciting the requirement of traditional software and any new
type software of smart handheld device such as iPad. As an example, the paper shows how the methodology
will be applied as a software requirement of iPad-based software for play-group students.
An Agile Software Development FrameworkWaqas Tariq
Agility in software projects can be attained when software development methodologies attain to external factors and provide a framework internally for keeping software development projects focused. Developer practices are the most important factor that has to cope with the challenges. Agile development assumes a project context where the customer is actively collaborating with the development team. The greatest problem agile teams face is too little involvement from the customer. For a project to be agile, the developers have to cope with this lack of collaboration. Embracing changing requirements is not enough to make agile methods cope with business and technology changes. This paper provides a conceptual framework for tailoring agile methodologies to face different challenges. The framework is comprised of three factors, namely, developer practices, customer collaboration, and predicting change
Distributed Software Development Process, Initiatives and Key Factors: A Syst...zillesubhan
Geographically Distributed Software Development (GSD) process differs from Collocated Software Development (CSD) process in various technical aspects. It is empirically proven that renowned process improvement initiatives applicable to CSD are not very effective for GSD. The objective of this research is to review the existing literature (both academia and industrial) to identify initiatives and key factors which play key role in the improvement and maturity of a GSD process, to achieve this goal we planned a Systematic Literature Review (SLR) following a standard protocol. Three highly respected sources are selected to search for the relevant literature which resulted in a large number of TOIs (Title of Interest). An inter-author custom protocol is outlined and followed to shortlist most relevant articles for review. The data is extracted from this set of finally selected articles. We have performed both qualitative and quantitative analysis of the extracted data to obtain the results. The concluded results identify several initiatives and key factors involved in GSD and answer each research question posed by the SLR.
Software Project Documentation - An Essence of Software DevelopmentEswar Publications
Software documentation is a critical attribute of both software projects and software engineering in general.
Documentation is considered as a media of communication among the parties involved during software development as
well the one who will be using the software. It consists of written particulars concerning software specifications as well as what it does, in which manner it accomplishes the specified details and even how to exercise it. In this paper, we tried to focus on the role of documentation in software projects.
Quantitative And Qualitative Evaluation Of F/Oss Volunteer Participation In D...ijseajournal
Free/Open Source Software (F/OSS) is an incredible and innovative opportunity of software development
in the area of software engineering. An F/OSS project evolves by receiving submissions from various
sources to address different aspects of the project like bug identification, feature request, support request,
translation request, source code, documentation etc. The present paper delves into a multi-case study of
F/OSS projects to evaluate volunteer participation in defect management quantitatively as well as
qualitatively. The relevant defect data has been retrieved from a research collaboratory. It is found that
generally a small core team is surrounded by a large community of volunteers participating in defects. It is
observed that defect reporting is a widely dispersed activity mostly contributed by volunteers external to
core team making occasional contribution while defect resolution is concentrated among a few individuals
mainly from core team making regular contribution.
Appendix AProof of effectiveness of some of the agile methods us.docxarmitageclaire49
Appendix A
Proof of effectiveness of some of the agile methods used to develop systems requirements
In all software development methodologies, the process of collecting, understanding and managing all requirements for a system is a crucial process in software development. Similar to all this other methods, agile methods are not exceptional. Most agile method handle requirements in order to implement them as much accurately as possible to satisfy all the customer demands. This is usually achieved by maintaining a continuous interaction with the customers to address their needs according to priority and functionalities. In this appendix, we shall be focusing on continuous process of improving the development process.
Some agile methods include the following
1. eXtreme Programming (XP) – it improves a software project in communication, simplicity, feedback and courage.
2. scrum- this is an agile, iterative and incremental method which takes care of all changes that may come across in the life-cycle of the project. Basically, it adds energy, focus and clarity to development teams. Its major aim is ot see the whole system being a successful product.
3. Dynamic system, development method (DSDM)
4. Adaptive software development (ASD)- this is a development process that is a product of rapid application development. It has four phases of communication and planning, analysis, testing & deployment and design and deployment.
5. the crystal family
Due to availability of these various methods, the potential adopters may experience a challenge of determining what to apply on its own and therefore there was need to define a document containing all the necessary values and common qualities to be used across all agile methods. This document is the Agile Manifesto and focuses mainly on human interactivity and processes management.
1. Individual and interaction over various processes and tasks. Usually the agile process will focus more on people and their interactivity but not on the structural processes and tools.
2. Working software and documentation. Main objective of the developers is actually delivering a functional code which will always add value to our users. Well documented code is always self-documented.
3. Responding to change over planning. Here developers are required to respond very fast to the requirements variations. Time used in planning is minimal compared to what our users actually requires.
4. Customer collaboration over contracts. The mutual relationship of the developers and susers of our system is monitored and regulated through engaging the customer in the development process.
The figure below shows the steps in agile methodologies which focus on an iteration and adaptable change.
5.
Tools needed for requirement management in agile methods of system development.
1. The most popular tools in agile methods include paper, pencil a drawing pin board. If we consider eXtreme programming requirements are obtained from user stories which ar.
Survey on adverse influencing factors in the way of successful requirement en...iosrjce
IOSR Journal of Computer Engineering (IOSR-JCE) is a double blind peer reviewed International Journal that provides rapid publication (within a month) of articles in all areas of computer engineering and its applications. The journal welcomes publications of high quality papers on theoretical developments and practical applications in computer technology. Original research papers, state-of-the-art reviews, and high quality technical notes are invited for publications.
Requirement Elicitation Model (REM) in the Context of Global Software Develop...IJAAS Team
Contxext:Requirement elicitation is difficult and critical phase of requirement engineering and the case is worst in global software development (GSD). The study is about requirement elicitation in the context of GSD. Objective: Development of requirement elicitation model (REM) which can address the factors that have positive impact and the factors that have negative impact during elicitation in GSD. The propose model will give solutions and practices to the challenges during elicitation. Method: Systematic literature review (SLR) and empirical research study will be used for achieving the goals and objectives. Expected outcomes: The expected results of this study will be REM that will help vendor organizations for better elicitation during GSD.
A guide to deal with uncertainties in software project managementijcsit
Various project management approaches do not consider the impact that uncertainties have on the project.
The identified threats by uncertainty in a projec day-to-day are real and immediate and the expectations in
a project are often high. The project manager faces a dilemma: decisions must be made in the present
about future situations which are inherently uncertain. The use of uncertainty management in project can
be a determining factor for the project success. This paper presents a systematic review about uncertainties
management in software projects and a guide is proposed based on the review. It aims to present the best
practices to manage uncertainties in software projects in a structured way including techniques and
strategies to uncertainties containment.
Networking is overrated! You must invest in your Reputation!
Speaker: Hayim Makabee, CTO at Dooiu
In this talk Hayim will share useful guidelines about how to manage and develop your personal reputation.
Hayim will focus on providing practical advice about how to create opportunities by generating value to the people in your professional network.
In general the goal of networking is to create new opportunities. These may be business opportunities, partnership opportunities or job opportunities. But what really creates new opportunities is our reputation.
Having a good reputation means that:
People will remember you. They will remember you for many years since they had the last interaction with you.
People will recommend you. They will introduce you to their own contacts whenever they think you may contribute.
People will constantly offer you new opportunities. They will invite you when they have a job opening, or when they need a partner or an adviser.
About the speaker:
Hayim Makabee is the CTO of Dooiu, an innovative Social Fintech. Hayim has over 25 years of experience in the Israeli high-tech industry, having held leadership roles as a Software Architect and Machine Learning specialist. He is also a mentor at Gvahim, where he helps new Olim to develop their professional careers in Israel. Hayim holds a M.Sc. in Computer Science from Technion and is the author of a book and several scientific publications.
About Dooiu:
Dooiu is a platform from which two or more people can make calls and exchange knowledge for money. Dooiu is a solution for communicating to each other and making payments in a simple and clear way. It allows those who sell their time as teachers, consultants, or experts to increase their income and grow professionally. Also, it enables any person who wants to consult on any topic to pay a fair price for the services received.
Applications of Machine Learning - INDT WebinarHayim Makabee
INDT Webinar about Applications of Machine Learning.
In these slides Hayim Makabee presents several applications of Machine Learning and their impact on our lives, including Recommender Systems and Autonomous Vehicles, with several examples of recent innovations in the fields of Industry, Health and Agriculture.
In these slides Hayim Makabee presents several applications of Machine Learning and their impact on our lives, including Recommender Systems and Autonomous Vehicles.
In these slides Hayim Makabee explains how we applied the Blue Ocean Strategy to plan the main features of the KashKlik platform and its business model.
Managing your Reputation Gvahim WebinarHayim Makabee
Useful guidelines about how to manage and develop your personal reputation. Practical advice about how to create opportunities by generating value to the people in your professional network. Presented by Hayim Makabee as a Gvahim Webinar on June 2020.
Useful guidelines about how to manage and develop your personal reputation. Practical advice about how to create opportunities by generating value to the people in your professional network.
The Story of a Young Oleh (Immigrant in Israel)Hayim Makabee
The Story of a Young Oleh (Immigrant in Israel) by Hayim Makabee
Presentation prepared for the Taglit groups (August 2018)
Taglit-Birthright Israel, also known as Birthright Israel or simply Birthright, is a not-for-profit educational organization that sponsors free ten-day heritage trips to Israel for young adults of Jewish heritage, aged 18–32.
Software Architecture for Agile DevelopmentHayim Makabee
Slides of a workshop given at Herzliya on June/2017, organized by ILTAM and IASA Israel. This workshop was dedicated to the topic of Software Architecture in the context of Agile Development. We answered the question: “How much Design Up Front should be done in an Agile project?” Hayim presented his approach of Adaptable Design Up Front (ADUF), describing its rationale, applications in practice and comparison to other approaches such as Emergent Design. He explained why adaptability is essential for the development of complex software systems using Agile methods. The concepts were illustrated through practical software architecture approaches such as micro-services and examples of real software systems that were developed in the past. The workshop also included an exercise on the definition and evolution of the design of an interesting system.
Adaptable Designs for Agile Software DevelopmentHayim Makabee
Abstract: This talk introduces the concept of Adaptable Software Design, and explains why adaptability is essential for the development of complex software systems using Agile methods. The concepts are illustrated through practical software architecture approaches such as micro-services.
The concept of Antifragility was introduced by Nassim Taleb to describe systems that benefit from impacts and volatility.
In this talk we will discuss how this concept may be applied in the field of Software Design with the goal of developing Change-Resilient Systems.
In particular we will address two patterns which frequently appear in Antifragile systems:
1) The Barbell Strategy and the importance of the separation between high-level abstract elements and concrete implementation details.
2) The Componentization Strategy and its applications in SOA, Microservices and Software Product Lines.
The SOLID Principles Illustrated by Design PatternsHayim Makabee
The goal of the SOLID design principles is to improve the Separation of Concerns, through weaker Coupling and stronger Cohesion. The main consequence should be software systems that are easier to maintain and to extend. However the definition of the SOLID principles is quite abstract, and some developers find it difficult to apply them in practice. In my talk I will show how well-known Design Patterns illustrate the application of the SOLID principles, and also show examples of how to follow these principles to Refactor and improve existing designs.
About the speaker:
Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems and Genetic Algorithms.
The quality of software systems may be expressed as a collection of Software Quality Attributes. When the system requirements are defined, it is essential also to define what is expected regarding these quality attributes, since these expectations will guide the planning of the system architecture and design.
Software quality attributes may be classified into two main categories: static and dynamic. Static quality attributes are the ones that reflect the system’s structure and organization. Examples of static attributes are coupling, cohesion, complexity, maintainability and extensibility. Dynamic attributes are the ones that reflect the behavior of the system during its execution. Examples of dynamic attributes are memory usage, latency, throughput, scalability, robustness and fault-tolerance.
Following the definitions of expectations regarding the quality attributes, it is essential to devise ways to measure them and verify that the implemented system satisfies the requirements. Some static attributes may be measured through static code analysis tools, while others require effective design and code reviews. The measuring and verification of dynamic attributes requires the usage of special non-functional testing tools such as profilers and simulators.
In this talk I will discuss the main Software Quality attributes, both static and dynamic, examples of requirements, and practical guidelines on how to measure and verify these attributes.
Title: The Role of the Software Architect
Speaker: Hayim Makabee, co-founder of the Israeli Chapter of the International Association of Software Architects (IASA)
Abstract:
In this talk Hayim will present the practical aspects of the role of the Software Architect, including:
- The four areas of expertise: Design, Domain, Technology and Methodology.
- The cooperation with stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.
Understanding the expected areas of expertise is essential for the architect to develop his/her professional skills.
Understanding how to cooperate with the diverse stakeholders is essential to improve the architect's impact and effectiveness.
In the context of Iterative Software Development, we ask the question: How much design should be done "up front"?
We propose the approach of Adaptable Design Up Front, which focuses on capturing the essential aspects of the system and plans for extensibility and adaptability.
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
Exploring Innovations in Data Repository Solutions - Insights from the U.S. G...Globus
The U.S. Geological Survey (USGS) has made substantial investments in meeting evolving scientific, technical, and policy driven demands on storing, managing, and delivering data. As these demands continue to grow in complexity and scale, the USGS must continue to explore innovative solutions to improve its management, curation, sharing, delivering, and preservation approaches for large-scale research data. Supporting these needs, the USGS has partnered with the University of Chicago-Globus to research and develop advanced repository components and workflows leveraging its current investment in Globus. The primary outcome of this partnership includes the development of a prototype enterprise repository, driven by USGS Data Release requirements, through exploration and implementation of the entire suite of the Globus platform offerings, including Globus Flow, Globus Auth, Globus Transfer, and Globus Search. This presentation will provide insights into this research partnership, introduce the unique requirements and challenges being addressed and provide relevant project progress.
top nidhi software solution freedownloadvrstrong314
This presentation emphasizes the importance of data security and legal compliance for Nidhi companies in India. It highlights how online Nidhi software solutions, like Vector Nidhi Software, offer advanced features tailored to these needs. Key aspects include encryption, access controls, and audit trails to ensure data security. The software complies with regulatory guidelines from the MCA and RBI and adheres to Nidhi Rules, 2014. With customizable, user-friendly interfaces and real-time features, these Nidhi software solutions enhance efficiency, support growth, and provide exceptional member services. The presentation concludes with contact information for further inquiries.
May Marketo Masterclass, London MUG May 22 2024.pdfAdele Miller
Can't make Adobe Summit in Vegas? No sweat because the EMEA Marketo Engage Champions are coming to London to share their Summit sessions, insights and more!
This is a MUG with a twist you don't want to miss.
Into the Box Keynote Day 2: Unveiling amazing updates and announcements for modern CFML developers! Get ready for exciting releases and updates on Ortus tools and products. Stay tuned for cutting-edge innovations designed to boost your productivity.
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
Check out the webinar slides to learn more about how XfilesPro transforms Salesforce document management by leveraging its world-class applications. For more details, please connect with sales@xfilespro.com
If you want to watch the on-demand webinar, please click here: https://www.xfilespro.com/webinars/salesforce-document-management-2-0-smarter-faster-better/
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Mind IT Systems
Healthcare providers often struggle with the complexities of chronic conditions and remote patient monitoring, as each patient requires personalized care and ongoing monitoring. Off-the-shelf solutions may not meet these diverse needs, leading to inefficiencies and gaps in care. It’s here, custom healthcare software offers a tailored solution, ensuring improved care and effectiveness.
Quarkus Hidden and Forbidden ExtensionsMax Andersen
Quarkus has a vast extension ecosystem and is known for its subsonic and subatomic feature set. Some of these features are not as well known, and some extensions are less talked about, but that does not make them less interesting - quite the opposite.
Come join this talk to see some tips and tricks for using Quarkus and some of the lesser known features, extensions and development techniques.
First Steps with Globus Compute Multi-User EndpointsGlobus
In this presentation we will share our experiences around getting started with the Globus Compute multi-user endpoint. Working with the Pharmacology group at the University of Auckland, we have previously written an application using Globus Compute that can offload computationally expensive steps in the researcher's workflows, which they wish to manage from their familiar Windows environments, onto the NeSI (New Zealand eScience Infrastructure) cluster. Some of the challenges we have encountered were that each researcher had to set up and manage their own single-user globus compute endpoint and that the workloads had varying resource requirements (CPUs, memory and wall time) between different runs. We hope that the multi-user endpoint will help to address these challenges and share an update on our progress here.
Unleash Unlimited Potential with One-Time Purchase
BoxLang is more than just a language; it's a community. By choosing a Visionary License, you're not just investing in your success, you're actively contributing to the ongoing development and support of BoxLang.
Enterprise Resource Planning System includes various modules that reduce any business's workload. Additionally, it organizes the workflows, which drives towards enhancing productivity. Here are a detailed explanation of the ERP modules. Going through the points will help you understand how the software is changing the work dynamics.
To know more details here: https://blogs.nyggs.com/nyggs/enterprise-resource-planning-erp-system-modules/
Enhancing Research Orchestration Capabilities at ORNL.pdfGlobus
Cross-facility research orchestration comes with ever-changing constraints regarding the availability and suitability of various compute and data resources. In short, a flexible data and processing fabric is needed to enable the dynamic redirection of data and compute tasks throughout the lifecycle of an experiment. In this talk, we illustrate how we easily leveraged Globus services to instrument the ACE research testbed at the Oak Ridge Leadership Computing Facility with flexible data and task orchestration capabilities.
Understanding Globus Data Transfers with NetSageGlobus
NetSage is an open privacy-aware network measurement, analysis, and visualization service designed to help end-users visualize and reason about large data transfers. NetSage traditionally has used a combination of passive measurements, including SNMP and flow data, as well as active measurements, mainly perfSONAR, to provide longitudinal network performance data visualization. It has been deployed by dozens of networks world wide, and is supported domestically by the Engagement and Performance Operations Center (EPOC), NSF #2328479. We have recently expanded the NetSage data sources to include logs for Globus data transfers, following the same privacy-preserving approach as for Flow data. Using the logs for the Texas Advanced Computing Center (TACC) as an example, this talk will walk through several different example use cases that NetSage can answer, including: Who is using Globus to share data with my institution, and what kind of performance are they able to achieve? How many transfers has Globus supported for us? Which sites are we sharing the most data with, and how is that changing over time? How is my site using Globus to move data internally, and what kind of performance do we see for those transfers? What percentage of data transfers at my institution used Globus, and how did the overall data transfer performance compare to the Globus users?
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxrickgrimesss22
Discover the essential features to incorporate in your Winzo clone app to boost business growth, enhance user engagement, and drive revenue. Learn how to create a compelling gaming experience that stands out in the competitive market.
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...informapgpstrackings
Keep tabs on your field staff effortlessly with Informap Technology Centre LLC. Real-time tracking, task assignment, and smart features for efficient management. Request a live demo today!
For more details, visit us : https://informapuae.com/field-staff-tracking/
How Recreation Management Software Can Streamline Your Operations.pptxwottaspaceseo
Recreation management software streamlines operations by automating key tasks such as scheduling, registration, and payment processing, reducing manual workload and errors. It provides centralized management of facilities, classes, and events, ensuring efficient resource allocation and facility usage. The software offers user-friendly online portals for easy access to bookings and program information, enhancing customer experience. Real-time reporting and data analytics deliver insights into attendance and preferences, aiding in strategic decision-making. Additionally, effective communication tools keep participants and staff informed with timely updates. Overall, recreation management software enhances efficiency, improves service delivery, and boosts customer satisfaction.
How Recreation Management Software Can Streamline Your Operations.pptx
To document or not to document? An exploratory study on developers' motivation to document code
1. To document or not to document? An exploratory study
on developers' motivation to document code
Yulia Shmerlin1
, Irit Hadar1
, Doron Kliger2
, Hayim Makabee3
1
Information Systems Department, University of Haifa, Haifa, Israel
2
Economics Department, University of Haifa, Haifa, Israel
3
Yahoo! Research Labs, Haifa, Israel
{yshmerlin, hadari}@is.haifa.ac.il, kliger@econ.haifa .ac.il, makabee@yahoo-inc.com
Abstract. Technical debt represents the situation in a project where developers
accept compromises in one dimension of a system in order to meet urgent de-
mands in other dimensions. These compromises incur a “debt”, on which “inter-
est” has to be paid to maintain the long-term health of the project. One of the
elements of technical debt is documentation debt due to under-documentation of
the evolving system. In this exploratory study, our goal is to examine the different
aspects of developers' motivation to document code. Specifically, we aim to iden-
tify the motivating and hindering aspects of documentation as perceived by the
developers. The motivating aspects of code documenting we find include improv-
ing code comprehensibility, order, and quality. The hindering aspects include de-
velopers’ perception of documenting as a tedious, difficult, and time consuming
task that interrupts the coding process. These findings may serve as a basis for
developing guidelines toward improving documentation practices and encourag-
ing developers to document their code thus reducing documentation debt.
Keywords: Documentation, technical debt, motivation
1 Introduction
Technical debt is a metaphor describing a situation where long-term code quality is
traded for short-term gain, creating future pressure to remediate the expedient [2]. Some
technical-debt inducing elements are code-related and some are not. Documentation
debt [15] is one of the elements of technical debt; this form of debt occurs when soft-
ware products lack the necessary internal documentation. A detailed review of technical
debt and documentation debt can be found at [11].
Documentation contributes to understanding of [4], and communicating about, the
software system, thus making it more maintainable. Maintenance is known to be a sub-
stantial, as well as the most expensive, part in the software lifecycle [9]. Lacking and
outdated documentation is one of the main causes of the high cost of software mainte-
nance [8]; in other words, inappropriate documentation creates a technical debt to be
redeemed, with interest, in the maintenance phase.
Despite the importance of code documentation, studies show that code comments
are often neglected relatively to code development [6]. There may be several reasons
2. for this phenomenon: external, referring to the work environment, and internal, refer-
ring to the programmers themselves. For instance, an external reason could be that prac-
titioners often work under very strict deadlines and therefore choose to leave the docu-
mentation behind, and an internal reason, that documenting is not perceived a creative
activity, thus developers prefer solving algorithmic problems over writing documenta-
tion [2]. An additional internal reason related to developers' lack of motivation to doc-
ument is that not documenting behavior in some cases may promote job security [5].
The internal explanations may indicate that there are additional motivation-related
factors that cause developers' reluctance to document their code. Therefore, we believe
that it is important to investigate these factors further, as it will allow proposing effec-
tive solutions for encouraging documentation. This research aims to explore and better
understand developers' motivation for code documenting. Specifically, our research
question is: "What are the motivating and the hindering aspects that can influence de-
velopers’ code documenting behavior?"
The rest of the paper is organized as follows: section 2 presents related works with
regard to different aspects of documentation; section 3 focuses on the research method
of our ongoing research, with the preliminary findings presented in section 4. We dis-
cuss these findings and our future research directions in section 5.
2 Related Work
Software documentation refers to several types of documents, which accompany the
development process; for example, documents describing requirements, design, mar-
keting demands, end-user manuals, and technical documentation. The latter is docu-
mentation of code, algorithms, and interfaces, which is very important for understand-
ing software programs [14].
Code is not documented enough in practice, despite the high, agreed upon, im-
portance of code documentation, and specifically software engineers’ understanding of
its importance [14]. Moreover, the growth rate of code tends to be much higher than
the growth rate of comments, because developers’ tendency to neglect documenting
newly added code [6].
In agile development, face-to-face conversations are considered the most efficient
and effective method of conveying information and documentation is often paid less
attention. However, over half of the developers in agile development teams find docu-
mentation to be important or even very important while, at the same time, too little
documentation is available in their projects [12].
One of the reasons for the scarcity of documentation seems to be the lack of devel-
opers’ motivation to document their code. The Fogg Behavior Model (FBM) [7] sug-
gests that behavior depends on the following three factors: motivation, ability, and trig-
gers, each of which has several subcomponents. The motivation factor consists of three
core motivators, each of which having two sides: pleasure vs. pain, hope vs. fear and
social acceptance vs. rejection. In our ongoing research, we aim to address the three
factors of FBM. The current paper is a starting point, in which we focus on the motiva-
tion factor. To encourage documentation, a triggering environment has to be devised,
in which developers’ motivation will be channeled toward enhanced documentation. In
3. addition, the devised environment should also boost developers’ ability to document in
an efficient and informative manner.
Several research works have focused on investigating motivating and de-motivating
aspects in software engineering in general. Two of the main models that refer to soft-
ware developers' motivation are the job characteristics model, and the model of task
design [10]. These models examine the motivation for the software development pro-
fession as a whole [1]. However, as far as we know, no such model was proposed in
the context of code documentation, despite the evidence for its importance on the one
hand, and the relatively little attention it receives in practice on the other hand.
3 Method
The goal of this study is to explore and better understand what influences developers'
motivation for code documenting. Data collection and analysis were performed using
qualitative research methods based on the grounded theory research principles [13].
The research consists of three stages, planned according to its exploratory nature.
First, in order to gain an initial understanding of the problem, we conducted five in-
depth interviews. Second, based on the results of the interviews, we developed a pilot
questionnaire and distributed it among ten additional participants. Third, yet to be ac-
complished, stage, is a refinement of the questionnaire toward large-scale distribution.
The results reported here are based on the preliminary findings obtained in the first two
stages.
The participants of the study were software developers with various seniority levels,
with at least two years of development experience, employed in different software
firms. We interviewed five software developers (three women and two men). We used
semi-structured interviews, which consisted of predefined open questions, and also al-
lowed time for free discussion. The interviews, as well as the later constructed ques-
tionnaire, consisted of two types of questions: open-ended questions regarding motiva-
tion to document and background questions. Ten developers (two women and eight
men), with an average experience of about 7 years, filled in the pilot questionnaire. The
data elicited were inductively analyzed, classifying answers to emergent categories in
the investigated topics: motivating and hindering aspects of documentation.
4 Findings
Table 1 describes categories that emerged from the analysis of the answers regarding
the motivating aspects of code documenting. Specifically, we asked: “What do you
enjoy when documenting your code?"
Three participants did not provide any motivating aspects of documentation. One
jokingly answered: "the suffering," another asked with wonder: "enjoy?" and the third
replied: "Odd question... nothing. It's part of the job."
In order to identify the hindering aspects of documenting, we asked the participants:
“What don't you enjoy when documenting your code?” The categories that emerged
from the analysis of the answers are presented in Table 2.
4. In addition, we wanted to check whether peer or management feedback and com-
pany policy play a role in developers' motivation to document. For this purpose, we
asked the participants whether they recalled receiving positive or negative feedbacks
regarding documentation on code they had developed, or general instructions regarding
documentation.
Table 1. Categories of motivating aspects of documentation
Category Example
Increases code
comprehensibility
“Documenting the code helps me to better understand my own work."
"Makes it [the code] more readable, easier to understand later on for
me and for other people that look at the code.”
“It's useful when the code is complex and there is no good refactoring.
When going over the code, it [documentation] helps to remember.”
Increases order “It helps to keep things in order.”
"Adds more structure to the code."
Increases code
quality
"It [Documenting] helps to organize my thoughts. I find that this
[practice] is directly related to TDD- if you write comments prior to
the coding [instead of the tests as in TDD] before the code, it helps to
develop better code".
"Good documentation shows that your work was done perfectly."
Table 2. . Categories of hindering aspects of documentation
Four out of the ten questionnaire respondents replied that they had never received
any feedback on their documentation when participating in code reviews. The other six
participants recalled receiving positive feedbacks to documentation on the code they
had developed. For example: "Yes, [I was told] that it helped them [the colleagues] to
understand my code." Only two participants recalled receiving negative feedbacks on
their documentation, for example, that the documentation was not detailed enough.
All ten participants answered that that their company does not have a strict policy
regarding documentation, and one respondent mentioned an informal policy: "We [the
developers] are advised to document our code and our manager reminds us about it."
One of the developers stated that in his opinion, "being forced" to document by com-
pany policy would not be effective. "Most of the developers are creative people and do
Category Example
Tedious task "To explain complicated issues - why this was done in a particular way."
"To explain what each parameter does.”
"This [documentation] is no fun, because I solved the problem already."
Difficult task " To be formal",
"Sometimes it [documenting] is difficult, because I do not know how to
explain the change. For example, I entered a fix reusing a feature that
worked in a different place in the code."
Interruption of
coding
"Breaks the continuity of coding;"
"Documenting is difficult to do retroactively, after you had written the
method, because you think it is self-explanatory and that it is quite
obvious how it works."
Time constraints "It [documentation] takes time."
"When I have a tight deadline, documenting is left behind."
5. not like being told how to do their job". These results further emphasize the need to
focus on internal motivation of developers in order to encourage them to document,
which may be more effective than external ones.
5 Discussion and Future Work
Our study aimed to identify the aspects that influence developers' motivation to docu-
ment, as a first step toward meeting the objective of our ongoing research to increase
developers’ motivation and performance of documentation activities. The results of this
study indicate that developers are often aware of the importance of documentation,
which corresponds with previous findings[14]. However, commensurate with other pre-
vious studies, code documentation is often overlooked in practice [6].
We found that developers' reluctance to document is related to their perception of
the task of documenting as tedious, difficult and distracting from the main task of cod-
ing as well as being time consuming; however, most of them could find motivating
aspects as well. Accordingly, we contend that emphasizing the motivating aspects of
documentation tasks, for example the documentation contribution of the developers’
understanding and promoting the quality of their own code, and masking the hindering
aspects thereof, for example by making this a less tedious task, would allow devising a
solution that would increase developers' motivation to document.
These findings should be carefully considered, given the limitations of the study.
For example, our findings indicate that a motivating aspect of code documentation is
improving code comprehensibility. In this context, it is worth mentioning that the fact
that documentation promotes code understanding may also serve as a de-motivator to
documentation, for example, when producing unclear code promotes job security [5].
Noteworthy, this de-motivating reason did not appear in our findings. The absence of
evidence regarding such de-motivating reasons could indicate either that our partici-
pants do not subscribe to these reasons, or it could possibly reflect responders’ strategy
to withhold such ‘selfish’ reasons, a limitation rooted in our use of self-reporting meth-
ods for data collection.
As for hindering aspects of documenting, the participants stated that they do not
enjoy the writing process itself, and that code documenting breaks the continuity of
coding. Moreover, code documenting requires time, which is often a scarce resource in
developers' daily work. Time constraints were mentioned as a hindering aspect of doc-
umentation; however, the presence of this aspect in the interviews and questionnaires
was not as dominant as we had expected. This may indicate that the lack of documen-
tation in practice is mainly a result of developers’ perception of this task as not enjoy-
able, rather than it being time consuming, as perhaps is commonly believed.
The results confirm that currently there is a lack of motivation among developers to
document. Recall that motivation is a key factor upon which behavior is dependent
according to the FBM model [7]. Thus, we believe that our findings are an important
step in order to develop a solution that will encourage developers to document their
code.
This study has several limitations. First, our sample consists of Israeli participants
only. It is possible that cultural factors are related to motivational issues, and this study
has to be replicated on populations from different cultures. The full-scale survey will
focus on recruiting a large number of participants from different parts of the globe and
6. from different cultures. Second, our data gathering tools were interviews and question-
naires, and relied on self-reports of the participants; the data may therefore reflect self-
serving bias, to some extent.
In the next step of the research, we plan to distribute a survey for further validation
and extension of our findings. Subsequently, a solution will be sought using motiva-
tions theories for increasing developers' motivation to document their code.
References
[1] Beecham, S, Baddoo, N., Hall, T, Robinson, H., Sharp, H.: Motivation in Software
Engineering: A systematic literature review. Information and Software Technology, 50(9),
860-878 (2008)
[2] Clear, T.: Documentation and agile methods: striking a balance. ACM SIGCSE Bulletin,
35(2), 12-13(2003)
[3] Cunningham, W.: The WyCash portfolio management system. ACM SIGPLAN OOPS
Messenger 4(2) , 29-30 (1992)
[4] De Souza, S. C. B., Anquetil, N., De Oliveira, K. M.: A study of the documentation essential
to software maintenance. In: Proceedings of the 23rd annual international conference on
Design of communication: documenting & designing for pervasive information, pp. 68-75,
ACM (2005)
[5] Drevik, S.: How to comment code. Embedded Systems Programming 9, 58-65, (1996)
[6] Fluri, B., Wursch, M., Gall, H. C.: Do code and comments co-evolve? On the relation
between source code and comment changes. In Reverse Engineering 14th Working
Conference, 70-79. IEEE. (2007)
[7] Fogg, B. J.: A behavior model for persuasive design. In Proceedings of the 4th ACM Int.
Conference on Persuasive Technology, (2009)
[8] Martin, J., McClure, C.: Software Maintenance. The Problem and the Solutions. Prentice
Hall (1983)
[9] Seacord, R.C., Plakosh, D.A.: Modernizing legacy systems: software technologies,
engineering processes, and business practices. Addison-Wesley Professional (2003)
[10] Sharp, H., Baddoo, N., Beecham, S., Hall, T., Robinson, H.: Models of motivation in
software engineering. Information and Software Tech,51(1), 219-233, (2009)
[11] Shmerlin, Y., Kliger, D., Makabee, H.: Reducing Technical Debt: Using Persuasive
Technology for Encouraging Software Developers to Document Code. In Advanced
Information Systems Engineering Workshops. Springer International Publishing, 207-212,
(2014)
[12] Stettina, C.J., Heijstek, W.: Necessary and neglected? An empirical study of internal
documentation in agile software development teams. In Proceedings of the 29th ACM
international conference on Design of communication, 159-166, ACM, (2011)
[13] Strauss, A., Corbin, J. M.: Basics of qualitative research: Grounded theory procedures and
techniques. Sage Publications, (1990)
[14] Tenny, T.: Program readability: Procedures versus comments. Software Engineering, IEEE
Transactions on, 14(9), 1271-1279, (1988)
[15] Tom, E., Aurum, A., Vidgen, R.: An exploration of technical debt. Journal of Systems and
Software, 1498-1516(2013)