I use a simple poll of how safe people feel. I got this from Norm Kerth’s book, Project Retrospectives (page 110). Norm describes this as part of an exercise to increase the sense of safety in the room and promote honest and open speech. In the context of a day-long-or-more end-of-project retrospective, then I can see the value of such an exercise. For an heartbeat retrospective, I don’t attempt this. I’m not optimistic about significantly raising the level of trust in a short period of time. There will be other retrospectives, and there will be time to work on trust issues in between. It’s often helpful, though, to bring the issue of trust and safety to the surface.

For getting a sense of the safety in the room, I’ll ask people to rate their feeling using this scale:

1.    I’ll just keep my mouth shut
2.    I’ll agree with whatever the group says
3.    I’ll discuss the non-controversial topics
4.    I’ll discuss almost anything
5.    I’m willing to talk about anything

I have everyone write a number on an index card or sticky note as a private ballot, and fold it so the number is not visible. I will then collect the ballots (or delegate to someone who seems both trusted and without power over others) and count the number of each value. On a whiteboard or flip chart I’ll record these with hashmarks. This gives a simple obvious view of the reported safety.

Sometime I’ll point out that this is only the reported level of safety. After all, if someone doesn’t feel safe, they may not feel safe enough to answer this question openly, either. They may give then number that they think is expected, or the one they think others will give.

Retrospectives are difficult in low-trust situations. They’re also a great tool for building trust over time.

Given-When-Then describes the scenario in chronological order, which also makes it easier to automate. Often I don’t implement it in that order, though. Instead, I’ll flesh out the Then with code fixtures first, as the results are the primary focus. The When is usually a straightforward single interaction with the system. The Given describes the business pre-requisites, and these get translated into actions that make the When interaction work. Starting with the Given can lead us astray into specifying things that don’t need to be specified for this scenario.

Sometimes we discover that there are other pre-requisites, too. These may be things that are simply taken for granted or implied by the specified context of the test. We take for granted that the system is up and running. Having money in the account implies that the account has been opened. We also assume that there are no special cases in the context that would invalidate this scenario. The account having a hold put on the account by the fraud department is not a reasonable assumption. This is a case that needs checking, but in another scenario where the special context is explicitly mentioned.

If there are other things that need to be initialized for this test that are not mentioned in the Given setup, then it’s time to pause to reflect. Could this indicate a mismatch between the world envisioned by the business and the implementation in the system? That could be something to correct. Or might it be something that is often implicit in business conversation, but needs to be explicit in the test. Maybe the type of account affects whether or not a fee is applied to withdrawals. Sometimes the business gets into the habit of speaking in shorthand that leaves out some important distinctions.

I’m still happy with “Given <this context>, when <an interaction occurs> then <a result>” as a formula for acceptance tests or executable requirements. I don’t know that this is the only good formulation. I’m still looking for others that would naturally occur to business people, and would love to hear some examples if you have them. While I don’t think Do-When-Provided is natural business-speak (I could be wrong in some businesses), it’s good to consider alternatives.

Given-When-Then is a formula. While it can help stimulate our thoughts, it shouldn’t limit them.

In the same manner, Mike Cohn’s canonical expression of a User Story, “As a <type of user>, I want <some goal> so that <some reason>,” helps us to remember to think about which user and why they’re requesting this. I generally counsel teams not to actually write their stories in this way, as it often results in a wordy and repetitious list that obscures the essence of the story instead of highlighting it. There’s nothing like a long list of “As a customer, I want <to do something> so that I can make a purchase.” The formula can lull you to sleep. I’ve seen examples of this were “making a purchase” was not really what the customer wanted, it was the way what the customer wanted was implemented. And I’ve seen “As a user…” fill in for customer, obscuring the fact that not all users of the system are customers, and not all stakeholders who want something from the system are users.

These formulae are thinking tools. Use them in ways that provoke thinking. If they’re just chores to be done or checkboxes to be checked, they’re not helping.

One of the low points was when several people, including a business analyst, product owner proxy, and the program manager, individually said that they couldn’t alter the “user stories” to cut across multiple components of the system because they were already in the computerized planning tool (and Word documents) and it would be too much work. That team did not appear to be getting much value from their “Agile approach” and had significant integration risk that was being studiously ignored.

One of the most frequently asked questions on public mailing lists and forums devoted to Agile development is “What Agile Planning Tool should we use?” There is always a chorus of answers touting this or that computerized tool, usually without asking any questions about the context. Is there one best tool?

