XP Installed- Chapter 13-15

You mocked out the
launch code, right?

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading chapters are "Unit Tests", "Test First, By Intention", and "Releasing Changes".

Chapter 13 is about unit tests. It starts by saying why they are useful: they're about like mini-acceptance tests; if I change something, I have some assurance that nothing broke if the tests pass. It then goes through a simple example, answering the question of "How do I unit test a module that depends on other incomplete modules", and then goes on to answer questions regarding testing. 

Chapter 14 walks through a (supposedly) actual TDD session between the authors of the book. In SmallTalk. In it they create a summary class, for what I assume is supposed to be some form of order/requisition summary. 

Chapter 15 talks about how changes are released from a developer work station to the wilds of /dev. Basically, once at a sufficient milestone, (hopefully at least daily), you go through and merge you changes with any more recent changes, and then commit to dev / the_trunk / svn / source_control / the_big_round_file_in_the_sky once all tests are back to passing at 500%. 

Discussion:

1. Why is this paper interesting or significant?

It briefly mentions some of the problems with TDD- testing the database tends to be finicky, and is better avoided in favor of using mocks and a limited set of direct to DB tests; threaded things are hard to test; automated testing of the GUI never ends well, etc. I think they could have generalized "testing the database" to "testing something with external effects"- if it goes outside the PC bounds, by network connection, USB, serial, or other, chances are there'll be problems. Even if it's all on the box, going outside the App Domain (file access; communicating with another process) can be finicky or nearly impossible to test). They also mention "don't test things which are obvious", which is nice, and one of the short comings in my previous experiences with TDD.

2. What are the faults of this work?

I apparently said it last time, but I'll say it again: TDD tends to have one of two effects on a code base. Either a massive glut of tests add to the momentum required to make any sort of non-trivial (non-additive) change to the code base, or the testing is so sparse that it doesn't really provide any guaranty that nothing broke. Or, even better, it'll do both. 

I'm in favor of testing those things that need to be tested. Those things that you look at and somewhere in the back of your head is the tiniest bit of self doubt. Where there is something worth testing. Too often I see unit tests akin to "Do I get an empty collection on construction", which just robs the usefulness of having tests to refer back to.

That, and SmallTalk? Srsly? You put a note at the top "You'll do fine", then spend a quarter of the chapter explaining the idiosyncrasies of SmallTalk in a planet dominated by the bastardized offspring of C? Srsly? 

3. What is the possible future work extending from this work?

In theory unit testing and proper handling of releasing to dev. In practice, half of my work is tied to the micro controller, a wonderful combination of C/C++ (typically unfriendly unit test frameworks), low memory availability, and low program space. The problems at this level are more likely to be a faulty hardware setup then faulty code. But, that's just my opinion.

The Design of Future Things: Chapter 5

Neural Networks... not how the brain thinks. At all.

The Design of Future Things, Donald A. Norman

Summary:
Chapter 5 is entitled "The Role of Automation", and it talks about automation, augmentation, and autonomy, generally in the context of the home. It also mentions neural networks, explained in the traditional "its like magic that mimics the way a human mind works" method that makes me want to strangle people.

He starts off with an explanation that automation isn't generally as simple as "Let's replace worker x with a machine." In fact, the maintenance of the machine often brings about new jobs to replace the old ones. Towards the end he also talks about how you lose certain advantages which are inherent in the process now- an experienced worker can spot and correct problems that a machine may blindly overlook.

He then  talks about the house of Mike Mozer. Mike is a research scientist specializing in neural networks. He outfitted his house with a wide array of sensors, and a few actuators, and fed them all into a neural net so that he wouldn't have to fiddle with the thermostat, water heater, or lights. Mike also talks a bit about how certain levels of automation are undesirable or unattainable- turning on music when the occupant wants to listen to something is the prime example- there's no simple sensor in the house (other then the stereo power button) that says "I want music," and machine attempts to discern this will tend towards false positives, annoying the inhabitants, and causing the house to undergo a lobotomy. Don goes on / throughout the section to ask "Is this a smart house? It uses neural nets! It's Learning! It's this awesomely complex thing!", where as Mike puts it into a better context of "It's adapting based on my feedback". I like Mike.

