Archive for February, 2016

Life of A Programmer — Session 5.1 — You are a Quality Assurance Manager

February 17, 2016

You are a software engineer. You work for a great software
development company.

Would you believe it if I told you that you are a Quality
Assurance Manager.

You don’t believe it! I don’t blame you.

Q.A. is a management activity. It is taught in Business
Administration.

You have a college degree in Software Engineering, not
Business Administration.

MORE IN THE NEXT MESSAGE

The Purpose of My Blog

February 17, 2016

The original purpose of my blog was to provide me an easy
means of reporting my activity on my personally funded
research and development activities on error-free software
development methods.

I subsequently expanded the purpose of my blog to encourage
others to improve their skills by conducting their own
regular experimental process.

I became a software engineer in 1966 due to an experiment
that I had performed. I have never taken a course in
Software Engineering. You are encouraged to take a similar
path. If my tools can be of any benefit, they can be
downloaded free-of-charge from my web-site, http://www.whatifwe.com

Limitation to My Response to Your Comments

February 17, 2016

Every day I receive between 50 and 100 comments. Many of these comments request information or advise from me.

I appreciate the honour of your request for information.

Unfortunately, there is only one of me managing and writing the blog. Consequently, I simply do not have enough time to reply to each of your questions.

There are many comments that ask the same question. In these situations where I have the information, I will provide my knowledge in a post, time permitting.

I will respond to any comment made by a person who is experimenting with my software development tools.

Thank You

Robert Adams

Monte-Carlo Test Method

February 17, 2016

A Number of years ago, I had a contract to build a hardware
control sub-system software product.

This hardware control sub-system was designed to control
legacy hardware shipped back from the Middle East.

This legacy hardware appeared to have not been well-maintained;
it needed a lot of service.

I was afraid that I might break this hardware when I tested my
hardware control sub-system software product.

I developed a Monte-Carlo Simulator/Stimulator Test System to
validate my hardware control sub-system product.

The Monte-Carlo technology is based on a pseudo-random generator.
It was originally used in the development of nuclear weapons.

The random nature of my Monte-Carlo Test System enabled me to
rapidly and thoroughly test the hardware control sub-system, both
from a user and hardware point-of-view.

The use of a Monte-Carlo Simulator/Stimulator Test System
enabled me to deliver an error-free software product.

WHATIFWE used Monte-Carlo software test methods for all software.
Would we get better products?

Can Programming Be Strictly Portable Relative To Language?

February 17, 2016

The activity associated with development of strictly portable methods
of software development will be presented here. Included in this
Portability effort will be Windows based C, C++, C#, and Visual Basic;
and Linux based C and C++.

TUESDAY: 2016/02/16

STATUS: A header comment command has been successfully added to common
program output library.

DETAIL: Header Comments are required for each of the files being
produced. These comments contain pertanent legal data such as a
copyright statement.

NEXT TASK: The task will be to continue developing the C++ output
library.

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

February 14, 2016

PRINCIPLE 4: ACCEPT NO VERBAL ORDERS

In 1961, Lockheed had a standard document called an ANVO. This meant
“ACCEPT NO VERBAL ORDERS”.

This is a very important and valuable concept. Spoken commands are
more likely to be misinterpreted.

Your boss might only make verbal commands. In this case, give him
your interpretation in writing.

When an ANVO has been issued, make sure that its required effort
is properly documented in your log.

MORE IN THE NEXT MESSAGE

How Do I Make My Blog

February 14, 2016

There have been quite a few requests for advice on
“how to build a blog”. As you can see from my blog, I have
prepared a lot of posts. Therefore, I have learned how
to do it efficiently.

There are some simple rules for making your blog easy
to prepare.

1. Have a well-defined purpose for your blog. For myself,
my blog was a means of publicly documenting my research and
development efforts.

2. Use a standard format. Then you can build a template
which will greatly facilitate its preparation. I use
my development software to write the blog.

3. Don’t get carried away with an artistic design. I use
the free WordPress. I do not use any pictures; all I
have to do is paste in the text. Above all, I did not
have to develop the blog web-site.

Above all, recognize that every post you publish will be
in the public domain forever. I have been very careful
to put just enough information to identify and date my
efforts but not to give away any proprietary data.

Hope that this helps.

Robert Adams

My Problems With LinkedIn.

February 14, 2016

I need to alert everyone that I do not have a working LinkedIn system.

I have made several attempts at correcting the problems without success.

People trying to connect with me on LinkedIn will be unsuccessful, no
matter how much I want to connect with them.

The Role of the Media

February 14, 2016

Both the incompetent and the competent benefit from
media attention.

The competent leader requires community participation.
The media helps him to obtain the participants.

The incompetent needs 15 minutes of fame. The media
helps him to satisfy his greedy goals.

Unfortunately the entertainment associated with the
incompetent attracts a lot of media attention.

The competent pioneer finds new solutions to current
problems.

WHATIFWE were to provide the media attention needed
to develop hope from the new ideas of the competent
pioneers?

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

February 10, 2016

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