Given the number of such tools available, either for purchase or for free, people are still seeking that perfect tool. Like Lord Franklin seeking the Northwest Passage, some pay a heavy price for that search.

What’s the big difference between the two situations described above? The first difference is that one was using a physical planning tool and the other a computer program. Should we take that as evidence that physical tools are always preferred and computer programs should be eschewed? That would be hasty without looking deeper. Our second “why was one team more successful than the other” answer is that the first team adapted their process according to the successes and difficulties they were having. The second held to a “consistent process” when it was getting in their way.

One of the biggest problems for teams trying to learn how to be successful with Agile techniques is that they often don’t recognize what’s getting in their way. They’re often trying to do things “by the book” to learn Agile practices–which is a good starting point. But they’ve not yet got enough experience to see the early warning signs of Agile impediments, and by the time they do, they often jump to the conclusion that “Agile doesn’t work.”

Let’s look at a recent inquiry on the Agile Project Management yahoogroup. The questioner mentioned that his small team was moving to Agile/Scrum and because they were partially distributed, were looking for “a product management platform at least to enable a virtualized scrum board and some basic reports like the burn down chart, etc.”

Some people opined that, because they were distributed, only an electronic tool would work. This isn’t necessarily the case. I’ve heard several reports of successfully using physical boards duplicated at each location. I can see some real advantages to this approach. One of the biggest challenges of distributed development is keeping the assumptions and attention of each location in sync with the others. Talking through the changes on the board on a daily (or more frequent) basis is an excellent means to accomplish this. Having silent changes that happen in the background within a computerized tool while you’re not looking, is not.

As it turns out, the team isn’t really distributed. The product owner and another business stakeholder is remote to the development team. The product owner makes an effort to be regularly engaged, but wants to give more visibility to the other business stakeholder. Using a distributed planning tool for this sets off warning bells in my head. It’s making the daily work of those producing the software more difficult for the benefit of someone who is insufficiently engaged in the process. I often hear the counter argument that “it’s only a few seconds to use the tool.” That may be, but those few seconds are multiplied many times over during the course of the project. They become a real drag on productivity and lengthen the cycle times. I’ve not measured the effect, but I’ve seen it clearly. Worst of all, it eventually discourages people from making improvements to their process because they’ve got so much invested in the current incarnation.

There are more insidious effects, too, when an electronic tool is being mandated just to observe from afar without engagement. The information that goes into the tool becomes a public record, and people start worrying about how to make it look good to others rather than how to use it to get work done. This is an even greater productivity friction, and it siphons attention away from the original goal.

The product owner of this team would do far better to develop a sprintly summary for the other stakeholder. Business stakeholders don’t really need visibility into the details within a sprint, anyway. If they truly do, then the sprints are too long. Broadcasting all of the minute details of how people are working just invites micromanagement and breeds distrust.

This is just one case study. In other situations, I would call attention to different details and likely offer different advice. Covering all the cases would be far too much for a blog posting. Besides, the real point is that people need to keep their ultimate goals in mind, and not trade thoughtful observation and decisions for the magic of a virtual tool.

P.S. Tim Ottinger and Jeff Langr have published some very good advice on this topic.

There are those looking at it from the point of view of usability and fitness for use. Some, often closely aligned with these, use the word “design” to talk about the visual aspects. Others, the user experience.

Others look at the manner in which the software is constructed. Those who use the title of “Software Architect” often look at the big picture aspects–what frameworks will be used and how the system will be distributed. DBAs look at the schema of the persisted data as design. Those who write the code see design in the modules, classes, methods and functions–and how they interact.

Some people think that design is something you do before building the system, often drawing diagrams to illustrate their ideas. Some go so far as to assert that if this is not done prior, the system is not designed at all. Others maintain they can do just as well designing on the fly, mostly capturing the design directly in the code, but also describing it in conversation and sketches. Still others say the real design is “as built,” and the original intent is not so important.

People use “design” to refer to all sorts of small tidbits in the development process. They abstract some of these and call them “design patterns.”

Sometimes people use the word “design” to mean “the important stuff I do while I leave the mere implementation to others.”

All this is just about software, and is surely not exhaustive. When you add physical products to the mix, the definitions multiply. Any discussion about design that doesn’t develop a shared understanding of what is meant by “design” is sure to cause difficulties. And public utterances about design will always be interpreted differently by some people.