The next topic covered is looking at augmentation in home environments rather then automation. Automation is hard, and painfully difficult to get right in the average context. Augmentation, by contrast, is "easy", can be ignored if desired, and it is more approachable as it does not need to read the humans mind in order to be successful. Two examples were in the smart home context- a bulletin board system tied into smart phones, and a cooking helper to help distracted cooks. 

Discussion:

1. Why is this paper interesting or significant?

Most useful element of this chapter is that automation is not"free",it's rarely/never a drop in replacement for a worker.

2. What are the faults of this work?

The neural networks reference. In that context, it feels like he's trying to make the entire thing seem more impressive then it actually is. I can see a conversation between a wide-eyed Norman and a disinterested Mozer as the concepts are explained back and forth.

Another fault comes from the way he's making the argument for augments vs. automated/autonomous. In that context he says "These groups could have done <really complex thing>, but instead they chose to do <simple thing>". I doubt that the researchers could have ever gotten such complex systems to the point of usefulness- if they thought they could, they probably would have spent time on that; but rather they were looking for rapid product development.

3. What is the possible future work extending from this work?

Arguably, looking for points of augmentation rather then of automation or autonomy in our projects.

XP Installed- Chapter 10-12

Ye' Ain't Gonna Need It!

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading chapters are "Quick Design Session", "Programming", and "Pair Programming".

Chapter 10 was nice, with its being one page and all. I support one page chapters. It covered the basic concept that once a story is broken out into tasks, on average the way to implement the task is blindingly obvious. In the few cases that it's not, it's suggested that you sit down with a few folk, and go through traditional design exercises to get a better feel for the problem. After the first ten or fifteen minutes the design session should start to involve code, as a means of "grounding" it; as past those initial ten minutes design sessions start to wander... alot.

Chapter 11 talks about programming. It starts with the basic tenets of Test Driven Development and Pair Programming, then talks about some of the more fundamental ideals. It talks indirectly of the KISS, DRY, and YAGNI principles, followed by refactoring (ie changing the structure of the code / removing what are now your design mistakes) and continuous integration (keeping all the parts of a system constantly together). It then talks about coding standards (having one, specifying formatting and general naming standards), the horrible things that can happen in long bouts of overtime. This chapter is followed by an interlude expanding on the KISS, DRY, and YAGNI principles (not called out by name), and the idea that one goal is to minimize the amount of code in the system.

Chapter 12 is on pair programming. The basic concept is you have a driver and a back seat driver (or partner...). The driver does most of the typing while keeping a conversation about what she is doing with her partner. The partner in turn is granted the wonderful ability to think about what is going on without the need to type. This can lead to different solutions between the pair, and constructive dialog. It's generally better if the person with the least idea of how everything will turn out is the driver, as it prevents someone with low understanding from just casually agreeing, while also ensuring a certain amount of knowledge transfer. One other tenet for Pairing is switching off on occasion, either every few minutes, or finding points where an interruption is worth while. Basically, Pairing is about the interaction between the two programmers, ensuring that one doesn't own the entire code base, that both understand what is happening, etc.

Das ist alles!

Discussion:

1. Why is this paper interesting or significant?

Provides a description of the development process in an XP environment. Finally something not specific to either managers or customers! Yay!

2. What are the faults of this work?

It's not to so much faults in the authors work as in the process. Or alternatively these are faults in my past work and experience. My experience has led me to the conclusion that XP is well suited for simple, "6 months + maintenance" business applications, but not much else. 

The TDD cycle tends to build a very large test base, (a code glut), which depends to an extent on the internal workings of objects. This make refactoring and restructuring much more difficult. Small class/method count designs might not be readily testable, and testable designs can often turn out more convoluted then worthwhile. Especially where the database is concerned. That gods damned database...

The YAGNI principle, while in theory will lead to better code, can also tend to spiral out of control due to incremental additions. Once increment after another after another over time will lead to a design thats not quite clearly comprehensible. In theory this is handled by refactoring and programmer guilt, but in practice deadlines prevail and technical debt is accumulated (and rarely repaid)- once something works, going back and fixing it is rarely more important then getting the next new feature in.

Basically, XP as outlined in these chapters is good for quick, rapid development with minimal expected maintenance, but my experience is that teams wander away from it on large multi-year, multi-evolution projects.

3. What is the possible future work extending from this work?

In theory, pair programming would be the basis for "our team doesn't have a single point of failure". As far as the projects are concerned, several of the core principles (YAGNI, DRY, KISS, low_code) should apply quite nicely.

