The Design of Future Things: Chapter 1

(Odd fact: the actual time at which blogs are due is not specified in 48pt font... I'd like to propose 5am of the next day, myself) 

The Design of Future Things, Donald A. Norman

Summary:
Chapter 1 seems to be giving us a context with which to understand the rest of the book. It talks about what intelligent systems are (such as an Adaptive Cruise Control), and what their failings are. It also gives examples of systems with good interactions.

TDoFT starts by giving examples of various 'bad' systems: An adaptive cruise control system with unanticipated acceleration, a navigation system that doesn't allow for user input in determining routes, and books. Each of these systems lacks a dialog between the system and the user. In most of the systems the interaction takes the form of two monologs, the user giving a series of commands, and the system responding. While in some systems there may be a form of iterative refinement (ie searching for something on google), there is never an "intelligent interaction", never a dialog between the two actors in the environment. This leads to frustration, and potential health and safety issues, on the part of the user.

Now that TDoFT has stated what is wrong with existing systems, it tries to give examples of what a good system is like. A craftsman and his tools, a horse and rider, a driver and car, or a customer and 'related items' feedback while shopping. In each of these cases, the goal is to transcend merely working with the tool, and instead have it as an integral part of your work. 

The author then goes onto discuss some future implications, for example what a 'smart house' might be like, in particular if we continue down our current trend of monologs between actors. Throughout the reading he notes that these may not be so much limitations of the designs, but rather fundamental limitations of the current technology- there is no good way to give a computer an understanding of the context in which it operates.

Discussion:

1. Why is this paper interesting or significant?

It gives a basis for the rest of the book. It illustrates that "Okay, this is what we're doing now, and this is why its awful, and this is why it is that way now."

2. What are the faults of this work?

I can't name anything too seriously faulty. There are minor details to the form of the arguments: he starts by going through and saying "we need empathic cars," but only later does he come back to the "there's a reason we don't have that yet," element. A non-trivial number of people will start to tune out after hearing "we need touchy/feely cars" based on the assumption that the author isn't familiar with why adding fluffy sociability to machines is so difficult, which detracts from the argument. However, I agree with his overall points... and thus don't see many faults.

3. What is the possible future work extending from this work (i.e., if you had implemented this work, what would be your next steps – either continuing or fixing this work, taking some of these ideas and applying them to others’/your work, or starting new work from some of these ideas)?

The primary thing to take from this first chapter is to think early and often about how your system will interact with its users. No interaction, with minimal transparency breeds distrust, while over communicating breeds annoyance and the off button. While it's beyond the hope of many to build a fully conversant system, it is reasonable to build a system that takes into account many of the software use cases, and to ask "What kind of exceptions are there, and how can they happen?".  By the laws set forth by Murphy and others, you will get many things wrong, but on average it is better then ignoring the problem all together.

XP Installed Chapters 1-3

(For humerous effect, assume all instances of he,she,they in this post are actually a gender/plurality neutral phrase)

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson


Summary:
The reading starts out with a definition of what the key roles are in an XP development environment: the customer, the programmer, and the manager. 


The customer basically gives direction and focus to the group. Through the use of stories they decide what will be built, and they say what features are important to them. At lower levels they also provide value judgments- they say 'feature x is more important than feature y', and 'that's awful, scrap it'. They also answer questions about the stories they provided, giving more detailed feedback, allowing the programmers to better understand what the customer wants. From experience, a spec without an understanding of the customer will generate an unusable application. In an ideal situation, a customer is on site to facilitate a rapid feedback process, and to lower the bar for ''what's important enough to ask."


The programmer is responsible for realizing the customers wildest dreams in a timely manner. Which is to say, much of the programmer's job is what it has always been- to understand what needs to be built, and then to build it. XP places a few additional requests on the programmer. All production coding should be done by pair programming to ensure low ownership and high cross training. A working software product needs to be built quickly, and maintained. Stories or changes need to be released for customer feedback early and often. But, at the core, the programmer is still a programmer.


The manager is responsible for much of the day to day rigmarole of organizing a group. The manager is responsible for organizing meetings between the programmers and customers. He is responsible for resolving conflicts, and removing impediments to progress. The manager lacks some of the more traditional tasks usually assigned to managers: he is not responsible for assigning tasks to individuals, he is not responsible for deciding prioritizations, and he's not necessarily given a say on "What is right". In these ways, Manager is perhaps the wrong name, rather the role is better described as "Facilitator".  


After the descriptions of the roles is given, a set of 'Rights' is spelled out, for both the Manager/Customer, and the Programmers. For customers the rights come down to "You can have it your way, and you can leave at any time with what's in front of you," and for programmers it comes down to "You have a right to work, and to understand what you are doing."


Chapter 2 looks at the project life cycle. Starting with the customer, a set of stories are generated for a system. Programmers will typically estimate what each story will cost, and defer back to the customer. The customer will make a value judgement for what they want, and then the programmers will do their best to fulfill the customers deepest desires. The customer can then change their mind based on what they see in front of them, and the process will repeat. 


Chapter 2 also covers some basic pitfalls of XP: either promise a deadline or promise functionality, but not both. Trying to get programmers to work longer or harder will come back to bite you in the long run. It's possible that the customer will hear deadlines that they don't like, and it's better to stay to the deadlines then to make broken promises.


Chapter 3 talks about the benefits of having an onsite customer. Namely, that they provide nearly instant feedback to questions, and will remove a lot of guess work on the programmers part from the code base. It's also worthwhile because the customer can see how the development team operates, see that they are (or are not) making real progress, and establish a "rapport' between the customer and development team. Chapter 3 also addresses a few of the issues with having an on site customer, namely that they may be unable to complete their normal duties.

Discussion:
1. Why is this paper interesting or significant?
It sets a cornerstone for many of the ideas behind XP. Chapter 1 is basically an overview of the entire XP process in macro-level detail. It defines the 3 major roles in an XP team, what their responsibilities are, and how they work together. Chapter 2 defines the life cycle, the basic idea behind iterative development, and emphasizes the idea of delivering quickly to the customer. 


So, it's interesting because it gives a good glimpse of things to come.




2. What are the faults of this work?
There are a few things which are... nit picky. XP as a process is great for certain 'customer centered' apps. I've used in the context of web apps many times. But it's not ideal for use in all cases. Developing a web application is entirely different from developing hard drive firmware. This is in turn different from developing end user centric applications (PLC controllers meant to be debugged by field technicians, an Office Suite). In the first, the working firmware may not be the primary artifact of the process, but rather the documentation of capabilities. It may also be less iterative, focusing less on customer interaction and more on implementing and refining the spec. In the second, the customer themselves may not know what the end user needs. While it's bad for a programmer to guess about the customer's needs, having a customer guess about the user's needs is only shifting blame, not resolving the underlying problems.

3. What is the possible future work extending from this work (i.e., if you had implemented this work, what would be your next steps – either continuing or fixing this work, taking some of these ideas and applying them to others’/your work, or starting new work from some of these ideas)?
The reading so far gives a framework for interaction. When we first go about setting up our projects, interacting with our first customers, this paper will have provided part of the framework for how that interaction will work. It may be a bit indirect, as depending on the project the customer may not have real "buy in" to the teams efforts (they may not have went out seeking a developer for a product, but rather had a developer come to them), but the overall interactions will be heavily influenced this overview.

Introduction

I am Matt Moss. I've been to Germany. I can set things on fire with my mind.


Post Graduation: I will be doing... things. Current plot is an odd (and likely painful) combination of Grad School and continuing current dual employment at the Energy Systems Lab and at CCG.

Computing Interests: Physical Computing, Circuits, Robotics, Distributed Systems, SkyNET

Computing Strengths: Systems, Databases, Backends, Thick Client UI, Distributed/Networked Systems, Physical Computing, Microcontrollers, Basic Electronics; Language wise: C#, C, C++, Python, Java, Erlang, to variable degrees.

Favorite CS Project: Freshman year, in a 221 class with 4 students; I implemented Ticket To Ride on top of GLUT. The large range of work (data representation, simple AI, supporting tools for capturing polygons and paths in the image of the game board), combined with the relatively fun final product makes this my favorite.

Least Favorite CS Project: The Logisim Processor in CSCE 312. The project itself was interesting, and something I learned alot from. I'm glad we did it. But Logisim is an awful simulator for complex circuits. It'd come to 'undecidable outputs' because we included a sub circuit. That was also a group project, where in it was largely impossible to merge what different people did into a single file. The project wasn't as well thought out as it needed to be.

Top Tech of past 5 Years: Consumer level Multi-Core processors (and eventually Many-Core). This has forced a rethinking of how applications are written, and is leading into a rethinking of how systems are designed.

Alternatively, as far as Tech Product, I think the Arduino represents a 'top tech product'. It's lead to a surge in DIY electronics, which has many interesting implications.

Management Style: Here is a task. I'll nag you about it incessently until it is finished and working. If you can't do it to my standards I'll do it myself.


Coding Style: If starting in a fresh system, get a functional prototype of each 'I have no idea how to do this' component, to get an idea of 'this is how I do this'. Then begin work on the full scale system, integrating and designing as you go along.

On an existing system: If its unusable, or more painful then its worth, scrap it and rewrite it. Otherwise try to follow the conventions and patterns of the existing system.

Misc: Best/Most_Productive Development time has been statistically proven to be from 10pm-2+am. Outside of these hours, my mind has a strong tendency to wander off onto Hulu, random reading, or etc.