Readings - Week 6

Building Collaboration into IDE's

What are the major collaborative features suggested by the authors?

Collaboration within the development environment is becoming increasingly sought after by technical team-members, allowing them to be aware of what is going on at all times and who is responsible for changes, additions or in general work throughout the lifetime of software program development. Some of the major examples used are:

1. Configuration Management - Integration reduces friction in the software development process
2. Screen Sharing - Integration promotes context in which the collaboration was done
3. Email and IM - Integration strives for traceability, allowing the content to be referenced and searched later

When looking at some of the features necessary in a collaborative IDE, one has to be careful at defining these, since many groups that work within the project adhere to different guidelines, program differently, and even use different tools for a wide variety of tasks. It is therefore imperative that the features be a global representation of what the collaborative process needs, and not what each member "wants" to have. Some of these features include:

• Provide peripheral awareness of other programmers and their activities (who is doing what around our code, especially code that you depend on).
• Support a variety of communication mechanisms (text, voice, visual).
• Integrate with the team's source-code control system and bug tracking system.
• Support "in context" communication, both synchronous (chat, screen sharing) and asynchronous (code annotations, persistent chats, team documentation).
• Support searching through saved team artifacts and the development history.
  

Assignment 2 - The Way of the Wiki - Part III

Last Post – 18 October 2007
On the 15th of October one of the users tagged my Afslaan article as copied content from the website. This was done by adding a tag into the text which automatically adds a content box into the page stating that it might be a copyright violation of the original website. After some further reading on how to negate this deletion, I deduced that you can delay deletion by adding the {{hangon}} tag to the top of the text. This inserts a template container, stating that the deletion should be delayed whilst further information and licensing is acquired. Furthermore, they request you to state why the page should not be deleted on the articles discussion (talk) page. I added the relevant request on the talk-page, stating that the information on the original Afslaan website is my work. When I was an active member in Afslaan, one of my portfolios was to create and manage a website, so all the content was originally created by myself.

Directly after these posting being made and delays put into place, I re-edited the entire article into my own words and made sure that there were no more copyright infringements. However, after visiting the article again today, I saw that it has been completely removed by a Wikipedia administrator.

I quickly reposted the article, but it was deleted again within 20 minutes of reposting. The administrator left me a message stating exactly why the page has been removed and what avenues are available to me to dispute the deletion or for possible reposts. This would involve getting the webpage administrator to grant me permission to use information on Wikipedia and also edit the original website to include for redistribution under GNU licensing v1.2 or higher. Due to time-constraints for this assignment, I unfortunately could not get the article up and running before the deadline.

My first article has also been visited and a minor change has been made. Basically a user has removed my User-tag which I added to the end of my article, as to make the article more general to Wikipedia and less personalized.

Overall, I find that Wikipedia is a good encyclopedia for posting articles, but users should KNOW the rules and understand – clearly – the licensing or respective guidelines that have to be adhered to when editing, creating and posting articles on this site. Wikipedia has a wide community which regularly keep tabs on recently created articles, false information or copyright infringements. Many of these users are just general users, who, out of their own accord, want to keep the site as relevant and truthful as possible. Many times, these users will tag articles and/or information and then administrators will be notified accordingly. The administrators then have the right to review the post and note and act according to the general rules and guidelines as set out by Wikipedia. This type of open-community editing greatly advances the overall Wikipedia standards and policies as described in my first post for this assignment.

As for the quality and value of my articles:
I have only posted two articles and an image. Both of these articles were non-existent before and my contributions were quite significant in size and quality, portraying relevant information on each topic. The articles contained truthful information from reliable sources and I personally feel that this could enlighten others who read these. I am quite disappointed that one of my articles (Afslaan) has been removed, as this was my most significant contribution, but after reading all of the guidelines, I fully understand why.Even after this assignment, I will keep a watchful eye on my articles to see how they might change and evolve in the near future.

Assignment 2 - The Way of the Wiki - Part II

Progress on First Article

After keeping a watchful eye on my first article – la Barré Family History – I saw that the article has automatically been updated by internet bots. These bots have automatically added a categorization button which states that the article has not yet been categorized and give the reader a chance to do so. Secondly, another bot has updated the page to include links to the disambiguation page. Other than those minor changes, nothing much has happened to the article in terms of extensions or major changes.

