Tarun's Blog

From Bill Buxton’s Sketching User Experiences (Buxton, 2007).

This case sets  the issues for high-tech design. Design that works “in the wild”,
that works for real people in real situations and facilitates achieving their human goals.

Bill Buxton sets the scene for us with his avalanche responder case. It is an incident
experienced by Bill’s good friend Saul Greenberg, Saul Greenberg, and three friends when
skiing in high mountainous terrain in Canmore and Kananaskis Country, Alberta, Canada.

The group was traversing a valley slope when a lethal avalanche fell across their path.
The three skiers in the middle of the group were caught in the slide. The lead (Saul’s wife)
and the last skier could only watch the disaster
unfold as the three others were engulfed
by the avalanche.

One was simply knocked down, one was buried up to her shoulders and the last  Saul, was missing.

The group was well prepared in that the equipment they carried consisted of transceivers, probe sticks & shovels.

But more than just the technology; it also requires knowledge, shared practices, skills, and analysis of a concrete situation (among others). When skiing in avalanche prone conditions, you work one of a number of simple systems depending on the severity of the risk. One was simply knocked down, one was buried up to her shoulders, and the last, Saul, her husband, was missing. The normal procedure when traversing is to spread out. Lookouts at either and and traverse one-by-one. Retain one lookout.Triage; rescue the most able first (and they may be able to assist later). Go to the approximate location, judge if carried, then guide using transceiver. Use avalanche probe. When the victim is felt you start to dig. And dig. Judy started digging. Steve arrived and asked if she had verified the spot with her probe, she hadn’t. Judy was confident that she had the right spot, but by this time she had had to dig so deep that her confidence was wavering…

What did Saul do? He tried to ski his way out but got caught in the hollow (avalanches can travel at up to 200km/hour whereas 40km/hour is really fast for a skier). He got caught in the trough, a ‘feature trap’, that also meant he was buried deep! But he had cupped his hand over his mouth and nose, preserving a small air space so he could breathe. He waited, buried under the weight of the snow, and tried to relax. He had to trust in his partners, their training, his and their gear.

None of the participants had ever been in this situation before. The total time from slide to rescue was about 10 minutes. Under the conditions, after 20 minutes he would have been dead.

Ask yourselves; After the ‘who’, what saved Saul? If avalanches are so lethal how or why  did he survive? If there is a system here? There is isn’t there? If so what is it?

Well I think the system is there and it consists of a combination of human & technology factors. I this case human factors consisted of

1) Ad-hoc Problem Solving: None in the group had ever been in this situation before. But they devised methods ad-hoc to rescue Saul

• Context
• Ad-hoc
• Adapting

2) Training: Saul used his training and put his hand over his mouth & nose to preserve a small air space, this proved to be crucial as it was taking time to dig him out.

• Rescue Training
• Survival Training

And technological factors involved were

1) Procedures: The group spread out so that there are always lookouts in such emergencies

• Lookouts at either
• Traverse one-by-one.
• Retain one lookout.
• Triage; Rescue the most able first (and they may be able to assist later)

2) Equipment: The group had transceiver, probe and shovel at their disposable for such situations

• Transceiver
• Shovel
• Probe Stick

But still it was the combination of the two that saved Saul. Though technology to locate accurately was available Judy relied on her eye sight & instincts and was confident that she was digging the right spot. But when she could not locate Saul her confidence wavered, so if she would have relied on evidence, she would have been sure about the burial location. And if transceiver would not have been there and as Saul was buried too deep, it would have been extremely difficult for the group to locate him.

We have our intentions for technology, it should just work. The system just works, in the wild. But what do we need to do to get it to work?

First have trust in the technology and then rely on it. And ensure that the system does take care of the context and environment landscape where it is supposed to function.

The class had an interesting discussion around Project view in which high tech development projects characterizes the work in terms of four key variables:

Quality, Cost, Time and Scope.

Allen initiated the discussion around how the project success is dependent on these 4 variables.

Allen projected the slides which had his own handmade graphs showing the impact for these variables on the project success and then whole class has discourse around the graphs on each dimension