Oops! There are no photos beyond last March. I felt sick to my stomach. That’s a lot of family memories to evaporated. Whew! The program we’ve been using to download the cameras also makes a backup copy local to the machine used to download. I’ve got all the pictures back on the photo server, and now just have to sort them into directories again.

But first, I need to fix the backup script. Why didn’t it warn me when it started to fail?

I copied a version on a different fileserver to that machine and edited it for the different source and destinations. It’s a simple shell script that mounts the USB drive, runs rsync to duplicate the data, and then unmounts the USB drive. I’d run into a problem once before where the drive wasn’t getting mounted properly, so I’d added some script to detect that and email me using msmtp if it failed. That only worked for mount errors, though, not for rsync errors.

As I hacked in detection and notification of rsync errors, I felt ill at ease. I was duplicating some of the script to send emails. The script was getting harder to read. The script was increasingly inconvenient to test. And I was nervous about introducing new errors.

I started practicing Test Driven Development a decade ago. It has become second-nature to me to test-drive the code I write. Why was this code just hacked together? Mostly because I hadn’t been thinking of it as code. It was just a script. At first, it just replicated the commands I typed on the command-line. I put those into a script to make it easy to run, and then to automate running it via the <del>chron</del> cron daemon. When I replicated it to another machine, I extracted the paths to variables to make it easier to change the differences. When it had failed to mount a drive, I’d added a check for that and a line to send me an email. That line surely crossed the border between “a file of commands” to “a program,” but I didn’t notice it at the time. Or, if I did notice it, I didn’t pay attention to it. After all, I don’t generally program in bash scripts and haven’t developed any rigor for doing so. It’s those “little” changes that “can’t possibly” hurt that bite you the hardest.

The script now “seems to be working,” but I’m not satisfied. Wouldn’t it be nice to get advance notice when the disk is getting close to full, rather than waiting until it is?

I now know I’m programming in sh, not just collecting a bunch of command-lines from my .history file. Adding the email notification of rsync errors was harder than I expected due to tiny errors made in an unfamiliar programming environment. In addition to being hard, it just felt “dirty.”

A little googling lead me to shunit2. After a little difficulty creating a tiny virtual disk under control of the tests, I quickly had a function that extracted the % full output using the du command and returned it as a number. Great! Now I can use that number to provide an early warning. And working test-driven is teaching me better shell scripting habits.

I’ve still got work to do, pulling the existing script into tested functions, but already I feel better. I’m on my way to a reliable and maintainable script.

I spent a chunk of my career where I often worked solo on projects that might get enhanced every year or two. This taught me a lot about the importance of code readability and what sort of things helped me quickly understand and avoid overlooking important considerations. I’ve also worked on a lot of legacy code bases, so I’m well aware of the pain and problems created by code that’s not readable, or is not organized in a helpful manner.

Last week at the AgileDC Conference, someone told me they were working on code I had written ten years ago. My first question was, “Are the unit tests still working?” This code was the first production code I ever wrote test-first, and it taught me a lot doing so. I was glad to hear that they had been maintained. When I was writing them, I couldn’t get anyone else interested in test-first development.

Even more gratifying was hearing that they’d recently used some of my code as an example in a discussion of object-oriented programming. The example they’d used was where I’d wrapped an integer in a class. Why would I do that? Because it wasn’t really an integer. It was a database ID. The integer was just an artifact of the database automatically creating ID values using a sequence. It would make no sense to perform arithmetic on it. And there were IDs for various entities that should not be used interchangeably.

The integer value was intended to be used only within the Data Access Object that read and wrote the database.

A few years ago, I was asked if I could change an algorithm in some embedded assembly code that I’d written more than ten years prior, and I hadn’t even seen for over ten years. Setting up the development environment wasn’t easy, as much of the hardware was no longer manufactured. The code, however, was not hard to modify. I had implemented the algorithm using state machines and data tables, and had created semi-readable constants for all of the “magic numbers” used.

Code is read much more frequently than it is written. Writing it clearly and expressively pays off when we have to read it next week or next month. Well-written code is also much more likely to be useful for decades into the future. If you write code only for the short term, it’s likely to have only a short life. People will find it necessary to rewrite it rather than maintain it for the long term.

My advice is to

• measure your progress
• watch the trends
• project the trends tentatively into the future

and relax.  It’ll work out the best it can.  False precision won’t make it any better.

Now I just read The Virtues of the Imprecisely Measured Self by Alex Knapp at Forbes. He tells the tale of a study in the journal Psychological Science April 2011 that indicates that precision, whether false or not, inhibits success.  Alex summarizes,

