A4NicholasEmbreeJacobWisneskyScottKeller

A4NicholasEmbreeJacobWisneskyScottKeller

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

Seeing as this paper was written in 1994, the discussion on the future of artificial intelligence in software engineering was especially interesting. This paper talks about automation getting to the point of removing the entire context from the work and turning people into "button pushers". To an extent, this is already happening and has taken off considerably with the invention of the internet. Currently, it is extremely easy for a power user with little coding experience to have substantial coding power and ease in artifact creation. In fact, I created a php forum with a SQL database for my forum the other day in about 2 minutes with the help of automated tools and about 2 lines of coding. It is not uncommon to see reasonably successful attacks on networks executed by users who solely know how to use scripts. However, automation has its place (as stated in the paper) and is currently more prominently used as an aid to humans instead of a replacement. Software automation is empowering designers by working alongside them. Intelligent systems check code for potential refactoring and code reuse and environments auto complete or suggest valuable methods based on context. I agree with Fischer in that the goal of automation must be to aid a human instead of replacing them. It reminds me of a discussion last semester about a pilot of a plane: to what extent do you want a computer to fly the plane?

What you did not understand

What we found interesting but did not completely understand was that even though it is hard to completely learn a full fledged design environment and it is much less trouble to learn a new computer language because of the fact that most computer languages share the basis in which makes all computer languages great. In our opinion, if all computer scientists started to learn what makes a design environment great and had take the time to fully comprehend and master that design environment, then the costs of learning a fully fledged design environment will be just as modest as learning a new computer language. This is true because the more one person learns about a subject, they are more comfortable in that specific field of study and can easily absorb more information on that specific subject. Once we place computer scientists into the paradigm that design environments are essential to the design process then they will be able to learn much more comprehensively.

Compare DODE with EDC

The EDC is really a fairly solid example of a platform to produce DODEs. The EDC also exists in such a way that it's fairly versatile and can be re-used to support multiple domains.

The various physical blocks and pieces that can be physically manipulated and used to interact with the simulation running on the EDC serve as a good construction kit. Whether the blocks mark bus routes or open space, create fires or floods, or increase the height of buildings, they provide a "pallette of domain concepts" and support construction via "direct manipulation and electronic forms." An "argumentative hypermedia system" can be implemented via the various monitors and displays set up around the table, or can be projected onto the table itself. Furthermore, a sort of abstract argumentative hypermedia system can arise from the discussions between table participants, who can argue for and against designs and other ideas due to the collaborative environment of the table. The EDC can easily support "catalogs" for many domains, be they a collection of prestored city plans, optimal solutions for building on floodplains, or ways to redesign CU's research campus. The specification component can arise out of the monitors and displays around the EDC. How precisely it would be implemented could vary depending on the exact domain. Finally, the simulation component is probably the strongest aspect of the EDC as a DODE platform. The use of the table, plus the monitors and projection on the wall, easily allow to have multiple representations of possible designs and situations. The ease of which the construction kit, catalog, and "argumentative hypermedia system" can be used and manipulated allows for powerful, versatile, and easily changed immersive "what-if" simulations.

Overall, the EDC is a very interesting platform for DODEs.

Comment on the best role distribution

The optimal role distribution between humans and computers in joint human-computer systems and socio-technical environments probably varies depending upon the particular system or environment. Some environments may intrinsically be more suited to larger computer roles, whereas others may require greater human participation. In general, however, the goal shouldn't be to come up with a concrete split between human and computer roles, but rather produce a general framework for recognizing the strengths and weaknesses of both humans and computers, and using this framework to maximize the strengths of all participants (human and computer) while minimizing their weaknesses.

Historically, computers have been strong at performing tasks that can easily be automated. Things like performing complex or even easy but repetitive steps have often been the domain for computers. In this sense, computers have often been a source of menial labor, used for freeing up humans for more "high-level" design or thinking tasks. There's nothing wrong with this view per-say, but there does seem to be a push to get computers more "involved" in socio-technical environments. I don't think the different views written in the papers are mutally exclusive - I really see them as different approaches to fostering greater computer involvement. A computer that provides a DODE is inherently more involved than a computer that just runs Notepad. A computer that tries to automate programming is more involved as well, just in a different way.

To expand upon the above: I see no reason why a bigger role for one participant (human or computer) must result in a smaller role for the other. Why not expand the roles of both humans and computers? If both are capable of more, why not have both do more? The key is to realize HOW a bigger role for one allows the role for the other to expand, and to use the benefits of expanding the role of both to leverage synergy between the two.