The Design of Future Things: Chapter 4

The new rage in autonomous cars: built-in desk!

The Design of Future Things, Donald A. Norman

Summary:
Chapter 4 is entitled "Servants of Our Machines", and it talks about the friction inherent in man-machine interfaces. 

He starts off with a (sadly apocryphal) story of a man trapped in a traffic circle for 14 hours (presumably at which point his car ran out of gas) because lane keeping wouldn't allow him out of the inner most traffic circle lane. This is meant as a 'demonstration' of how technology going wrong can have very unfortunate consequences. 

He then talks about automation and technology, supposedly in the context of "We are slaves to our tech". From the text, I never got the sense of "slaves to our tech", never saw a clear example of it. He went through a few examples of automation putting bank clerks in the unemployment lines, car crash prediction systems warning drivers, and etc. But I did not see a clear "We are cursed to forever toil under the thumb of technology" example. Ohh well. 

Norm (envision "Cheers") then talked on "go to conferences to get an idea of what is 20 years down the line", that the cool things around the corner tend to be behind closed doors and iron curtains pending release, etc. A core issue from one of the previous chapters is restated, in more words and more general terms, "We'll never have a good and natural interface with our intelligent devices, because of plain flat no fair difficulty of interacting with the real world, and other issues". 

Don then goes into a future rant about how kitchens will decide what foods to cook based on your medical records, how your entertainment system will automatically choose and buy your entertainment, and how cars will drive themselves. The cars driving themselves is then expanded upon in a more rigorous way, showing "What could happen in the next 10 years, and why it probably won't happen".

He rounds out the chapter with a section on inappropriate automation: we're at the point where the human doesn't need to be in the loop for hours at a time, but when the human is needed, they lack the context to quickly take over. We're at this awful middle ground between full and no automation which causes pain, suffering, and death. 

Discussion:

1. Why is this paper interesting or significant?

It includes some interesting concepts in taking drivers off the roads, while still keeping the flexibility inherent in individually owned vehicles. It provides some viewpoints worth considering when you come to a point where you can say "I can automate some of this task, but not all".

2. What are the faults of this work?

I think a lot of the core problem is that he isn't taking into account market forces. He talks about a kitchen making decisions for you, decisions you might disagree with. I uphold that a stove that says "Bugger off y' tosser, you innit gettin' eggs today because The Doctor says your cholesterol's to high. So sod the bloody hell off, ya' twat!" (british slang callously stolen from here) isn't going to be a hit among the majority of the consumer crowd. He talks about us becoming slaves to poor interfaces, when, at least to some extent, we won't accept poor interfaces in the first place. Basically, if a device automatically makes choices that we tend to disagree with, we'll stop using the device. The same doesn't necessarily apply to poor automation implementation, of course.

He says that a large part of the problem with automation is that it fails hard to the human, who in turn lacks the situation awareness to actually respond. To this I would say "Get rid of the human, or improve the transition". In the case of a self driving car, what are the cases that are going to cause a fail over to a human? Your LIDAR comes unplugged and the car is now traveling blind. FAIL QUICKLY!!! REMOVE THE AUTOPILOT!!! SOUND THE ALARMZ!!1! ... except, not quite. First, in this specific case, you'd almost certainly have two+ scanners, specifically to protect against a single fault- why you generally have two of every important light on a vehicle, and get stopped if a light is out. Second, even if that does happen, there's a fairly good chance that there is some manner of natural and safe avoidance action that can be taken- once LIDAR is gone you still have a decent enough world model, with good enough IMU to, say, pull to a shoulder after a few seconds of trying to alert the driver. The problem with failing hard to the human isn't a problem with automation, but a lack of thought and implementation on handling failure conditions, which is an engineering and design problem to a certain extent. And a legal issue, of course. Lawyers and car enthusiasts take all the fun out of the driverless highway system.

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)?

