Gpw 2013, Konstruktive Paranoia, 2013-03-15


Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Gpw 2013, Konstruktive Paranoia, 2013-03-15

  1. 1. GPW 2013 Konstruktive Paranoia Vitaly Rudovich Vit R
  2. 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. 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. 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. 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. 6. Proof● You have seen such software many times Vit R, gpw2013, 6 Konstruktive Paranoia‎
  7. 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. 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. 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. 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. 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. 12. Bugs vs. errors: Errors● The process ● find ● correct ● learn● This is boring Vit R, gpw2013, 12 Konstruktive Paranoia‎
  13. 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. 14. Paranoia● Anything can be wrong● "Can be" or "is"?● Welcome to the real world Vit R, gpw2013, 14 Konstruktive Paranoia‎
  15. 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. 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. 17. Solution● Measure and compare ● Dont believe any statistics you dont 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. 18. The cost of errors● Direct harm● Indirect harm● The error correction cost ● can be reduced Vit R, gpw2013, 18 Konstruktive Paranoia‎
  19. 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. 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. 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. 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. 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. 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. 25. Custom diagnose module● project specific output ● STDERR ● dialog ● socket ● log file ● CSV file ● ...● project specific errors Vit R, gpw2013, 25 Konstruktive Paranoia‎
  26. 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. 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. 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. 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. 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. 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. 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. 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. 34. Project pageNew versions and additional information will be available on Vit R, gpw2013, 34 Konstruktive Paranoia‎