Keep Track of Every Change

Every change has the potential to cause problems. Three common problems are:

1. The change did not fix the problem for which it was intended.
2. The change fixed the problem but caused others.
3. At a future date, the change is noticed and nobody can figure out why it was made or by whom.

In all three cases the prevention is to track every change. Tracking entails recording:

• The original request for change. This might be a customer's request for a new feature, a customer's complaint about a malfunction, a developer's detection of a problem, or a developer's desire to add a new feature.
• The approval process used to approve the change (who, when, why, in what release).
• The changes to all intermediate products (who, what, when).
• Appropriate cross-references among the change request, change approval, and changes themselves.

Such an audit trail enables you to easily back out, redo, and/or understand changes.

Reference:

Bersoff, E., Henderson, and Siegel, Software Configuration Management, Englewood Cliffs, NJ: Prentice Hall, 1980.

Control Baselines

It is the responsibility of software configuration management (SCM) to hold the agreed-upon specifications and regulate changes to them. You might not have a board in charge of SCM. I once worked as a technical product manager (TPM) and controlled the backlog for several teams. Regardless of the name, there is someone or a group that sets priorities for tasks yet to be completed.

While repairing or enhancing a software component, a software engineer will occasionally discover something else that can be changed, perhaps to fix a yet unreported bug or to add some quick new feature. This kind of uncontrolled (and untracked) change is intolerable. SCM should avoid incorporating such changes into the new baseline. The correct procedure is for the software engineer to make a change request (CR). This CR is then processed along with the others from development, marketing, testing, and the customers by a configuration control board, which prioritizes and schedules the change requests. Only then can the engineer be allowed to make the change and only then can the SCM accept the change.

Configuration control board is a bit of an old, formal name. I think most companies these days just use the representatives of the stakeholders - product managers, engineering directors, and architects.

So, this practice is immensely frustrating to the go-getter developers who see problems and want to fix them. But it is immensely practical in the sense that one man's bug is another man's expected functionality and changing things breaks expectations which leads to upset customers.

Reference:

Bersoff, E., Henderson, V., and Siegel, S., Software Configuration Management, Englewood Cliffs, NJ: Prentice Hall, 1980.

Independence Hall

Where America started...

Construction on the Pennsylvania State House,
now called Independence Hall, began in 1732
and was completed 21 years later in 1753.

Katy and I had the opportunity to visit Philadelphia, PA in April, 2017.

Located in Philadelphia's Center City, the area between Fifth and Sixth streets, and between Market and Chestnut, is home to the spirit of US history. Independence National Historic Park covers an area of 45-acres with approximately twenty buildings. Including what was once called the Pennsylvania State House which we now call Independence Hall. The Declaration of Independence was planned, discussed, and signed here.

Independence Hall Tower

The stately two-story redbrick building has a steeple with a clock in it. It used to house the 2,080-pound Liberty Bell which was rung on July 8, 1776, to announce the first public reading of the Declaration of Independence.  

"Proclaim Liberty Throughout All the
Land Unto All the Inhabitants thereof"

The Liberty Bell has its own home on the park grounds with a nice view of Independence Hall behind it.

Rotate People Through Product Assurance

 

In many organizations, people are moved into product assurance teams as a first assignment or after they have demonstrated poor performance at engineering software. Product assurance, however, requires the same level of engineering quality and discipline as designing and coding. As an alternative, rotate the best engineering talent through the product assurance team. A good guideline might be that every excellent engineer spends six months in product assurance organization every two or three years. The expectation of all such engineers is that they will make significant improvements to product assurance during their "visit." Such a policy must clearly state that the job rotation is a reward for excellent performance.

Reference:

Mendis, K., "Personnel Requirements to Make Software Quality Assurance Work," in Handbook of Software Quality Assurance, New York: Van Nostrand Reinhold, 1987.

The Sieve of Eratosthenes

Eratosthenes

Tonight I have been thinking about applications of the principle of inclusion-exclusion. The gist of it is how to determine how many elements are in the union of two finite sets. Ideally, you want to determine that number without examining every element. That is done by figuring out which elements need to be examined (the inclusion part) and which elements can be ignored (the exclusion part).

A wonderful example of applying the principle of inclusion-exclusion is "The Sieve of Eratosthenes" which is used to find all primes not exceeding a specified positive integer. At this point you might be thinking this is just an application of divide-and-conquer, and I agree. Simple concepts can be very powerful.

