Archive for the ‘Life Of A Programmer’ Category

Life of A Programmer — Session 8.2 — Tools Help Make The Software Engineer

June 27, 2017

The Tool, if it is to be compliant of the principles of ISO-9001 must be capable of:

1.0 Developing a system of Standard Methods.

2.0 Exclusively using these Standard Methods in the development of product.

3.0 Testing all work-products from the Standard Methods all the way to the Product.

An experimental beta development system that satisfies these requirements is available on my web-site, http://www.whatifwe.com

I have developed both a Linux and Windows Open Source version.

They can be downloaded free-of-charge.

The download has a fairly decent manual.

THE END

Advertisements

Life of A Programmer — Session 8 — Tools Help Make The Software Engineer

June 19, 2017

With the right development program, you can develop Error
Free Software.

There are some historical examples of this truth.

In the early 1960’s, Fortran was a major computing languages.

The Fortran compiler had a never ending bug list.

PL/1, the next major language, was far more reliable.

I used it at Lockheed for over five years and never encountered
any errors.

PL/I was designed in strict compliance with the principles of
simple precedence.

MORE IN THE NEXT MESSAGE

Life of A Programmer — Session 7.5 — How Do I Become a Quality Assurance Software Engineer

June 6, 2017

RULE 4 — NEVER USE A PATCH TO SOLVE A PROBLEM.

Never patch the program!!!.

A patch is usually a last minute change which is not clearly
thought out.

The product delivery is usually close at hand.

Management is saying “All you have to do is …” (The most
dangerous phrase in the English Language).

The patch will probably violate RULE 1 (The strict use
of standard methods).

None-the-less, avoid the short-cut and you will more likely
find the solution to the problem.

MORE IN THE NEXT MESSAGE

Life of A Programmer — Session 7.4 — How Do I Become a Quality Assurance Software Engineer

May 29, 2017

RULE 3 — USE OLD, WELL-TESTED, OPERATING SYSTEM CAPABILITIES.

Relative to the operating system, use the old, well established
capabilities and minimize your interface.

Think of it in a similar manner as purchasing a new car.
If you purchase a radically new model, you will become an
unwilling member of the test team.

Similarly do not use a pipe if a file will do as well. Files
were developed long before the pipes.

An above all, do not use its multitasking capabilities unless
absolutely necessary. This capability can expose you to many
challenging problems.

MORE IN THE NEXT MESSAGE

Life of A Programmer — Session 4.4 — How can you become more skilled than your fellow employees.

May 23, 2017

PRINCIPLE 3: MAKE SMALL SELF-DOCUMENTING SOURCE FILES.

Each of your source code files should not be longer than
three or four pages.

Each source code file should have lots of descriptive
comments.

Each source code file should reference a section of
your plan.

Each variable name should be instantly identifiable.

Keep in mind that your source-code goal is to be able
to instantly relate to its design and use when you open
its file.

You might have to answer a question over the phone a year
after you complete the project.

MORE IN THE NEXT MESSAGE

Life of A Programmer — Session 7.3 — How Do I Become a Quality Assurance Software Engineer

May 16, 2017

RULE 2 — TEST ALL WORK PRODUCTS.

I was able to “look over NSA’s shoulder” when they were developing
SELINUX (Secure Linux Operating System”.

Their activity can be best described as “programming as usual”.

I asked them about their test plans. They said that they were not
going to test the system. It would be Common Criteria tested when
delivered.

This is not an adequate test plan. Testing all of the work-products
is the only way to thoroughly test the product.

Back in my hardware engineering days, we made test plans which
thoroughly tested each circuit board. Divide and conquer!

SELINUX will fall short of its intended goal. The bad-guys will
find the weak points.

MORE IN THE NEXT MESSAGE

Life of A Programmer — Session 7.2 — How Do I Become a Quality Assurance Software Engineer

May 9, 2017

RULE 1 — RIGOROUSLY USE STANDARD METHODS.

Prepare a minimum set of standard methods that you will use on all your programming effort. Keep them “simple, stupid”.

In the hardware world, the Quality Assurance Manager working with management purchase the set of Integrated Circuits needed to get the job done.

These standard methods are your “Integrated Circuits”.

MORE IN THE NEXT MESSAGE

PROGRESS REPORT

May 5, 2017

This purpose of this post is to publish single line status
reports on the projects performed during the week.

**************************************************************
**************************************************************

2017/04/26

RELATIVITY BOOK

The “Equation of Motion Rexamined” page presenting
discoveries following the Prague Conference has been
tentatively prepared.

**************************************************************

2017/05/03

RELATIVITY BOOK

The “Equation of Motion Rexamined” page has been modified to include
the Paris page. The Personal Evolution Section has now been prepared.

Life of A Programmer — Session 7 — How Do I Become a Quality Assurance Software Engineer

May 2, 2017

To become a Software Engineer with a Quality Assurance
capability, you must implement a basic philosophical change.

Software is not an art form; the computer is not the easel
where you can express your creative juices.

You will become an engineer responsible for providing tools
and services that will affect public safety.

You think not. I beg to disagree.

I was transferring $1000 between my savings and checking
accounts when the ATM went down. It took the bank half a
day to find my money.

You ask, what do I need to do in order to improve my quality
and be more indispensable to my employer.

RULE 1 — RIGOROUSLY USE STANDARD METHODS.

RULE 2 — TEST ALL WORK PRODUCTS.

RULE 3 — USE OLD, WELL-TESTED, OPERATING SYSTEM CAPABILITIES.

RULE 4 — NEVER USE A PATCH TO SOLVE A PROBLEM.

MORE IN THE NEXT MESSAGE

Life of A Programmer — Session 6.3 — What should a Quality Assurance Software Engineer Know.

April 25, 2017

SOFTWARE ERROR SOURCE 2: THE OPERATING SYSTEM.

The operating system is the silent partner in all software
development activities.

The operating system, also having been developed by human
beings, will also have errors.

Most of the errors will have already been discovered.

The ones that have not been discovered will, in general,
be difficult to fix.

You, as the user, will have no control over that repair
process.

Consequently, you may end up with a difficult task of
working around a system error that was discovered on your
watch.

MORE IN THE NEXT MESSAGE