Precision can actually be the enemy of performance goals. To be sure, feedback is definitely a positive thing. But it appears that if you want to keep yourself motivated, it’s best to get a more generalized, imprecise feedback that lets you know you’re heading in the right direction, rather than the precise coordinates of where you are on the path.

It’s something to think about.

Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.

There are some very good reasons for this. For one thing, it’s unlikely that you’ll find much business value in delivering a system that allows people to login, but do nothing else. Unless you’re writing a login package for others to integrate into their code, something else is the central idea of the system. Surely there are some things about that central idea that we don’t yet know in detail. By contrast, “login” is fairly widely known and understood (even if sometimes implemented poorly). Even if we decide we can’t deliver the system without “login,” we can learn important things earlier if we work on the central idea first. (And I can imagine, in a pinch, having a usable system where access was controlled by putting the computer in a secure room where only those with authority could touch it.)

Learning important information sooner is one of the subtle but powerful benefits of working in an Agile fashion. It can help the business make better decisions about priority, or even about the direction of the effort. That’s one of the tenets of the Lean Startup focus, but it works for established organizations, too. There’s almost always something new about what we’re doing, or we wouldn’t be spending money doing it.

This pattern of accelerating learning is powerful for businesses that use it. But it’s also powerful for programmers working on the code. As we build our application, we can learn about better ways to structure the code, and we can use that information when we’re writing further code. I’ve found this to allow me to do a better job when developing code in an iterative-incremental fashion than when creating an up-front design and then following it.

Let’s look in more detail at Jon’s suggested beginning:

For example, to start, you can simply check that the response has “Login Succeeded” ( or “Login Failed” for testing that a bogus login attempt does indeed fail). …simply:

Scenario: Successful Login
    When I login as admin
    Then I should be logged in

Scenario: Failed Login
    When I login as asdf56ghasdkfh
    Then I should be not logged in

And your steps would hide the logic for filling in the login form and checking for success:

Given /^I login as "([^"]*)"$/ do |login|
  @login_name = login
  visit login_path
  fill_in "login", :with => login
  fill_in "password", :with => "password"
  click_button "login_button"
end

Then /^I should be logged in$/ do
  response.should contain "Login Succeeded"
end

Then /^I should not be logged in$/ do
  response.should contain "Login Failed. Please try again."
end

Given this simple start, where will we put our access control logic? Most likely in our Controller of MVC or Presenter of MVP. Then we’ll decide to which page we direct the user. In effect, we’re protecting the “Login Succeeded” page from the unauthenticated. Is that page the asset whose access we want to control?

I once worked with a client who had an application that allowed authorized users to access the documents to which they were authorized. It was not an Agile shop, and they were not working in short iterations using small stories. They had, however, been delivering new functionality in each release for a number of years. And they were very thorough programmers, carefully checking that they were not delivering bugs. Having started with the idea of access control, they had ended up with their authorization check in the Action class of their Struts app. Over time, there was a need for further authorization concerning some documents. Only an authorized user could see any document, but some documents were only available to a subset of users. The Action class checked that the user was logged in, retrieved the list of documents, and then filtered out the ones that particular user was not allowed to see.

Do you see any problem with this scheme?

It works well enough, but it causes some maintenance headaches. Even though there was not a link to the unauthorized documents, there’s nothing to stop a savvy user from guessing the URL and retrieving it anyway–so there had to be an authorization check there, too. And there were multiple lists of documents, so each one had to make this check. Sometimes when the authorization logic changed, one of the Action classes would be overlooked. Extracting this authorization filtering code to a method would reduce much of this duplication and make that particular mistake less likely, but some lists had different filtering rules. Also, the Action classes would retain the duplication of the order of steps that each one had to apply in order to properly protect the assets. (That’s a more subtle flavor of duplication that many overlook.) And there was a requirement to show some documents in the list to people who were not yet authorized to retrieve them.

It was pretty complicated and error-prone. Enforcing the security at the outer layer, instead of directly around the protected assets, resulted in more places and more variability in the implementation. I’m sure that you and I and Jon Kern would not end up with such an error-prone design. Jon is an excellent software designer–much better than I am. He can explain why you’d want to design in a particular way and describe the reasons why. I, on the other hand, have trained myself to be sensitive to duplication. Test-driving code with an aversion to duplication would lead me to a different design.