The first variable picked up was Time. Time is a crucial dimension of production activity. It turns out that an appropriate time line is a huge enabler for a project. However too aggressive a time target dooms a project to undue hast, unrealistic delivery times and, potentially, failure. Similarly, an excessively long time frame can defocus a team’s attention and starve the project of valuable feedback and checkpoints.

“How does a project get to be a year late?… One day at a time.” (Brooks Jr., 1995)

Second variable on which project success is dependent is Scope. It was deduced during discussions that scope management is very crucial for project success. Typically project scope will expand over time to include more features in greater detail as you learn what the customer wants/needs/really needs. The feature list of a project should always be clear and concise. Too large a list of features or feature creep generates problems of priority and coherence. A smaller set of the most crucial features probably has a stronger (positive) influence on the underlying architecture of the product. And “less scope makes it possible to delivery better quality”

“If you actively manage scope, you can provide managers and customers with control of cost, quality, and time.” (Beck, 2000)

Third variable is Quality which was a bit contentious and generated some debate. However quality might be defined we should keep in mind that a definition of quality is a non-trivial exercise. Quality is usually highly contextual, situated in a prevailing culture of what constitutes good or bad quality. In the case of software the product (or service) is not a physical good and so does not wear out in the way that hardware does. Hardware degrades over time due to physical wear and tear, breaking down and mechanical or physical failure. Software still fails and so it undergoes maintenance work to fix or enhance it over its economic life. For the purpose of a particular project the product’s quality is generally a negotiated concept. Don’t deliver something you know hasn’t been tested, or fails the tests; quality should be used to set thresholds and targets, using it as a control variable undermines and destroys the values we all aspire to.

“Quality is a terrible control variable” (Beck, 2000)

The final and perhaps the most important variable discussed was Cost. The project go, no-go decisions are generally taken on the cost basis only. The “Estimation as practice” relies on the skill, knowledge, resources and contexts of those involved in a situation. Estimations are ‘situated’ in the same way that other kinds of knowledge work are situated amongst context, history, place and moments in time. Accepted wisdom suggests that you make a guess, double it and hope for the best. Why? Novel valuable high tech requirements are by definition unknowns. And estimating how to produce an as yet unknown, unfinished thing is necessarily an art, not a science. But we don’t need to leave it there; there are some approaches and practices, that combined, enable us to make informed ‘guesstimates’ or scientific wild-ass guesses (SWAG) that help us overcome this bind.

“more software projects have gone awry for lace of calendar time than for all other causes combined… but adding manpower to a late software project makes it later.” (Brooks Jr., 1995)

For estimation, Allen introduced the class to an interesting notion of Planning Poker. Planning Poker is “played” by the team as a part of the Sprint Planning meeting. A Planning Poker session begins by the customer or marketing representative explaining each requirement to the extended development team. We use the term extended development team (often called the “whole team” by agile software developers) to refer to all those involved in the development of a product, including product managers, project managers, software developers, testers, usability engineers, security engineers and others. In turn, the team discusses the work involved in fully implementing and testing a requirement until they believe that they have enough information to estimate the effort. Each team member then privately and independently estimates the effort. The team members reveal their estimates simultaneously. Next, the team members with the lowest and highest estimate explain their estimates to the group. Discussion ensues until the group is ready to re-vote on their estimates. More estimation rounds take place until the team can come to a consensus on an effort estimate for the requirement. Most often, only one or two Planning Poker rounds are necessary on a particular requirement before consensus is reached.

Each group was instructed to use Planning Poker to estimate the cost in number of hours to build the Lego robot the class had built in the earlier session. Our group has 4 people and we used the provided poker cards to deduce the estimates. In most cases our estimates were quite close but still we need a few iteration of card playing before building the consensus around estimates.

The week three readings in Managing System Development course were articles on different software engineering methodologies.

Brooks Jr. F. P. (1987) No Silver Bullet Essence and Accidents of Software Engineering, Computer, 20, 10-19

Brooks_NoSilverBullet_1987

An interesting analogy between Software Projects and Werewolves and based on personal experience I can vouch that projects can turn overnight into monsters difficult to control and manage. A software project like Werewolves can destroy individuals, team’s even organisations. Once the things start going bad then heads start rolling starting from Project Managers, Configuration Managers & development leads in that order.

