gpw 2013, konstruktive paranoia, 2013-03-15

GPW 2013

Konstruktive Paranoia

Vitaly Rudovich

Vit R

http://www.vit-r.com/Projects/ErrorLog/ConstructiveParanoia/

Vit R, gpw2013, Konstruktive Paranoia ‎

2

Background

● 20 years in IT: SW Dev , QA, RE, PM● C, Fortran, Java, Prolog, Tcl/Tk...● C++ SIL-4

● Safety Integrity Level - 4● Probability of Failure per Hour 0.00000001

● Shlaer-Mellor aka. xtUML● fair model-driven development, model check, model test● 100% code generation from model

● DOORS / DXL● What is the worst programming language you ever

worked with?


3

Why Perl?

● Typical tasks of a consultant● This piece of ... code does not work.● We have some data. What does this data mean?● We have a problem.

● Perl● CPAN

– Perl is CPAN● available and permitted

– Most big firms have some Perl version in their archives.● fast● highly plastic


4

How about good parts?

● A dialog with a customer:– This is a nice solution with recursion.– What?– OK. How about a "foreach" cycle?

● This presentation describes how to cut the Perl wings off but keep flying.


5

Software Development as sculpting

● We pretend to sculpt in stone, although we are making pottery. (or playing with plasticine)

● Clay vs. stone


6

Proof

● You have seen such software many times


7

The Legend of The Right Process● We pretend we build pyramids.● Waterfall, spiral, scrum, XP...

are similar: Our product can only grow. Differences are only in the ways of growth.

● We pretend we cannot throw anything away. We do not reduce waste but deny it.


8

The real life: How to save money, time and quality

● Stop, find the errors and redesign.● Stop, find the errors and develop new version form

scratch.● Stop, find the errors, recalculate budget, estimate

profit and declare a failure.


9

The real life: How to waste money and time and loose your hope

● Dangerous sentences– Anything we did is an investment.– We are good, but something is probably not optimal.– If we find and kill all the bugs, we succeed.

● Zombie– Our project is 90% ready.– How long are you in this state?– Third year


10

Software project outcomes

● Source code● Documentation● Knowledge

● most valuable part● most ignored part● usually is not documented


11

Bugs vs. errors: Bugs

● The process● find, catch, discover, remove, find the bugs created by

bug removal, repeat● This is a MMORPG

● Developers create the features.● Testers find the bugs.● Developers reclassify bugs into features.● Managers confirm the bugs being bugs and assign the

bug removing tasks.● Developers claim they have no time; they create new

features.


12

Bugs vs. errors: Errors

● The process● find● correct● learn

● This is boring


13

The error Sources

● User requirements● Management decisions● SW architecture● SW design● SW development● Libraries● User data● User commands● SW environment● ...


14

Paranoia

● Anything can be wrong● "Can be" or "is"?● Welcome to the real world


15

Prevention

● If you X, your code will be better.● paranoia mode on:

● Why?● How do you measure the effects of X?● Does X have unintended consequences?● Is the cost of X less than the cost of the errors that it

prevents?● If you X, you feel better.


16

The silver bullets

● It is impossible to add quality.● Tests, QA, Processes, Methods...

● This is verification● You can verify against requirements

– Do we develop our product in a right way?● You cannot validate.

– Do we develop a right product?● "Industry proven" X

● Maybe it contains or generates errors● Maybe it is not applicable for your conditions● Your implementation may be not correct


17

Solution

● Measure and compare● Don't believe any statistics you don't make up yourself

● Do not repeat errors● Do not hide errors● Be prepared

● Do not hope you can create an error-free world● You can predict errors● You can reduce the cost of errors


18

The cost of errors

● Direct harm● Indirect harm● The error correction cost

● can be reduced


19

The error correction processes

● error detection● communication● search for the error sources● analysis of the error conditions● analysis of correct behavior

● How it must be?● development● proof of the error correction


20

Error correction: highest cost

● Communication● slow● inaccurate, erroneous, incomplete● harmful

● Analysis● What? ● Why?● What instead?

● The "heaviest" process is the context load.


21

Errors: highest cost

● Errors in requirements● Test with the real data.● Test in the real conditions.

● Old errors are more expensive● Reduce the errors lifespan


22

Do not hide errors

● <program state is correct> or die()● <data state is known> or die()● Do not believe in logs.● All unknown errors must stop execution.● Report errors on the appropriate level.


23

Comments (1)

● A message in the bottle● Anything that is not in the source code will be lost,

forgotten or ignored● Do not hide

● your errors● alternatives● your assumptions● your knowledge


24

Comments (2)

● If possible, comment out but not delete● Remove something only if it is necessary to remove● If you have something to say, say it

● The most valuable comments by search for problems– !!!– ???– OMG!– F.CK!


25

Custom diagnose module

● project specific output● STDERR● dialog● socket● log file● CSV file● ...

● project specific errors


26

Most frequent functions

● set_debug_mode(); # 0 or 1● DBG(), LIFESIGN()● ASSERT(), ERROR(), WARN()

● send high level information● why is the state or the data not correct● what assumption is not correct● describe what you know about the error conditions

● DUMP_HASH_AS_JSON()● Json file 2 MB● Manuell verification● Perl script to check state


27

Negative filters

● Preconditions● check: data, internal state, assumptions

● Postconditions● check: end state, results, errors

● Invariants● detect: infinite cycles, incorrect states

● Anything that is not proved to be correct is suspicious


28

Discover errors as soon as possible

● Test your assumptions● Test your algorithms● Test before you move forward● Prove each step● die "OK";


29

Bulletproof against maintenance

● Harvard management methodology wizards claim that the human resources quality is not important, if you have the right management process.

● Be prepared.

● Your software must be recoverable after all types of maintenance.


30

Do not believe in interfaces

● Software produce errors● Users produce errors● Errors can be creative

● Number of employers– "-3" (correction value for another table)– "TBD" (manual user correction )

● Date– "2013-02-31" (the last Sunday of February. User calculations

in Excel)● User Name

– "1@23F32" (XML export was wrong)● Crosscheck input values if possible


31

Talk to user

● User is always right (but frequently dumb)● Developer:

– The output is garbage: each third record is wrong.● User:

– Why garbage? Two thirds of values are correct.● Users ignore errors

● whenever they can


32

Talk to user: Report to the appropriate level

● Stop execution● Block the dialogs● Present the errors in a simple way● Deliver the error messages with results● Shout


33

Talk to user: Prevent unnecessary communication

● Make your error descriptions user friendly● What is wrong?● Who is responsible?● How to correct?


34

Project page

New versions and additional information will be available on



gpw 2013, konstruktive paranoia, 2013-03-15

Technology