Why people in software development (including project managers) tend to lie

Service public - Why the upper class never ever get the truth

The upper class everywhere, in politics, business, etc. have special conditions and they live in a separate world for themselves. With priority trouble shooting hotlines, where someone picks up the phone almost immediately while normal people have to wait for ever (record is 1.5 till 2.0 hours... multiple times, with different people, a company in Switzerland... again, and again.)

So, they never ever face the real world troubles normal people get. Service public is an other term for "Service the upper class - the public will pay for it".

The upper class never ever get the truth if they live in a separate staged world - made for them alone. They live like in a Trueman show, where everything is faked and staged to look as perfect and real as possible. The want everything FAST - and they end up getting crap. This is what we where told communism production system was... should be... should have been... in there cold war vision... A history teacher of mine told us this (in the communist system) all will and up in quality disaster, producing only single weak thin nails for example - useful for nothing.

I think we in the west are not far away from that idea... ? Target? Or what? The faster the better? Quality does not matter. This is the new measurement for killing people at the workforce in the west... to move the work places somewhere else, where they "work faster"... but not better... it getting worse.

And at the end we are in a "because of communistic system" workplace as they hold us... funny. Where everybody lie to each other and say to each other how "good" you are...

But it should work!

This one is a good one. I like it, because it has to to with people AND machines. Technical people - and others(!) - tend to believe in electronic devices. The should work - should. But sometimes they don't. For example if they don't have power. This was a problem for a company who has an iPad up and running in there store window. The iPad did display some ads over the internet, but ironically it stops working the next day.

Why? That's the question!

It took several days (I think this company and with the help of many other people) - even months, to just accept a simple problem: Power problem. Before that they did different technical testing, change source code, speculated this and that... nothing worked. For weeks, months, maybe years... who knows...

I came in an I did a test. The log showed that about 03:32 in the morning the machine stops working. So what? The iPad battery did not last for a night to the next morning when the main power switches on again. It turns out that the main power supply was turned off during the night.

Solution

The solution was simply to not turn off the main power supply over night.

So some people like problems that are not clear and where to solution is hidden somehow - just to talk a lot of nonsense and wasting your time.

What I found in Software so far

„Whatever can go wrong will go wrong.“ - Murphy's Law

Read the F* (final) Manual !

Really? But what if the documentation is wrong? It can end in a disaster.

This really happens to a company, where an external MySQL database expert did something to a database which was absolutely correct according to the documentation - according to the documentation, but it failed. Why? Because the specs where wrong. They where wrong for English and an other language.

So the manual was not up-to-date and / or wrong for a specific version of the database system MySQL.

Model View Controller (MVC) used incorrectly

Use Model View Controller communicating each others back and forth if you want a super not maintainable mono block of software that must be written from scratch every minor release.

The right thing is to have the Controller in between which manages the communication between the View and the Model.

Never ever let the view communicate to the Model directly. If you do this, you will end up in a not maintainable peace of software.

The problem is that we have more and more coders not programmers anymore. Coders just type in something. Used by managers and project leaders who think programming is just "type in some strange letters and numbers in sequence into a computer". That's it. But it's not.

The use of global variables ( g_ )

So you change a value of my_super_number to something in a function and find out later that something terrible happened somewhere. After a research you find out that you changed a global variable! But you never knew that.

My advice is to mark global variables. For example with a "g_my_super_number" as global. So you know what you are using global variables.

It's also fun to change the name of super global variables which are use in many places. A project women did that and did not inform anyone... the result was that nothing worked again. She just changed that because it's fun to see for her employees looking stupid because the code does not work anymore. Project managers should not touch any code just to show the world that they are able to change anything and check in a file.

Some companies also use capital letters for global variables. But I prefer to have a prefix. So then you can enter g_ and get a full list of all global variables. Very nice.

Use of variables used within or for the view ( UI_ )

If you have variables used or close to the view, just mark it so that you and others can find it!

Prefix it with "UI_" or "ui_" as User Interface (UI).

Use:

UI_speed_km = "99.3 km/h";

Not:

speed_km = "99.3 km/h";

Units factor wrong calculated

If 1 is 1 kilo byte is 1 mega byte. The user is maybe not able to upload data to a server because the file size limit is calculated not correctly.

A function changes an input value

This is a big one. There is a rule: Never ever change any input value at all. Else mad things can happens. You can get strange output values.

My advice is to mark any input variable with a prefix like so:

Note: in_xy stands for input xy variable. So you can see and you know if you use an input variable.

int myFunc (int in_x, int in_y)
{
    int ret = in_x * in_y;
    return(ret)
}

Wrong date format interpretation

A person (from Austria) swap month and day position within date formats - not once, often... like so:

YYYY-MM-DD vs. YYYY-DD-MM

So, a statistic based on these numbers become totally useless - for customers as for internal decisions. However, these numbers are used over months if not years - until I found this "bug"... and telling the truth that the numbers are totally useless. On some browsers uses by customers the numbers get wrong - on some others not.

Codes that blocks the user interface

Result: Strange error messages and wired up screens. And it's not always the same. Depends on the environment the customer uses. Different OS, different Web Browser, etc. For example the user will see a browser that is crashed, and/or running and waits for ever, etc. with different user interface elements on it or a blank screen, etc.

Else statement missing for IF

float water_level = 10.1
if ( water_level >= 1.0 ) {
    // alarm for water level reached 1 meter
}
if ( water_level >= 2.0 ) {
    // alarm for water level reached 2 meters
}

float water_level = 10.1
if ( water_level >= 1.0 ) {
    // alarm for water level reached 1 meter
} else if ( water_level >= 2.0 ) {
    // alarm for water level reached 2 meters
}

Equal is not compare

So, this a problem for all C like programming languages. Other more secure languages use different notation.

'=' versus '=='

void main()
{
    int door_open_flag = 0;
    if ( door_open_flag = 1 ) {
        // open the save
        printf("OPEN the save.\n");
    }
}

This safe is not safety. It will open the door every time. At least if you are programming in C/C++, PHP, etc. Some compilers will warn you, some not.

The cost of one bug

In general: The longer a bug is not found - the more it costs to fix it afterwards.

Software bugs can cause:

* Side-Effects

* Speculation

* Customer confusion

* Height costs

As earlier you find a bug, the better. If a bug is found late, the more it costs.

There seems to be a factor of 10 of every step:

Step: Idea --> x 10 --> Step: Development --> x 10 --> Step: Realization, Programming --> x 10 --> Step: Testing --> x 10 -->Step: Distribution and Customer installation locally

Every step a bug pass will cost you factor 10.

So a simple bug not found in all steps can cost a factor of 10 ^ 4 = 10.000.