Rickerism

Tar-baby is a metaphor I find myself using and having to explain quite often. Metaphors are the essence of communication. They enable us to compare and contrast a situation in great detail with very few words. For instance, I can say “sour grapes” and evoke the entire Aesop story of the Fox and the Grapes to compare and contrast a particular situation. I assume that all literate individuals are familiar with Aesop’s fables and make the allusion with confidence. I cannot make the same assumption about Uncle Remus.

“The Tar-baby” is one of the stories by Uncle Remus. I heard these stories as a kid growing up the South. Maven’s Word of the Day sums up the idea quite succinctly:

Tar-Baby was a doll made of tar and turpentine, used to entrap Br’er Rabbit in the second of the Uncle Remus stories. The more that Br’er Rabbit fought the Tar-Baby, the more entangled he became. In contemporary usage, “tar baby” refers to any “sticky situation” that is only aggravated by additional contact. The only way to solve such a situation is by separation.

Some technologies or technical approaches are tar-babies. Experience teaches the senior engineer to avoid these technical approaches because he has witnessed the consequences. Most tar-babies look innocuous enough. A team faces a technical challenge and they decide to apply a particular approach. Once the team starts applying the approach, other problems start to crop up. The team applies fixes to the new problems, only to see the fixes spawn even more problems. Each supposed fix causes only more problems to arise. The team struggles and struggles until it is stuck.

It is very hard for a junior team to recognize the tar-baby while they are engaged day to day struggling with it. It is hard to conceive that the initial innocuous solution to problem is actually the root cause to all subsequent problems.

A simple example of a technology tar-baby is putting metadata in an identifier. One sees it all the time. The team decides to create a unique identifier for an object by combining metadata of the object. It might be a purchase order, for instance, so they combine the date, the customer ID and a character indicating the payment terms. Inevitably, new metadata needs to be added. Situations arise that are ambiguous to the metadata. The metadata out grows the length of the identifier. It is one mess after another until over time it becomes unmanageable. The senior engineer knows: do not put metadata in the identifier; it is a tar-baby.

I keep my eye out for tar-babies within the client companies that I work with. As I learned from Uncle Remus, the only solution is separation. You have to nip it in the bud. You have to cut the Gordian knot. But there I go with the metaphors again.

Very large companies have very large software projects. It is not uncommon to find projects with hundreds of developers with schedules lasting years. Such projects cost hundreds of millions of dollars. Sometimes the projects go wrong. The companies put more people on the project, meaning more money. The deadline slips, the project is extended more months, which means more millions. In some cases, the company deems the project a lost and pulls the plug. The technology investment is a complete loss. We are talking about $100 million, $250 million, sometimes $500 million spent with no result.

Rule of thumb is $1 million for every 8 people per year. A project with 40 developers will cost $5 million per year. A project with 200 people lasting four years will cost $100 million.

Large companies should have very large project insurance. They should pay some premium in order to insure that at the end of the project there is something that can be delivered. The definition of very large project will differ between companies. I would consider any project with 100 people and longer than one year a very large software project.

For every large project, set up a competing team with 5 to 10 percent of the resources. If the main project has 100 people, then the competing team would have 5 to 10 people. The competing smaller team has the same business objective. However, the smaller team operates outside of the rules of the large company. They have no bureaucracy. They do not need standard approval processes. They operate with complete freedom. The smaller team does not have to use the same technology or techniques of the main project. They need only solve the same problem.

The two teams should work in isolation. The members of the large project should not know that the smaller project exists. The small project should have access to all requirements generated by the large project.

You must never, never let the large team steal resources from the small team. However, you may want to let some team members leave the large project for the small one. Very skilled software developers are creative people, and creative people will become very frustrated with the bureaucracy of a large project. The very skilled developers can always find work. If and when they become frustrated, you have a choice: either watch them leave for another company or move them to the small team. In the small team they will regain their excitement and they will have all the knowledge of the project objects. It may seem that the advantage is in favor of the small team. Remember, they are your insurance.

The small team must be a strategic asset. The team must have a separate reporting chain right up to the CIO, or CEO or even chairman. If the small team has a common manager anywhere lower on the chain, then you can be guaranteed that they will be shut down. The managers will covet the resources of the small team. They will see the small team as only a threat, not a strategic asset.

At the end of the project, you must be prepared to throw one of the two projects completely away. This concept is probably the most difficult to accept in very large project insurance. Executives will feel compelled to pull something out of the large project and merge it with the small one. Any attempt to merge the two projects will fail. This is insurance; there is no half way. If the house does not catch fire, you do not get your fire insurance money back. If the house does catch fire, you get a new house; the old house is gone. The same is true with very large project insurance. One or the other project will deliver; there is no half way.

You are not wasting your money by having a competing smaller team. Consider a project with 200 developers over four years. The main project budget is $100 million. The small team would be 16 developers over three years, which is $6 million. The large project burns more than $2 million per month. If it slips three months, it has burned more than the cost of the insurance.

Apparently PBS has made documentary entitled “Pioneers of Television.” There were multiple articles about it in the local paper. I only just found out about it because I only read the headlines of the local paper while I am wadding them up to make a fire. (It is quite cold today.)

The documentary is about the actors. PBS calls them pioneers, as if they did something brave and new, as if they risked something. Our forefathers were pioneers. They left the comforts of civilization and went into the wilderness to make something new. They faced the dangers of starving, freezing to death and slaughter by savages. They built an empire of wealth from bare land.

There certainly were pioneers in television in the 1950s, but it was not the actors. The actors did the same thing in the television studio as they did on stage. The actors did what actors have done for 3,000 years. And what did the actors risk?

The pioneers were the men who invented television, who built the television manufacturing plants, who built the television broadcasting companies, who built the new business models, who invented the new techniques in advertising. These men risked their fortunes and made something new. Does PBS talk about these men? It is as if they did not exist.

It was seven score and four years ago today that Abraham Lincoln spoke these words.

Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.

Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate — we can not consecrate — we can not hallow — this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us — that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion — that we here highly resolve that these dead shall not have died in vain — that this nation, under God, shall have a new birth of freedom — and that government of the people, by the people, for the people, shall not perish from the earth.

Abraham Lincoln, 19 November 1863

Seven score and four is the only perfect square in the Fibonacci series.