The Chinese Wall

Reading about the Chinese Wall. Found this description;

In business, a Chinese wall is an information barrier implemented within a firm to separate and isolate persons who make investment decisions from persons who are privy to undisclosed material information which may influence those decisions. This is a way of avoiding conflict of interest problems. In general, all firms are required to develop, implement, and enforce reasonable policies and procedures to safeguard insider information and to ensure that no improper trading occurs. Although specific procedures are not mandated, adopted practices must be formalized in writing and be appropriate and sufficient. Procedures should address the following areas: education of employees, containment of inside information, restriction of transactions, and trading surveillance.”

So it’s a barrier, a conceptual notion, that separates two or more groups, as a means of restricting the flow of information. Okay, you want a Chinese Wall to avoid conflict of interest. Got that.

Just wondering why we have so many Chinese Walls in the world of software development? (i.e. the project team, the contractor, the testing team, the maintenance team etc. )

Why on earth would delivering great software to end-users benefit from huge Chinese Walls?

A small sanity check;

Our respected customer needs a very complex system. One he will value highly. We have never build a system like this before. Let’s make sure the people involved see each other (a) as much as possible, or (b) not at all.

Advertisements

Get me an update Confucius

Change. Popular word.

Confucius mentioned that only the wisest and stupidest of men never change. The wise folks know what they are doing, they are in full control, and they know what’s ahead. The stupid folks, well they are incompetent, clueless, ignorant, no idea the trouble they are heading for. So we have wise and stupid men…..how to spot the difference?

No wonder change is difficult.

A little bit of math never hurts

There is nothing wrong with making decision based on your intuition. But it never hurts to do a little bit of math. I find the following 4 examples very useful;

Example 1: The Communication Explosion
Fred Brooks (Man Mythical Month) is famous for his law “adding manpower to a late software project makes it later“. The reason for this is the added burden of communication which leads to a productivity decrease. This is made up of 2 parts; training and communication between team members. Brooks gives away a simple formula to calculate the number of potential interfaces: x = n(n-1)/2.

So if you have If you have n members in your team, there are x interfaces across which there may be communication. Are you sure you want N+1?

Example 2: The Calculated Risk
You have a list with 15 risks (n), each one has a low probability of hitting you; say 10% (p). The chance (c) that at least one of them will hit you is nearly 80%. That is, one minus the 15th power of 0.90. That’s worth talking about during a project meeting. In a formula: c = 1-(1-p)^n

That’s worth talking about.

Example 3: RISKOLOGY 
Tom deMarco and Timothy Lister wrote a great book called Waltzing with Bears, managing risk on software projects. In that book they introduce RISKOLOGY. RISKOLOGY is a free simulator which runs under Excel. The program can tell you how wide the window needs to be in order to cover all the uncontrollable risks of your project. It takes into account 5 core risks of any software project;

– Errors in original sizing
– Effect of employee turnover
– Requirements function growth
– Failure to reach consensus (Fatal)
– Effect of productivity variance

All it needs is 1 input: you most optimistic delivery date. This should be easy 🙂

Example 4: The Fault Feedback Ratio
The Fault Feedback Ratio (FFR) – the % of fixes that actually feed another bug into the system. Jerry Weinberg (Perfect Software and Other Illusions about testing) writes; “The estimated FFR is 25%, with 1 bug introduced in every 4 bugs fixed, but in my experience this is rather low.

So if we have 4 weeks to deal with 60 bugs…..and we take into account that 1/4 of those fixes (15) and have to be fixed again…so we need another week to deal with 15 bugs and we still have 4 bugs which need to be fixed….hmm…this information will surely help future test planning.

Recently I read a great quote on math by S. Gudder;
The essence of mathematics is not to make simple things complicated, but to make complicated things simple.”