But to expect a Silver Bullet to kill the uncertainty & complexity is expecting moon. As Brooks rightly mentions this ambiguity & density is inherent in software engineering realm. “No other technology since civilization began has seen six orders of magnitude in performance-price gain in 30 years”

Brooks went philosophical when he invoked Aristotle to divide difficulties inherent into software realm into essences and production difficulties into accidents. But I don’t believe philosophy is going to help us here. The difficulties inherent in the nature of software as well as during production of software are varied in nature and collating these into any single philosophical term is to over simplify the problem. In software development we are trying to describe a bit of our own intelligence, personality traits & inter human dynamics which is not easy.

I liked Brook’s division of essential difficulties in nature of software into

1) Complexity

2) Conformity

3) Changeability

4) Invisibility

And agree with him that the past breakthroughs have partially solved some glaring issues. For example High-Level Languages, Time Sharing & Unified Programming Environments have to an extent given us perhaps a Silver Pellet if not a Bullet per se.

As the article is quite old so the future hopes on the horizon at that time have since come and gone.

1) Ada

2) Object-Oriented Languages

3) Artificial Intelligence

4) Expert Systems

5) Automatic Programming

6) Graphical programming

Most of these programming constructs have since been used extensively and retrospectively most of these constructs have helped in the advancement of Software Engineering.

Most effective statement in the article comes in the Incremental Development section which is grow, don’t build software. I agree the industry has evolved from writing software to building software and the next step in evolution should be to grow software.

Racoon, L. B. A. (1995) The chaos model and the chaos cycle. ACM Sigsoft Software Engineering Notes, 20, 12

Racoon_TheChaosModelAndChaosLifecycle_1995

This is the most insightful of the articles I’ve read on software engineering and I totally concur that the developer’s viewpoint has been overlooked in traditional models.

The software engineering is complex in nature and Chaos model “which combines a simple, people oriented, problem-solving loop with fractals” is a good fit in that. Racoon’s analysis on how Chaos model “improves or understanding of the contribution and limitations of users, developers, and technologies” is enlightening. And it does makes sense when Chaos Model is used to “define the phases of the life cycle in terms of fractals and show that all phases occur throughout the life cycle”.

Now when I look back and analyse poorly executed projects using linear Problem-Solving loop, the failings can be derived from the Problem Definition phase. Most of the time all resources & time is spent in solving wrong problems. The acceptance of the fact that project life cycles are not linear but fractal in nature can definitely allow us to approach the problems from different viewpoint. The traditional software techniques do not agree on the fact that all levels of software development have the same value to the project as a whole. And it is part of the problem a uniform focus instead of focus on few large issues by top management and running down from that order results in skewed projects.

I totally agree that software development is a Human activity and enough checkpoints should be put in place to ensure

1) Developers don’t mistakenly identify the problem or ignore the problem definition

2) Wrong technology is not used or right technology is not misused

3) Miscommunication is avoided in the project team

Fractal phase definitions can be used as an alternative method during project management to get a different viewpoint.

1) Requirement Analysis

2) Design

3) Implementation

4) Maintenance

5) Prototyping

But it is to be used with a caveat that it is long winding method and needs strong PMO to ensure that the project does not get trapped in a fractal mess.

Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan, (2010) Scrum + Engineering Practices: Experiences of Three Microsoft Teams

WilliamsEtAl_SCRUMExperience_2010

It is a good read on Scrum Methodology which is an agile software development process that works as a project management wrapper around existing engineering practices to iteratively and incrementally develop software.

The authors have tried to summarised their findings with three different Microsoft teams which implemented Scrum Methodology to execute projects. The teams are varied in size and nature and the projects also have a a number of different variables. To the uninitiated Scrum is composed of the following project management practices:

• The Product Owner creates the requirements, prioritizes them, and documents them in the Product Backlog during Release Planning. In Scrum, requirements are called features.

• Scrum teams work in short iterations. When Scrum was first defined [16, 29], iterations were 30-days long. More recently Scrum teams often use even shorter iterations, such as two-week iterations. In Scrum, the current iteration is called the Sprint.