I helped these programmers implement a new feature–one that provided government-mandated access to certain documents even if the user wasn’t logged in at all. Since this required a change to all of these access controls, it provided the impetus to change the design. While adding this new requirement using Test Driven Design, I also refactored code to remove the duplication. As I did so, I pushed the access check lower in the code, passing along a “AuthenticationToken” object that could be treated as a black box by intervening layers. Ultimately the access check was made in the database queries themselves, insuring by simple inspection that no path in the user interface could lead to a condition that allowed unauthorized access.

You’re probably a good programmer, too. I’m sure you wouldn’t make a mistake. Linda Rising recently told me that 80% of people think they’re above average, so you must be good. As it happens, the programmers who built this system were pretty good, but they weren’t experienced in the technology. This J2EE system was the first Java code they’d ever written. These programmers generally succeeded by being very careful to check all the paths. Only very occasionally did they miss one and allow a bug to escape to User Integration Testing.

It’s my contention that by implementing the primary functionality first, in this case the listing and retrieval of documents, then we’ll be more likely to naturally put the access control directly around the assets that matter. In other situations, there may be other considerations for the access control that would be different from the application I described. In any case, if our primary story is

When I do whatever my application does
Then I get the result of doing so

in all of the varieties of “do,” then the proper place for access control will be obvious for more than 80% of us when we get to the story

Given I am not an authorized user
When I do whatever my application does
Then I am denied the result of doing so

While it is certainly true that we can get to the desired design anyway, as both Jon’s blog and my story above illustrate, it’s easier, more direct, and more likely that we’ll do so if we start with our primary business functionality before the LOGIN story.

It’s not a law of the universe, but it’s a good heuristic: The Login story is not the place to begin.

• A list of features to be built
• A release plan or timeline for those features
• Setting up development infrastructure such as version control or continuous integration servers
• Studying or practicing skills in new technologies they expect to use
• … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.  The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?”

The initial backlog really only needs to be one item in order to start delivering.  If you’ve got too many unknowns, then just start with one item.  Get the business stakeholders, the programmers, the testers, and anyone else who needs to be in on the discussion (User Experience? Ops?) to talks about it.  (I call this a meeting of the Three Amigos.)  What is the one obvious thing that needs to be done? (Hint: it’s not “login.” Start with the main purpose of the system.) I can’t imagine a situation where a project is started without any ideas at all.

Take that one thing, and slice it into thinner slices.  Decide on the examples that represent acceptance of those slices.  Some of the slices will have questions that can’t be answered.  Put those aside for the moment.  Choose the most central slice that travels through the entire concept from end to end, or as close to that as possible.  Estimate that as one team-iteration.  (Estimates don’t have to be “right.” They’re just estimates.)  Start building it.

Learn the necessary skills in the technology while accomplishing real work. Learn the parts that aid building the system, rather than developing the system according to some framework. When you don’t know how to accomplish something, or you think multiple approaches might work, do minimalistic spikes to give the information needed to make a decision.

Along the way, start slowly building your development infrastructure. Set up a local code repository. You can always migrate the code to an “official corporate” repository later.  Right now, there’s not much code. Set up a simple build-and-test script so that everyone builds in the same fashion. You can always add other build targets later. If you’ve got time, you can set up a Continuous Integration server. Otherwise, just do it manually. Checkout & build into a clean workspace. Do what’s needed to run the code so that you can show it working.

If you can’t accomplish this slice in one iteration, it’s probably not thin enough. Or, maybe you haven’t yet solved an essential technical problem. Or the goal isn’t yet clear enough. Figure out what impediment is most in your way, address that, and try again.

More likely, you’ll get this slice done in less than a iteration length. If you get this slice done before the end of the iteration, then pull in another slice.  Estimate this as “the rest of the iteration.”  Repeat as needed.  As long as you’ve gotten one slice done, you’ve got a potentially deliverable product increment.

Yes, there will still be development infrastructure to be developed. There’s no particular rush to get that done. Just keep improving it, so that it helps you get more done. Yes, there will still be technical skills to be developed. That should always be the case. Just keep experimenting and pushing your limits.

Yes, there will still be features to be added to the backlog, refined, prioritized, split into stories, and prioritized again. This should continue throughout the project. It’s part of the “steering” process. Yes, there will still be a need for projections to estimate when functionality can be released, or how much functionality can be released by a certain date. When you think you’ve got enough information about what needs to be done, then consider the initial release plan.  By then you’ll also have accumulated a little information about how fast things get done.