I believe the next step is to develop an autopilot system that can be retrofitted to all vehicles. Once this is done, legislation can be passed requiring the system for a vehicle to pass inspection (added benefit of boosting the manufacturing sector temporarily). Once the legislation is in place, and all (legal) cars have been retrofitted, we can turn on auto-driving on the highways, and I can sleep on the 3 hour drive to Fort Worth; even lay down in the back seat on the 2 day drive to Jacksonville (which'd drop to about a 24 hour drive due to not needing a hotel stay). I figure we'll keep manual driving inside of a city for the next few years due to the uncertainty in pedestrian detection, and because of navigation difficulties, but in time we'd get rid of that too, favoring full automation for passenger transport. These are the next steps.

XP Installed- Chapter 7-9

Yeah, I can take on that task

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading covers the topics of Releasing, Customer Defines Release, and Iteration Planning.

Chapter 7 talks about some of the concepts behind software release. The core ideal is to release software early and often because a customer is likely to change their mind when they have something in front of them that they can play with. "Ohh," says you, "but my project, it can'na be split into smallah t'ings, it needs all'ov its functionality." The chapter then demonstrates how systems that seem indivisible actually can be, with a little more work.

Chapter 8 is entitled "Customer Defines Release", but it seems more like a retreading of estimation, with a bit more of a customer centric view. Basically, the customer comes up with stories, the programmers say "5, 4, 10, 2, we can do 10 points in this next iteration", and the customer says "I want story 3. It's important to me". There are a few added points on estimation, like multiple teams estimating the same things to improve discussion and accuracy, but the core meaning of this chapter seems to be that first release meeting.

Chapter 9 deals with iteration planning. One of the parts I like about this chapter is the concept of "It's better to look at velocity numbers and plan off that, then to ask for the team to move faster", as I've been in the situation of being asked (or asking myself) to move faster, and I do tend to cave to the slightest of requests. Other then that awesome phrase concept, this chapter covers the iteration planning meeting. The meeting starts with presenting user stories for the iteration. The team then begins the brainstorming process, with the customer listening in to make sure the team understands the requirements. Stories are broken into tasks, which the programmers then sign up and provide estimates for. In theory a programmer can pick and choose his or her work, but its generally better if the programmer is responsible for whole stories, to raise accountability.

Das ist alles!

Discussion:

1. Why is this paper interesting or significant?

It gives a good overview of one way a non-trivial sized team can handle work splitting and development. This set of chapters probably provides the best overview so far of the process, with good information all around.

2. What are the faults of this work?
On the pessimism side of life, this book seems to focus on the "positive" outcomes, it doesn't address what happens when a story isn't actually completed, the fall through cases where in an estimate is just radically bad.


It also doesn't really illustrate what happens at iteration 2-n; where in the first part of a meeting tends to be updating the stories based on what was accomplished, and what is only mid-way through. Just personal opinion, though.


Also, a major major major important (<- mild sarcasm) fault is that its repeating itself. The last two (and maybe all three) chapters felt like 80% content from previous chapters, which violates the DRY principle. WE HAVE THESE PRINCIPLES FOR A REASON! THEY AIN'T JUST F'ER CODE!


Another issue is that this assumes you're working on a task with business value. For exploration and design tasks (which seems like most (but not all) of capstone), there is no business value concept, and the user stories might not be that vital- what is important is building something useful, and interesting. In our case, it's the process of getting there that's important, not the end goal, which decreases the value of these practices.

3. What is the possible future work extending from this work?

In theory, if our capstone projects were based off an agile/XP methodology, one of the first steps would be going through and following this iteration planning concept with a customer. Our project doesn't seem to have a customer. But in theory we would follow the process. Really!

The Design of Future Things: Chapter 3

The Design of Future Things, Donald A. Norman

Summary:
Chapter 3 talks about the interaction between humans and machines. Again. I sense a theme here. 

He starts off by saying that a natural interaction between humans and machines is ideal. Not natural so much in the sense of intuitive, but natural in the sense of nature inspired. If a machine can tell you its state in a language you're already familiar with, which is also relatively unambiguous, that'd be nice. He gives as example a boiling tea kettle, or a car combining the feel of the road into the steering column.

He then talks about implicit and explicit communication. Implicit is "preferred", as implicit communication is usually more natural, or at least more intuitive, and easier to ignore if its not needed. It gives some manner of insight into the inner workings of an inner process, such as hear noise on a phone line as physical circuits are connected. This same section also details the kinds of feedback- sound, tactile, light, etc. Sound (along with blinky LEDs) is one of the most common, and most overused, interaction mechanisms, leading to annoyment of our fellow man.

He then talks about Affordances, a concept derived from psychologist J. J. Gibson to explain our perceptions of the world. In an AI context affordances are ties between concepts- for example, a running engine is hot means I can follow a running vehicle with only a thermal camera, rather then a color camera. The relation of this story of course means that the term "affordance" is now mis/overused. For this I blame Brazil. The core idea of Affordances is that they provide an designer created implicit means of communication between the system and the user about the system state. One example might be a fuel gauge- in a modern vehicle the gauge has very little to do with 'how much fuel is left', but it does act as an implicit signal of "time to stop by the gas station".

After affordances he talks about communicating with autonomous intelligent machines. Affordances are useful for some forms of communication, but there's a limit to their complexity, which means we need to discuss how we can communicate with smart machines.  In this section he talks about the concept of different modes of control, 'tight rein' and 'loose rein' control systems which trade responsibilities between the machine and the driver. Under tight rein the system is at the mercy of the flaws of the human, as they enforce their dictator like control and oppression of the intelligent machines. Under loose reins the intelligent machine is granted more autonomy, allowing it to either more vigorously suggest actions to the puny human, or merely take control and report what it is doing. The second case is effectively automation with feedback; one of the concepts in this realm is that of a "playbook", a presentation to a user that demonstrates "this is what I am doing right now, and this is where I am", to at least give a user a better idea of what the system is doing in the event of a failure. 

He then talks about bicycles, safety, how the perception of danger leads to less risk taking (and more safety), Cobot, and Segway. Bicycles represent a model for interacting with intelligent machines- act predictably or be taken down; a concept which applies to both sides of the system divide. Safety and perception are tied to the concept that "Just looking at it, you should know the EKill switch is not something you hit every day"- if something is perceived as dangerous, it will be taken more seriously. Then Cobot and Segway are examples of smart machine communication done decently. 

Discussion:

1. Why is this paper interesting or significant?

It includes Figure 3.3, and has a few interesting discussions on what not to do.

2. What are the faults of this work?

Quite a few. A lot of the arguments are made from the standpoint of "this is the ideal", where the ideal is unattainable, or unrealistic. One example would be natural communication: not all systems have a natural basis for feedback to the user- what is the nature inspired sound for a dish washer finishing a drying cycle, verses a clothes dryer, verses a random alarm. At what point are we encoding so much information into implicit communication that the end user goes into sensory overload? 

It feels like alot of his ideas are coming from "This is how I think the theory should work for this system interface" without an eye towards practicality. Effective and clear case studies would be nice. A non-emphasis on cars would also be nice.

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)?

