Workaholics United : Consider All Factors (CAF)

In any situation, certain givens define the range of how we perceive it. By expanding the scope of considerations with a conscious effort, we can increase the span of our attention to aspects that might have otherwise been missed.

Consider All Factors (CAF) is an attention directing tool designed to do this. During a defined interval of time, you mentally list every consideration about a topic you can think of, as opposed to just the first few that come to mind.
An example

A shy person is invited to a party. His default reaction is to think, “I’m just not an extrovert.” For this exercise he decides to enrich his perspective by considering other factors in that social situation:

* Body language
* Greetings
* Response to questions
* Questions to ask others
* Dressing for impact
* First impressions
* Smiling
* Who’s there that I already know?
* Purpose of attending
* Anxiety created by unfamiliarity

Some considerations arguably overlap: first impressions, dressing for impact, smiling. It doesn’t matter, and would be counterproductive to censor new angles on what might be thought of as the same theme, since the only way to really know is in hindsight. In this case, the person might not have previously paid any attention to the role of personal appearance in creating good first impression, despite that factor being obvious to others.

By consciously distributing cognition around a topic, he gives himself new things to think about. The consideration “purpose of attending” might contrast with going to the party simply because he was asked, instead of having a deliberate focus to guide to his behavior. The consideration, “anxiety created by unfamiliarity” is interesting. One strategy for overcoming his social apprehension is to familiarize himself with everyone in the room, making as many introductions as possible to avoid being confronted with a crowd of strangers.
Other examples

We can “do a CAF” for a couple of minutes on just about any topic, either for better planning or simply for its own sake as a mental exercise. Doing a CAF on apartment hunting might yield:

* Commute to and from work
* Length of lease
* Rent
* Total move-in cost
* Impression of landlord
* Square footage
* Aesthetics
* Noise level of surrounding area
* Walking distance to amenities (e.g. stores, parks)
* Parking
* Consensus with other decision makers
* Furniture
* Pets
* Terms of rental agreement

Again, some overlap. Pets and lease length would be covered in the rental agreement, but isolating “terms of rental agreement” as a separate item might prompt the apartment hunter to look more carefully for unreasonable clauses instead of taking the contract for granted. Notice that the apartment hunter has also factored in “impression of landlord” as a conscious consideration rather than leaving it as an afterthought or subliminal intuition.

Starting a exercise program:

* Type of exercise
* Clothing
* Equipment
* Schedule
* Home, gym, personal trainer?
* Fitness goals (e.g. weight, running distance)
* Handling eventual decline in discipline or enthusiasm
* Nutrition
* Documenting progress

This person has identified a decline in discipline and enthusiasm as something to deal with before its onset. It’s much easier to plan for setbacks in advance than trying to address them while they’re happening.

And now to the essence of my point… If you apply CAF to a software programming task, and the benefits become much more apparent. Make it a habit to perform a CAF at the inception of a programming assignment, and you will experience that your estimates will be closer to actual outcome and that your solution quality will increase because you become able to handle many issues pro actively, which may in other cases have become problems and forced you to do hacks-tweaks in order to get the code to conform to functional requirements within your estimated time frame.

The more you practice the CAF operation, the easier it gets, and less inclined you are to be satisfied with accepting the first considerations that immediately come to mind. When you think about a new topic, you’ll begin to instinctively ask yourself, “What am I missing?”


Estimation : Off-The-Cuff Estimates

Project teams are sometimes trapped by off-the-cuff estimates.

A projectmanager on a team asks, for example, “How long would it take to implement this component”, while showing the developer a wireframe. The immediate response is typically, “I don’t know. I think it might take a week. I’ll check into it”, and of the developer is to his/her desk to investigate the functional requirements further. Back at the desk the developer looks at the design and code for the component, back at the desk the developer notices a few things forgotten when the PM asked the question, adds up the changes and decides that it would take about 3 weeks. The developer hurry over to the PM’s desk to update the first estimate, but the PM is in a meeting and therefore not to be found. Later that day the PM suddenly appear at the developer’s desk and happily notifies the developer (before this can get a word out): “Since it seemed like a small project, I went ahead and talked to the customer about it. He was very excited about it and can’t wait to see the component next week. Can your start working on it today?”.

I have found that the safest policy is NOT to give off-the-cuff estimates. Using intuition and guessing as basis of software estimates are almost always related with cost and schedule overruns.

One of the errors people commit when estimating solely from personal memory is that they compare the new project to their memory of how long a past project took, or how much effort is required. Unfortunately peoples sometimes remember their estimate for the past project rather than the actual outcome of the past project. If they use their past estimate as the basis for a new estimate, and the past project’s actual outcome was that it overran its estimate, guess what? The estimator has just calibrated a project overrun into the estimate for the new project.

While guessing and intuition most definitely are positively correlated with project overruns, another less recognized fact is that the use of documented facts are negatively correlated with project overruns. In other words, there is a world of difference between giving the PM an off-the-cuff estimate versus saying, “I can’t give you an answer of the top of my head, but let me go back to my desk, check a few notes, and get back to you in 15 minutes. Would that be OK?”.

While this is a simple point, off-the-cuff estimates is one of the most common errors that project teams make. So in order to become a better software engineer, we need to stop delivering off-the-cuff estimates !

This blog post is the first in a long series about estimation I will be doing. Estimation is probably the single most important skill next to actual programmatic skills for a programmer, and even for non-programmers estimation is one of the most frequently performed activities, however also one of the skills that we pay the least attention to.

First step in becoming a better estimator is to realize that off-the-cuff estimates are invalid and errorprone, and should be replaced by a structured analysis of the entity being estimated based on documented facts.