Meisten Manager und Entwickler bezeichnen Perl als eine gefährliche Programmiersprache, die der Source Code kompliziert und verwirrend macht. So werden für die Projekte "sichere" Sprachen gewählt, die mehr strickt und weniger flexibel sind. Selbstverständlich ist ein Kinderdreirad sicherer als einen Rennwagen, aber es gibt Aufgaben, für die der Zweite wesentlich besser passt. Perl ist schnell und flexibel. Man muss nur immer bewusst sein, dass Perl gefährlich ist. In diesem Vortrag werden die Strategien und Methoden vorgestellt, die während mehrjähriger Verwendung von Perl und anderen "gefährlichen" Sprachen gesammelt wurden und die in verschiedenen Projekten geholfen haben, Software schneller zu entwickeln, logische Fehler zu vermeiden, Bugs zu finden und mit unsicheren Kundendaten umzugehen.

1. GPW 2013
Konstruktive Paranoia
Vitaly Rudovich
Vit R
http://www.vit-r.com/Projects/ErrorLog/ConstructiveParanoia/

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?
Vit R, gpw2013, 2
Konstruktive Paranoia‎

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
Vit R, gpw2013, 3
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 4
Konstruktive Paranoia‎

5. Software Development as sculpting
● We pretend to sculpt in stone, although we are making
pottery. (or playing with plasticine)
● Clay vs. stone
Vit R, gpw2013, 5
Konstruktive Paranoia‎

6. Proof
● You have seen such software many times
Vit R, gpw2013, 6
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 7
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 8
Konstruktive Paranoia‎

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
Vit R, gpw2013, 9
Konstruktive Paranoia‎

10. Software project outcomes
● Source code
● Documentation
● Knowledge
● most valuable part
● most ignored part
● usually is not documented
Vit R, gpw2013, 10
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 11
Konstruktive Paranoia‎

12. Bugs vs. errors: Errors
● The process
● find
● correct
● learn
● This is boring
Vit R, gpw2013, 12
Konstruktive Paranoia‎

13. The error Sources
● User requirements
● Management decisions
● SW architecture
● SW design
● SW development
● Libraries
● User data
● User commands
● SW environment
● ...
Vit R, gpw2013, 13
Konstruktive Paranoia‎

14. Paranoia
● Anything can be wrong
● "Can be" or "is"?
● Welcome to the real world
Vit R, gpw2013, 14
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 15
Konstruktive Paranoia‎

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
Vit R, gpw2013, 16
Konstruktive Paranoia‎

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
Vit R, gpw2013, 17
Konstruktive Paranoia‎

18. The cost of errors
● Direct harm
● Indirect harm
● The error correction cost
● can be reduced
Vit R, gpw2013, 18
Konstruktive Paranoia‎

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
Vit R, gpw2013, 19
Konstruktive Paranoia‎

20. Error correction: highest cost
● Communication
● slow
● inaccurate, erroneous, incomplete
● harmful
● Analysis
● What?
● Why?
● What instead?
● The "heaviest" process is the context load.
Vit R, gpw2013, 20
Konstruktive Paranoia‎

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
Vit R, gpw2013, 21
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 22
Konstruktive Paranoia‎

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
Vit R, gpw2013, 23
Konstruktive Paranoia‎

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!
Vit R, gpw2013, 24
Konstruktive Paranoia‎

25. Custom diagnose module
● project specific output
● STDERR
● dialog
● socket
● log file
● CSV file
● ...
● project specific errors
Vit R, gpw2013, 25
Konstruktive Paranoia‎

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
Vit R, gpw2013, 26
Konstruktive Paranoia‎

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
Vit R, gpw2013, 27
Konstruktive Paranoia‎

28. Discover errors as soon as possible
● Test your assumptions
● Test your algorithms
● Test before you move forward
● Prove each step
● die "OK";
Vit R, gpw2013, 28
Konstruktive Paranoia‎

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.
Vit R, gpw2013, 29
Konstruktive Paranoia‎

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
Vit R, gpw2013, 30
Konstruktive Paranoia‎

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
Vit R, gpw2013, 31
Konstruktive Paranoia‎

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
Vit R, gpw2013, 32
Konstruktive Paranoia‎

33. Talk to user: Prevent unnecessary
communication
● Make your error descriptions user friendly
● What is wrong?
● Who is responsible?
● How to correct?
Vit R, gpw2013, 33
Konstruktive Paranoia‎

34. Project page
New versions and additional information will be available on
http://www.vit-r.com/Projects/ErrorLog/ConstructiveParanoia/
Vit R, gpw2013, 34
Konstruktive Paranoia‎