Consider that Eratosthenes lived between 276 and 194 B.C.E. He was born in Cyrene, a Greek colony west of Egypt. Eratosthenes tutored the son of King Ptolemy II and was the chief librarian at the famous library at Alexandria. His amazing feats of intellect includes measuring the size of the Earth. Carl Sagan mentions Eratosthenes in the 1980 mini series, Cosmos. He explains how Eratosthenes measured the Earth and it is amazing to think that with our modern tools a family can use these same methods to not only repeat the experiment but to prove that the Earth is [mostly] round as well.

Establish Software Management Procedures Early

 Effective software management is not just having a tool that records who made what change to the code or documentation. It is also the thoughtful creation of naming conventions, policies, and procedures to ensure that all relevant parties are involved in changes to the software. It means that:

• Everyone knows how to report a problem.
• Everyone knows how to request a new requirement.
• All stakeholders are informed of suggested changes and their opinions are solicited.
• Change requests are prioritized and scheduled.
• Versioning is figured out.

These things used to be recorded in a document called the software configuration management plan (SCMP). It would be written early in a project and get approved around the same time as the software requirements specification (SRS) is approved. These days it seems that no one makes these plans. Instead expecting their tools to tell them what to do when they start a project which results in some lopsided projects. For example, most teams I know report problems using JIRA internally. Some provide JIRA accounts to their users to report problems externally but few combine the two which results in a skewed view of product. A developer view vs a user view.

I could give more examples but that would be getting away from the point:

At the start of each software project, round up the stakeholders and have them agree to how each of the above bullet points will be handled. Make special effort to ensure that there are answers for internal vs external and a way to blend the two views.

Reference:

Bersoff, E., Henderson, V., and Siegel, S., Software Configuration Management, Englewood Cliffs, NJ: Prentice Hall, 1980.

Product Assurance Is Not a Luxury

 

Product assurance includes:

1. software configuration management
2. software quality assurance
3. verification and validation
4. testing

Of the four, the one whose necessity is most often acknowledged, and under-budgeted, is testing. The other three are quite often dismissed as luxuries, as aspects of only large or expensive projects. The checks and balances these disciplines provide result in a significantly higher probability of producing a product that satisfies customer expectations and that is completed closer to schedule and cost goals. The key is to tailor the product assurance disciplines to the project in size, form, and content.

Reference:

Siegel, S., "Why We Need Checks and Balances to Assure Quality," Quality Time Column, IEEE Software, January 1992.

Do a Project Postmortem

At the end of every project, give all the key project members a three or four day assignment to analyze every problem that occurred during the project. For example, "We were ten days late starting integration testing. We should have told the customer." Or, "We started designing and coding before the requirements were complete." Or, "the team was already exhausted from working long hours when the CEO demotivated everyone by announcing there would be 'no raises'."

In general, the idea is to document, analyze, and learn from all the things that went wrong. Also, record what you believe could be done differently in the future to prevent it. Future projects will be improved by these project postmortems. If possible new or promoted employees should attend one or more project postmortems before becoming key members of a project.

Those who do not remember the past are condemned to relive it.

 - George Santayana, 1908

The Thought That Disaster Is Impossible Often Leads To Disaster

Gerald Weinberg's "Titanic Effect" principle is that believing that disaster is impossible often leads to disaster. You must never become so smug that you think everything is under control and will remain that way. Overconfidence is the primary cause of many disasters. It is the mountain climber who says, "It's just a small climb; I don't need a belay," or the hiker who says, "It's just a short hike; I don't need water," who gets into trouble. Reduce risk to your projects by analyzing all your potential disasters up front, develop contingency plans for them in advance, and continually reassess new risks. This principle emphasizes the need to expect these risks to become real. Your biggest management disasters will occur when you think they won't.

Perhaps if Weinberg had been writing Quality Software Management in 2020, he would have called it the "Covid-19 Effect." No matter what it is called you'll still face a very big problem. It takes costly time and effort analyze the risks and make contingency plans. Most projects will be lucky and won't face disaster and some will but they contingency plans will work and make the problems seem smaller than they actually were. It won't take long and someone, probably your company's CFO, will say, "Do we really have to do all this expensive analysis and planning?" This is the disaster that will sink many future projects if you don't plan for it in advance by documenting the problems that such planning avoids and estimating the costs had contingency plans had not been in place. Furthermore, you must make disaster prevention and recovery a company culture value that everyone believes in and ensures it's success.

Reference:

Weinberg, G., Quality Software Management, Vol. 1: Systems Thinking, New York: Dorest House, 1992.

Manage by Variance

 

It is difficult, if not impossible, to manage a project without a detailed plan. Once you have a plan, update it as necessary. Now that you have an up-to-date plan, your responsibility is to manage the project according to that plan. As you report your progress, report only the discrepancies between the plan and the actuals. While the project is underway, a progress report should be, "Everything is as stated in the plan except ...." This way attention and resources can be applied to the problem areas.