Rickerism

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.

I was involved in the creation of an OSGi solution for the US Army for the Super Bowl XL security. It was an early implementation of SODA. It connected all the various nuclear, biological and chemical sensors that the US Army National Guard and US Department of Energy were using to detect hazardous materials. The location of each device and its reading was shared on the network. The location and status was plotted on a satellite image of downtown Detroit. The soldiers walking the beat saw the same information as the guys in the command shack.

Two events happened during that mission that highlighted the strength of OSGi.

The first happened the day before the Super Bowl. We had been testing for weeks, but on Saturday afternoon the committee tells us that we will not be allowed to use 802.11b or 802.11g bands for fear of interfering with their wireless ticketing devices. We scrambled to make the change. With the component structure of OSGi, it was very easy to change the software. The hard part was finding 802.11a routers in Detroit on a Saturday evening. We cleaned out every Best Buy in three counties.

The second event occurred the morning of the Super Bowl. We were in the tents around the stadium bringing the gear on line. One of the soldiers walked up and showed the palm top computer screen he was holding. “Why is it doing this?” he asked. He had found a bug.

“Shoot. I know what’s causing that,” exclaimed one of the senior developers. He went over to a laptop in the tent, pulled up the source code in Eclipse, made a few changes to the code and built a new version of the bundle. He then pulled up the system monitor and deployed the bundle out to all of the installations. The whole process took less than five minutes. In fact, the soldier was still standing there going through the screens. He muttered, “Oh, it’s working now,” and went on about his mission. Indeed it was working, and working on all of the other computers scattered across downtown Detroit.

When people ask me if OSGi is ready for enterprise applications, I immediately think back to that mission at Super Bowl XL. That was nearly two years ago.