A4JoeMcCabeGrahamRobertsNickHughesBenjaminGolden

A4JoeMcCabeGrahamRobertsNickHughesBenjaminGolden

To-Do

1. which was the most interesting idea/concept you learned from the article?
2. articulate what you did not understand in the article but it sounded interesting and you would like to know more about it
3. compare the ideas/argumentation/functionality for DODEs with the EDC demonstration given in the class meeting on February 11!
4. one major objective of the article, the commentaries, and the reply is to understand the best role distribution between humans and computers in joint human-computer systems (or socio-technical environments)! Comment of this issues from your personal experience!

Most interesting idea/concept

#1 (Joe) I though the idea of humans still wanting to design things was interesting. I thought the example of the model trains described the program perfectly. While a computer could effectively design and code entire programs in the future, there would still be lacking of the element of personalization. Which each model train set that a person setups up in their basement, they add touches from out their life. Like they may choose to buy and install a model house that represents their childhood home, or if the train set begins to deteriorate the person has a personal option to upgrade or modify their personal train set. This even happens when people code a small assignment for class, each copy of the program that is turned in is completely different. Yes, the concepts and logic of the program may be the same, but each person may chose to use a different color in their GUI or a personalized font. All of these smaller design decisions made by a person is what makes their software different from someone else's. You can look at Google Docs vs. Microsoft Office and you can immediate tells which product belongs to each company. This is because of their layout, features and personalization by the coders who program the software.

What you did not understand

#2 (Graham) One thing that I did not entirely understand in the article was the evolutionary approach to software design and development. Specifically, during the "Evolutionary growth" stage is the product finished and delivered to the domain experts to use? Or is this more of a Beta version of the software that the domain experts can use? I can see an advantage to letting them use the product so that they become comfortable with it and are interested in improving it further, but will this give the customer a false sense of completeness in the project? This seems very similar to the Agile programming methods which state that the customer should immediately have a working product to test and give feedback on. Although this is generally a well respected approach to software development there are some situations where this method could not be implemented successfully. One such area would be in mission critical applications like spacecrafts, where it is not possible to iterate. Would it be possible to update this model to work in these projects, or is another method needed?

Compare DODE with EDC

#3 (Nick) When we compare DODEs or Domain-Oriented Design Environments with the EDC demonstration given in class we can see there are a lot of similarities. First of all, from the reading I have gathered that the idea of a DODE is to incorporate domain-specific knowledge, combine elements into a synthesis, design various simulations, all in a collaborative environment. It seems that the EDC demonstration is a great example of a Domain-Oriented Design Environment. It incorporated domain-specific knowledge - knowledge from different sources that is specific to a region of space. It combined several elements into a single interface, showing multiple sources of information on several screens, and various overlays of information as they apply to each. There were various design simulations such as simulation of forest fires and floods, which could help aid the design process in terms of the topography of the land and other factors. And of course, all of this was being done in a collaborative environment, which allowed multiple people the ability to contribute to the design environment simultaneously, independent of one another or as a group when needed. In short, the concepts behind the DODE were clearly demonstrated in the EDC demonstration, and in theory this way of setting up a design environment would enhance human collaboration and problem solving, replacing a more computer-automated design environment.

Comment on the best role distribution

#4 (Ben) I once did work for a small metro district maintaining an existing piece of software. This software was purchased from a 3rd party developer in Australia to enable the district to send water bills in the form of PDF attachments to emails. When used by the employees of the district the software had a horridly low success rate. The Error messages were ambiguous and technical, the program required very specific mail server settings, and the log files were bloated and impossible to effectively read. So I was hired to get the program working. By the end of the dilemma the functionality that the district originally desired was implemented. However, it required using a piece of software to act as a local mail server, and another program custom developed by myself to recreate log files in a readable manor and accurately report any failures along with causes. I think this is a prime example of how terribly wrong a piece of software can go without effective communication between end-user and developer, especially during the time of development. This software was developed independently with no specific client in mind and then distributed without any effective interactive feedback or support. As is, without human/user feedback the software that the district purchased was useless, in order to accomplish anything they required sizeable aid in communicating with the computer/program in order to accomplish the desired task.