| Deletions are marked like this. | Additions are marked like this. |
| Line 15: | Line 15: |
| * See also http://www.loudthinking.com/arc/000538.html#comments |
Jerry Weinberg's book, Weinberg on Writing: The Fieldstone Method (093263365X) describes a technique of gathering ideas like fieldstones until you have a collection with which you can build a book. Such a technique may not make you a William Faulkner or William Shakespeare, but it will enable anyone to become a journeyman author.
Fieldstones can come from anywhere. Here are some pointers to some I've come across:
Watts Humphrey's paper [http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2003/1q03/watts-new-1q03.htm Some Programming PrinciplesRequirements] says this:
These programming principles are as follows:
- When we program, we transform a poorly understood problem into a precise set of instructions that can be executed by a computer.
- When we think we understand a programs requirements, we are invariably wrong.
- When we do not completely understand a problem, we must research it until we know that we understand it.
- Only when we truly understand a problem can we develop a superior product to address that problem.
What the users think they want will change as soon as they see what we develop.
Jeff Sutherland has termed this Humphrey's Requirements Uncertainty Principle - for a new software system, the requirements will not be completely known until after the users have used it.
See also http://www.loudthinking.com/arc/000538.html#comments
Alistair Cockburn's paper [http://alistair.cockburn.us/index.php/Foundations_for_Software_Engineering Foundations for Software Engineering], which has much wisdom about the nature of Engineering, also has this gem of a metaphor:
Some programming languages are very malleable, such as LISP, APL, Smalltalk, Python, and Ruby. Other languages are less malleable, such as Ada, C++, and the other strongly typed languages. Programmers sometimes compare working in the former languages to working with clay and working in the latter languages to working with marble. Wonderful sculptures can be made from either clay or marble, but the necessary skills and the approach differ significantly.
Gojko Adzic's [http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/ How to develop software like commanding a tank] talks about how to give direction such that those directed can continue to make progress in the face of the unexpected. The main points are to communicate not just the "what" and "how," but the "goals" and "anti-goals" (or problems to watch out for) as well. He reports the changes seen in the work of junior, senior, and mid-level programmers using this technique. He also warns of three challenges:
- "identifying and expressing true goals, not just repeating specifications or requirements"
- "a single project should not have too many goals," and
- how to "pass on the goals throughout the organisation without overloading people with information."
Fast Company [http://www.fastcompany.com/magazine/94/open_change-or-die.html Change or Die] (Issue 94, May 2005, Page 53) by Alan Deutschman:
Instead of trying to motivate them with the "fear of dying," Ornish (Dr. Dean Ornish, a professor of medicine at the University of California at San Francisco and founder of the Preventative Medicine Research Institute, in Sausalito, California) reframes the issue. He inspires a new vision of the "joy of living" -- convincing them they can feel better, not just live longer. That means enjoying the things that make daily life pleasurable, like making love or even taking long walks without the pain caused by their disease. "Joy is a more powerful motivator than fear," he says.
...
In Louis V. Gerstner Jr.'s successful turnaround of IBM in the 1990s, he learned the surprising importance of this kind of emotional persuasion. When he took over as CEO, Gerstner was fixated on what had worked for him throughout his career as a McKinsey & Co. consultant: coolheaded analysis and strategy. He thought he could revive the company through maneuvers such as selling assets and cutting costs. He quickly found that those tools weren't nearly enough. He needed to transform the entrenched corporate culture, which had become hidebound and overly bureaucratic. That meant changing the attitudes and behaviors of hundreds of thousands of employees. In his memoir, Gerstner writes that he realized he needed to make a powerful emotional appeal to them, to "shake them out of their depressed stupor, remind them of who they were -- you're IBM, damn it!" Rather than sitting in a corner office negotiating deals and analyzing spreadsheets, he needed to convey passion through thousands of hours of personal appearances. Gerstner, who's often brittle and imperious in private, nonetheless responded admirably to the challenge. He proved to be an engaging and emotional public speaker when he took his campaign to his huge workforce.
...
Radical Change Reframing alone isn't enough, of course. That's where Dr. Ornish's other astonishing insight comes in. Paradoxically, he found that radical, sweeping, comprehensive changes are often easier for people than small, incremental ones. For example, he says that people who make moderate changes in their diets get the worst of both worlds: They feel deprived and hungry because they aren't eating everything they want, but they aren't making big enough changes to quickly see an improvement in how they feel, or in measurements such as weight, blood pressure, and cholesterol. But the heart patients who went on Ornish's tough, radical program saw quick, dramatic results, reporting a 91% decrease in frequency of chest pain in the first month. "These rapid improvements are a powerful motivator," he says. "When people who have had so much chest pain that they can't work, or make love, or even walk across the street without intense suffering find that they are able to do all of those things without pain in only a few weeks, then they often say, 'These are choices worth making.' "
[http://www.easycomp.org/cgi-bin/OrgPatterns?OrganizationalPatternLanguages Organizational Pattern Languages]
James Shore, in [http://jamesshore.com/Change-Diary/Intermission.html Change Diary]:
Although I made plenty of mistakes--I should have been more inclusive, for one--those mistakes didn't hurt me in the long run. The one mistake that came back to haunt me had nothing to do the techniques I used to inspire change.
No, my biggest mistake was different. I was too sure of my solution. Ultimately, an agile approach was the wrong approach for this project.
The right approach was not to do the project at all: it couldn't be accomplished in the time available.
James Shore, in [http://jamesshore.com/Change-Diary/Weeks-One-Through-Eight.html Change Diary]:
I seem to remember making this fundamental mistake over and over. It was really a problem of arrogance: I thought I knew the answers and I thought all I had to do was show the yokels how to do things right.
No, I didn't really think of people as "yokels." I knew this arrogance was a problem and I tried to suppress it. I even wrote some notes about not being arrogant. But arrogance simmered deep-down. It prevented me from going to the group and asking their permission to make decisions together. Rather than work with the group to come up with good ideas, I tried to sell the group on my ideas. If I had worked with them, I would have been much more effective.
- Michael Hill (on the XP mailing list):
There are four criteria for a good [user] story:
Verticality -- It must run from "pixels to bits".
Testability -- It must be testable.
Fit -- It must be small enough to fit comfortably in one iteration.
Value -- It must be something the customer wants.
from Mark Gerzon's [http://hbsworkingknowledge.hbs.edu/pubitem.jhtml?id=5351&t=leadership Moving Beyond Debate: Start a Dialogue] article:
As I worked in more than a hundred organizations or communities over the past decade, I kept track of which form of discourse my clients most often wanted. They did not want more speeches and presentations. They did not want more debates between two know-it-alls, each of whom was sure they were right and the other person was wrong. They did not want yet another "exchange of views" that skirted difficult issues and papered over problems. What they yearned for was deep, honest, inclusive, and respectful dialogue. Dialogue is designed for situations in which people have fundamentally different frames of reference (also called worldviews, belief systems, mindsets, or "mental models"). "Ordinary conversation presupposes shared frameworks," says Daniel Yankelovich, who has been a pioneer in analyzing public opinion for the past quarter century. Dialogue makes just the opposite assumption: It assumes that the participants have different frameworks. The purpose of dialogue is to create communication across the border that separates them. It is a way of conversing that:
Enables a wider range of feelings to be expressed than in debate.
Inspires more honesty and forthrightness than other methods.
Avoids superficial, forced compromises.
Generates learning, new options, and innovations.
Increases the likelihood that everyone will be "heard."
Seeks the deeper truth in each perspective.
Simply put, dialogue fosters the trust that is essential to leading through conflict. Its purpose is not to be nice. Its purpose is to be effective. When it comes to conflict, it is far more effective to build trust than to deplete it. Every tool we have used so far has helped to lay a stronger foundation for trust building."
from Ed Gibb's blog, [http://edgibbs.com/2006/05/01/agile-methodology-context/ Musings of a Software Development Manager] blog:
"At the end of the day, it all comes down to common sense." Its a relevant point and one I tend to get caught up in. The point is really to adjust the process to fit the needs of the team and the context while making forward progress.
from Skip Angel's [http://spaces.msn.com/chiefskipper/blog/cns!A59D550BCED8263B!851.entry?_c=BlogPart#permalink Random Thoughts from a CTO] blog: In talking about the four project variables, Cost, Schedule, Scope, and Quality, Skip says,
"Clarify your quality. Make sure that the project team knows how to measure the success of the project (In other words, what is good enough?). What are your quality criteria i.e. performance, scalability, usability? What is the threshold measure for each of the criteria e.g. Each function must handle x customers at once time at take no longer than y time? What is the priority of each of the criteria?"
Where in here is the Quality that differentiates extensible, maintainable code from cut-and-paste hack-it-together spaghetti? That's the Quality I mean.
from Annie Lamott's Bird by Bird (via [http://ellen-kushner.livejournal.com/42408.html?thread=478376#t478376 Ellen Kushner's blog]):
"I thought such awful thoughts that I cannot even say them out loud because they would make Jesus want to drink gin straight out of the cat dish."
Bruce Eckel's [http://mindview.net/FAQ/FAQ-006 definition of mentoring]:
Consulting guidance on a project - that is, a team is working on an actual project and the mentor comes on site periodically and helps "steer the boat," which includes reviews and walkthroughs of design, code, and/or process. You could think of it as "someone to watch over you."
J. Steven York's [http://york-multiplex.blogspot.com/2006/03/writers-and-other-delusional-people.html writing blog] states:
"Stealing words is a crime. Stealing ideas is frequently a smart thing to do, but always steal from the best. Start with Shakespeare and work your way forward."
"And remember that you don't even have the right to call yourself a failure if you don't try, and you still don't have the right unless you've stopped trying. Until then, you're still a success waiting to happen."
[http://www.altisinc.com/Links/100_Rules.html One Hundred Rules for NASA Project Managers] by Jerry Madden includes such gems as these:
Rule #8: Running fast does not take the place of thinking for yourself. You must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.
Rule #43: Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have happened, and reality. Documents are normally a static picture in time that get outdated rapidly.
Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. Get the basic system working first and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world that the newer version works. It is necessary to have contingency plans for software.
Rule #82: Wrong decisions made early can be recovered from. Right decisions made late cannot correct them.
Rule #87: Projects require teamwork to succeed. Remember, most teams have a coach and not a boss, but the coach still has to call some of the plays.
Rule #88: Never assume someone knows something or has done something unless you have asked them; even the obvious is overlooked or ignored on occasion, especially in a high stress activity.
Rule #90: A puzzle is hard to discern from just one piece; so don't be surprised if team members deprived of information reach the wrong conclusion.
Rule #94: Mistakes are all right but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.
Rule #96: Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
Rule #100: Never make excuses; instead, present plans of actions to be taken.
Also see this [http://appl.nasa.gov/ask/issues/14/practices/ask14_lessons_madden.html similar and related list].