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.

Miraculous Productivity Increases

The technology industry is saturated with people who preach that this tool or that technique will reduce development cost. We all hear at business meetings and conferences about software managers claiming huge increases of 50 to 100 percent in productivity by applying tool x or language y or method z. Don't believe it! It is hype. Moderate increases in productivity of 3 to 5 percent are much more reasonable targets.

You should be happy with tools, languages, and methods that shave a few percentages off your cost or add a few percentages to your quality. However, cost reduction makes no sense without an understanding of its impact on customer and employee satisfaction. If you want to really move the needle then focus on your customers and employees.

I've blatantly used AnalyticsInHR's image because it so well addresses my point. I don't know anything about their business but it appears that they know somethings about business performance.

References:

DeMarco, T. and Lister, T., Peopleware, New York: Dorset House, 1987.

Chappell, B., 4-Day Workweek Boosted Workers' Productivity By 40%, Microsoft Japan Says, NPR, Nov 4, 2019.

What Version of Java Compiled This

I try to use the latest stable version of Java/JDK when I can. There are a lot of performance improvements in newer versions of Java. Newer versions of OpenJDK also allow usage of Java Flight Recorder (that's a big deal). So when I have to work with a new Java application I often start with a new version of Java and work my way down the list until everything works. This can be a painful experience. When I have less time I'll look up what version of Java was used to compile the application then use the same version to run it. Even if you do have free time this is a good idea because Java 8 and below is probably going to have problems running on Java 9 and beyond. A lot of core language classes changed.

You might be thinking, "Why is this?" That's a valid question. It comes down to poor testing. The people testing are using the same environment as the developers and don't see a problem. The class files provided by the JDK are available to the application to use. All required classes should have been bundled with the application, but if the issue isn't caught in testing then it doesn't happen.

Anyway, how to test this: if you have a JAR or WAR file unzip it. On Linux, you can just run the unzip command against the file: unzip example.jar. On Windows, if you have a third party application you can point it at the file. If you are using Windows' built-in zip handling then rename the file to end with a .zip.

Once the files are extracted navigate to a class file made by the provider of the application; something like, com/yoakum/oneZero/security/. On Linux run javap -verbose Example.class | grep "major" on Windows run javap -verbose Example.class | findstr "major". This will return a number which you'll match to the following table:

Class Major Version | Java Major Version
                 ...|...
                 15 | 59
                 14 | 58
                 13 | 57
                 12 | 56
                 11 | 55
                 10 | 54
                  9 | 53
                  8 | 52
                  7 | 51
                 ...|...

This isn't a problem unique to Java. Every programming language I've ever worked with has had this issue. Java shouldn't have this issue as badly as it does. And it wouldn't if businesses would put more effort into ensuring their applications were more fully packaged to remove risk of missing or conflicting versions of dependencies.