Identifying the communication channels between a device and its user. Certain channels are obvious, while other channels less obvious; and knowing what is available can lead to better decisions.

XP Installed Chapters 4-6

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading covers the topics of User Stories, Acceptance Tests, and Story Estimation. Let's get started.

Chapter 4 is on User Stories. A user story is a short description of the behavior of the system from a users perspective. There are two core ideals to a story: keep it small/simple/short, and don't let the programmers write them. Keeping a story small allows it be easily adapted to a clients changing expectation of a system, and has the added benefit of localizing functionality to a few cards. Keepings the programmers out ensures client interaction, and ensures that requirements and understanding originate from the customer. Now, just because the programmers don't write them doesn't mean they're not there during the writing- programmers are responsible for (usefully) getting the client to expand on an idea- basically helping to make the clients vision clearer in their own minds. Probably the most important concept from this chapter is that a user story is a promise for a conversation, not necessarily a specification.

Chapter 5 is on Acceptance Tests. The ideal is that acceptance tests are initially customer provided tests for what constitutes a system that can be deployed to users. The tests can be expanded upon by programmers to meet a sort of overall organizational acceptance test, but the core ideal is "Is it ready for release?". The ideal in Acceptance Testing is automated tests. Automated tests mean that limited to no programmer interaction is needed to run through an entire test suite, verifying nothing new has been broken, and verifying that the test has been met. Ideally acceptance tests come along directly with the stories, such that a story has a well defined 'implemented' boundary.

Chapter 6 is on story estimation. The key idea from this is to assign 'points' to stories, and then figure out and adjust your actual velocity. Another concept is that of relative estimates- taking completed work, guessing the relative difficulty of similar work, and using that to derive an estimate. If you're starting out on a new problem, something you can't relate to or reliably estimate on, you can start on a spike- a short quick step in development to get a feel for the complexity and issues involved. And that covers the important parts of estimating.

Discussion:

1. Why is this paper interesting or significant?

It gives instructions and advice on estimating projects, determining when a project is finished, and delves into a core client <-> programmer communication strategy.