• A Sprint Planning Meeting is held with the development team, testers, management, the project manager, and the Product Owner. In the Sprint Planning Meeting, this group chooses which features (which are most often user-visible, user valued, and able to be implemented within one iteration) from the product backlog are to be included in the next iteration, driven by highest business value and risk and the capacity of the team.

• Once the Sprint begins, features cannot be added to the Sprint.

• Short, 10-15 minute Daily Scrum meetings are held. While others (such as managers) may attend these meetings, only the developers and testers and the Scrum Master (the name given to the project manager in Scrum) can speak. Each team member answers the
following questions:
o What have you done since the last Daily Scrum?
o What will you do between now and the next Daily Scrum?
o What is getting in your way of doing work?

• At the end of a Sprint, a Sprint Review takes place to review progress and to demonstrate completed features to the Product Owner, management, users, and the team
members.

• After the Sprint Review, the team conducts a Retrospective Meeting. In the retrospective Meeting, the team discusses what went well in the last Sprint and how they might improve their processes for the next Sprint.

The Scrum based process used by teams was as following

1) Basic Scrum: All teams began with four week iteration of the Scrum Process as described above. The teams performed “just-in-time” design of features before or during the iteration in which feature was to be developed.

2) Planning Poker: The teams used Planning Poker to estimate the person hours required to complete functionality within an iteration.

3) Continuous Integration: The teams utilised the continuous integration practice where members of a team  integrate their work into the main build frequently.

4) Unit Test-Driven Development: With this practice, a software engineer cycles on a minute-by-minute basis between writing failing automated unit tests and writing implementation code to pass those tests.

5) Quality Gates: The Microsoft teams call their done criteria “quality gates”. The quality gates established for these teams included the following:

• All unit tests must pass
• Unit test code coverage must be at least 80% (for
all teams except Team B)
• All public methods must have documentation
• All non-unit test code must not have any static
analysis errors or warnings (see Sub-Section 9 of
this section)
• Build must compile with no errors or warnings on
the highest level

6) Source Control: Source control is management of changes to documents, programs, and other information stored as computer files through a source control system. The Microsoft teams used the Visual Studio Team Foundation Server Version Control tool.

7) Code Coverage: Engineers were required to manage their automated unit test coverage and monitored this coverage with each build. Two of the teams (A and C) followed the Microsoft Engineering Excellence recommendation of having 80% unit test coverage.

8) Peer Review: In each iteration, the teams conducted design reviews of architecture diagrams and of code when adding new features.

9) Static Analysis Tool:  The use of static analysis tools can identify common
coding problems [17] or unusual code [1] early in the development process [9]. The teams utilized the FxCop static analysis tool built into Visual Studio.

10) XML Documentation: The team used .NET-style inline XML generated documentation on all public classes, properties, and methods. As a result the code was self-documenting.

The findings of the study was that the productivity of the teams as they transitioned to
agile temporarily dropped for three iterations. The team attributed this drop to their unfamiliarity of Scrum and required a “gelling” period to start delivering value based on
the development process. From their fourth sprint on they experienced a significant improvement in productivity without an increase in defects. Teams transitioning to the
use of an agile software development should plan for a similar temporary productivity decrease.

Teams that used Scrum and sound engineering practices showed better quality in terms of defect density compared with similar non-Scrum teams including data benchmarked across 40 projects from nine companies. These results indicates that Scrum combined with sound engineering practices have the potential to yield a higher quality product. Team B that followed Scrum but the engineering practices to a lesser degree than Teams A and C had the highest defect density.

Allen gave the class choice of different enquiry methods for a small research exercise. Elena & myself picked up Extreme User Interviews as our enquiry method for this exercise.

Extreme User Interview is a very useful technique to highlight key issues of design problem. In this individuals are identified who are either extremely familiar or unfamiliar with the product and then asked to evaluate their experience using it.

Elena & myself decided to pick Smart Phone as a the product to research on using this technique. We decided to interview two people each who either are using smartphones as of now or who have never used it before. We decided to conduct two interviews with each person, one preliminary and other one where we dig deeper into the product features.

The results are summarized below, we found the technique very useful for firming up the product design issues.