My Second Wikipedia Article

After long and arduous thought on the topic of my second article, I finally found a topic worth covering. In my first 4 years of studying, I lived in a Men’s Residence (U.S. Dormitory version) called Afslaan. I quickly searched Wikipedia for any articles related to Afslaan but found none, paving the way for a new article to be posted on the website.

I quickly started writing a article on the History of the residence and it soon transformed into a information page regarding general residence information, leadership groups, pictures and links. I used some new features from Wikipedia like organizing my article into sections. Wikipedia has a very intelligent feature which automatically adds an index to the article, should the number of sections exceed a normal page-view. This is also particularly helpful should another user wish to add information, one only needs to update the article with a new section and the index will automatically be updated to reflect the changes.

Another feature used in this article was that of a template standard. The templates are created by Wikipedia and easy to use, once you know what you are looking for. The templates provide the author a sure and secure way of adding data which should be in a standardized format.

Uploading images to the article was at first a bit confusing, but after realizing that the images work in the same way as an article, it was pretty straight-forward. Basically, if you upload a picture to an article and that image does not exist in the Wikipedia library, the link to the image turns red, just like an article which does not exist. After posting the article, I basically clicked on the red image link, set its license features and uploaded the image.

I hope to see some changes to the article in the coming days as that would mean that the article is drawing some attention from other readers.

Readings - Week 5

R. Kraut, L. Streeter: Coordination in Software Development

What characteristics of software development do cause coordination problems?

There are several characteristics within Software Development, that make coordination harder than usual, listed below are the most significant ones.

Scale
Software Developments are often so large, that all the minor complexities and intricate details are never understood by one single person. Since it is often difficult to find such a person, companies have to look for alternate routes. The size of such a project, often lead to sub-groups forming rapidly, either through social preference, borders or organizational preferences. But this leads to the groups becoming distant from one-another which in turn leads to a wider rift between the notion of sharing and cooperative work. Compartmentalization can lead to errors, narrowness and insufficient opportunity for comparing knowledge and can reduce motivation in the future.

Uncertainty
Inherent uncertainty in software development, compounds the coordination problem. Since software development is not as structured and requirements often change throughout the lifecycle of the project, uncertainty becomes more and more prevelant. Users, analysts and domain usage also have a strong influence on the requirements and hence, uncertainty factor. It is often the case that designers and architects do not have the information required readily at hand, so the coordination effort between them and the analyst and users becomes tedious. It is also uncertain, since the different sub-groups working on the software all have different ideas on the functionality and aspects of the software.

Interdependence
Due to the nature of software modules, which in the end, need to mesh perfectly together to have a working program, interdependence becomes very important. Poor coordination in sub-groups developing integrating modules, could lead to failure in integrating the modules themselves.

Informal Communication
With the addition of the above-mentioned three problems, coordination becomes particularly difficult when you take the communication aspect into account. Coordination cannot become viable when there is no communication to convey the desired requirements of changes. Some of this communication is in the form of formal communication, often in the form of documents or technical specs...but these are found to be difficult for conveying a more personal approach. Informal comm is often better, making it easier to summarize, memorize and remember for future use, but could lead to the formal atmosphere being dropped altogether.

Ko et. al: Information needs in collocated software development teams

What information needs exist and how severe are they?

1. Writing Code
• C1 - What data structures or functions can be used to implement this behaviour
  
• C2 - How do I use this data structure of function?
• C3 - How can I coordinate this with this other data structure or function?
  
2. Submitting a Change
• S1 - Did I make any mistakes in my new code?
• S2 - Did I follow my team's conventions?
• S3 - Which changes are part of this submission?
  
3. Triaging Bugs
• B1 - Is this a legitimate problem?
• B2 - How difficult will this problem be to fix?
• B3 - Is it worth fixing?
  
4. Reducing the Failuree
• R1 - What does the failure look like?
• R2 - In what situations does this failure occur?
5. Understanding Behaviour
• U1 - What code could have caused this behaviour?
• U2 - What’s statically related to this code?
• U3 - What code caused this program state?
6. Reasoning about Design
• D1 - What is the purpose of this code?
• D2 - What is the program is supposed to do?
• D3 - Why was this code implemented this way?
• D4 - What are the implications of this change?
7. Maintaining Awareness
• A1 - How have resources I depend on changed?
• A2 - What have my coworkers been doing?
• A3 - What information was relevant to my task?