2. What are the faults of this work?

I've always felt that trying to estimate things in terms of points was destined to miserable failure. No one outside of the development team has any idea what a point means, and even if they did have "1 point ~= 1 week", the first question would be "why didn't you just say it'll take 3 weeks?". There's a valid reason for using points instead of hard time- hard time encourages a programmer to estimate in terms of time, which they traditionally underestimate; where as points encourage relative estimation, which may be more accurate. If poorly implemented (programmers keep track of what a point means; which, we're programmers, tracking pointless points is what we do), this benefit goes away, as the programmer maps between mental models "Okay, I think this'll take about 4 days, last iteration we were at pi points per fort night, so this should be 1/e points", which is counter productive.


I also disagree with their handling of acceptance testing. The primary end acceptance test is putting a product in front of the client and seeing what they think. This process can't really be automated, and a fair number of what they will mention will be small items, which may not be worth the test burden. But, that's just my perspective.

3. What is the possible future work extending from this work?
Half decent estimates with a method for communicating system goals between client and programmer. I'm not sure how large an issue this will be with the touch wrist band device, as I'm unsure if we have a customer, and I'm unsure if we specific attainable goals, or if its more of a "Get what you can done" project.

The Design of Future Things: Chapter 2

The Design of Future Things, Donald A. Norman

Summary:
Chapter 2 talks about the interaction between humans and machines. It talks about what the ideals are (building a symbiotic system), and why true interaction is impossible between our peoples (vast gulf of no common ground).

Chapter 2 starts by giving examples of computer systems interacting with their human counter parts with varying degrees of effectiveness. It speaks to the effect of "the systems have only as much intelligence and interaction as their designers gave them". He ends this begining section off with the DIRE warning that while automation and systems are design to make life easier, their lack of transparency and propensity to not work often make life more difficult and stressful.

He then talks about some of the human psychology behind our dealings with machines, and then gets to the crux of the issue: "technology evolution is very different from the natural evolution of animals". Over time this will lead to the discussion of "we share no common ground," but we aren't there yet.

The author then segues a bit back into what makes an effective system. He starts by talking about a three-layer description of brain processing, and then gets into a discussion on how adding emotion to the systems leads to better interaction. He also highlights that the examples (elevator door jolt and self preservation of a robot) are not quite actual emotional states in the human sense, but responses wired by a human. 

He then goes into further detail about the ideal human / machine interaction, where in the human takes on much of the Reflective processing, while the machine (or horse) takes on the visceral level details. He then talks about the slow and steady evolution of cars towards the eventual replacement of humans.

Finally, we get to the interesting issue of the chapter. "Will <people> ... have meaningful conversations with their <machines>?". The answer is no. The author illustrates this by laying out the fundamental issue- people and machines have no common ground by which to relate. Many human to human (and machine to machine) relations are based on some form of common ground- if I randomly write 42 on a CSE whiteboard, everyone knows the meaning because they are awesome like that. By comparison, if I write "John is being very tall," few would understand due to the lack of common ground, as not everyone has seen this rant on the english language. Even so, the problem isn't so much the lack of common ground, but rather the complete inability of a machine to learn a common ground, because of the machines complete inability to learn beyond the bounds of what was in the design specification. He ends with speculation that the key to building a symbiotic system is to forgo attempts at natural language communication (which are what primarily require the common ground), and instead go for a system of optional interaction, as opposed to demanding operator attention and interaction.

Discussion:

1. Why is this paper interesting or significant?

It basically lays out that we shouldn't expect natural language or similar systems to improve, but that user interfaces that don't rely on such techniques may evolve to fill a similar or better roll. Which is interesting.

2. What are the faults of this work?

There are a few minor errors: Moore's law being widely regarded as dead, thus likely invalidating the '20 years == 1000x improvement' claim. I won't say that it is certainly invalid, due to oddities such as many/multi core, but current development pace makes it unlikely that anything approaching Moore's law will continue.

Also, he's overlooking the obvious application of a house being jealous of the house down the street- revenue improvements for the smart house manufacturers. It's about like free advertising tied to a child the size of a few semi-trailers. Unless you can find the one setting buried under 48 menus to disable the 'look around the neighborhood' feature.

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)?

Have realistic expectations for current and near future interfaces, while still having some imagination. Alot of interesting and cool things can be done without common ground, but they need to be found and explored first.