There will still be a lot of holes in your knowledge of what needs to be done and how fast things get done.  Don’t trust your initial release plan to be “right.”  It’s just a stick in the sand to help you judge how things are going.  Keep planning, and move the stick as needed. And as time passes, you’ll have a better and better indication of how fast the system gets developed. Even when you think the Release Plan is complete, it needs to be continually reviewed and adjusted. Since it’s never done until the release, there’s no particular hurry for a certain level of completeness.

This sort of beginning is very like the Hudson Bay Start that Johanna Rothman describes in her book, Manage It (pp. 52-53).

The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600-1700s in northeastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away. By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies–before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

There’s really no reason (other than “that’s not the way we do things around here”) that this can’t work for the start of any team/project. It’s a great way of learning the right stuff for the current situation while also making a bit of progress. I use this technique in my Agile in Six Months transition plan.

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me.

I wholeheartedly agree with Brian’s assertion that we have “a readiness to reduce (abstract away, simplify, generalize) the world’s complexity into something simpler that you can work with and think about.” This is not just true of knowledge workers, but of people in general. The assault of the universe on our senses is far too much to observe without doing so. As Brian says, “By default, we mostly act unconsciously, with the unconscious mind forwarding only anomalies to the rational part of the mind.” In other words, when the world around us is appearing to conform to the models that are most ingrained within us, we can react according to those models without making a conscious choice.

Other models are less ingrained, and we apply them more consciously.  Brian’s examples of the “homo economicus” and the “V-model of the Systems Engineering Process” models are good illustrations of models we’ve built particularly to help us with situations that our subconscious doesn’t handle.

Is there a fundamental difference between our unconscious and conscious models? As far as I can tell, it’s only in our awareness of them.  The study Brian uses to illustrate the power of the unconscious mind describes a detectable awareness between a cookie sheet and a chess board.  The unconscious model accounts for putting a cookie sheet into the oven, but does not account for putting a chess board into the oven.  Certainly both cookie sheets and chess boards are too modern to be innate to the species. Instead, the pattern of putting a cookie sheet is one to which we’ve become accustomed by familiarity. Or, at least, most of us have. Trying the same experiment with people unfamiliar with ovens, cookie sheets, and chess board would assuredly give different results.

Reductionist models are the way that both the conscious and unconscious mind deals with the sensory overload.  But the models we use can lead us astray.  As Brian says,

So sticky is the “homo economicus” reduction that economists face the occupational hazard of treating it as the only model of human behavior, which can make them say awfully silly things. Similarly, elegant and simple software development models like the V-model are so elegant, so simple, so pleasingly linear that their failure to work with real human behavior and limitations is commonly seen as the fault of the people, not the model.

H.L. Mencken put it this way, “For every complex problem, there is a solution that is simple, neat, and wrong.”  We are more likely to jump to an easy answer when we only know one model that fits the situation, or when we fit a model that’s so deep in our unconscious that we don’t notice it’s there.

If we are to avoid the trap of being limited by an inappropriate model, then we need to know more than one model.  And for the unconscious models, we need to find ways to rethink the situation according to conscious models.

In fact, this latter use is the value I find in the Myers Briggs Type Indicator model that so irks Brian. Brian would like for people to discard MBTI because it’s not “true” and doesn’t predict peoples’ behavior well. I, on the other hand, don’t expect either of these things from MBTI. It only aspires to be a model of preference, not behavior. While it often gets misapplied for things such as predicting what career path a person should take, that’s not, as far as I know, an intended use. And I don’t believe it’s “true” in the sense of corresponding to entities in the human psyche. Instead, it’s “true” in the sense that it corresponds to human observations, much as putting a cookie sheet in the oven does. I’m not even convinced that the preferences indicated by the MBTI are constant. I wonder if my preferences change slowly over time, and if they sometimes change rapidly and suddenly in response to the situation.

Whatever the faults of the MBTI as a model for people, it helps me to rethink the application of my unconscious models. As an introvert, my unconscious model might label an extravert as pushy and self-absorbed. Re-evaluating the situation in the light of MBTI, however, may suggest to me that they’re merely thinking out loud. As an NT (iNtuitive-Thinker), it’s easy for me to jump to the conclusion that the solution in my head is both correct and obvious. Realizing my preferences helps me to realize that it is unlikely to be obvious to others, and that I should test its correctness with some data.

We would do best if we always beware our implicit trust in our models, especially our deepest and most closely held ones. These are the models that allow us to act immediately and “instinctively.” But it is the model we don’t question that will most likely get us into trouble. From time to time, especially when things are not playing out to our liking, we can view the same situation in light of multiple models and see if they give us different insights.