For the relevant severity of these cases, please refer to the diagram below:

Assignment 2 - The Way of the Wiki - Part I

For this assignment, I have chosen Wikipedia as the wiki of my article contributions. I might also post on a different wiki. This post will be kept updated throughout the assignment period, so visit it regularly!

Wikipedia

This wiki serves as a general encyclopaedia and covers a broad spectrum of topics. There is no specificity when it comes to what articles might be posted, yet, there are certain limitations on the content. Anyone can post new articles (if they do not already exist), edit existing articles or even enter a discussion based around central thoughts and ideas concerning the article.

Since Wikipedia is widely used by many individuals, it is inevitable that some articles contain information which is redundant, irrelevant or simply not true. Wikipedia strives for correctness of information by requesting users to insert any references and notes to verify the content. The strength of the wiki lies in that any person can access and edit the information. Since this is the case, the user only needs to adhere to certain policies and standards:

• Wikipedia works by building consensus.
• Wikipedia is an encyclopaedia.
• Respect other contributors.
• Respect copyrights.
• Avoid bias.
• Include only verifiable information.

In addition to this, Wikipedia also states the five pillars that define Wikipedia’s character:

1. Wikipedia is an encyclopaedia
2. Wikipedia has a neutral point of view
3. Wikipedia is free content
4. Wikipedia has a code of conduct
5. Wikipedia does not have firm rules

For new users, it is fairly simple and straight forward to create a new user account. This can generally be done in around 5 minutes and you will be able to edit, contribute or simply discuss other articles in no time. Since Wikipedia is constantly changing and being updated, there are some rules to follow for writing or editing articles, but these can be quickly and easily learnt from the Wikipedia Tutorials which take you through a step-by-step process of writing your first article and submitting it to the wiki. This of course is all done in a Sandbox as to not disrupt the actual wiki, but serves the purpose of authentic editing and user interface controls, to familiarize the user with wiki editing. Throughout the Tutorials, interesting information relevant to the editing and submission process is given to explain more sensitive points of editing etc. Users who are more experienced, might find this information helpful when editing and creating more advanced articles.

My first Wikipedia Article

I have created my account. I have worked through most of the Wikipedia tutorials and also played around on their sandbox a bit (not to disrupt the main page).

My first article I thought would be on the History of my Family Name – la Barré – after searching for this on Wikipedia, I saw that a few articles on people and places existed with connotations to the family name, but no specific History of the name article existed...and thus thought this the perfect article.

I quickly updated the main page with the relevant link to Family History name which was easy enough and then continued to create a new article. After editing and some familiarization aspects, I was well on my way to posting my first article. The article is now up and running, and I am anxious to see what will happen to it in the near future...keep you posted!

Groupware and Social Dynamics: Eight Challenges for Developers

Unlike large mainframe systems, GroupWare has to “fit” into an already existing infrastructure and the applications must adapt to the organizational setup even when facing political or social resistance. One big challenge that remains is that of the interface. Since single-users use the groupware software, developers need to focus on a clean interface as well as the group processes and activity challenges that might arise.

It is often the case with new software or applications, that users need to get used to the application or it requires a steep learning-curve...which in turn leads to more work necessary. This additional work does not guarantee additional benefit, and the company is often stuck with a white elephant afterwards. GroupWare systems are often challenged by the social, political and economical factors which a group naturally portrays and because of this, a system (scheduling system) is at a disadvantage when it comes to information regarding human-interaction etc. One should be careful not to disrupt these carefully constructed webs of interactions by forcefully introducing a new GroupWare system.

Because GroupWare builds on individual activities, developers have to be alert to the facts that the software should be designed to align to individual needs and requirements. They should also make sure that infrequently used features are not dominating the primary screen. These enhancements could lead to a wider and quicker acceptance of GroupWare as a whole. Developers must also look at the introduction of GroupWare and take into account what users want and need in group setting. Often, software is doomed from the beginning, because it has been poorly introduced, or does not benefit the customer at all, or only minimally. The developers would be wise to take a step back and understand the group process activities, application use and also group-activity requirements, and integrate all of these features into already existing software.