vit_r (vit_r) wrote,
vit_r
vit_r

Constructive Paranoia (GPW 2013)

GPW_2013_KP_img_04_user

Доклад был прочитан на немецком, но весь текст на английском. Слайды есть, но здесь пусть будет просто деревом. Примеры с кодом будут когда-нибудь, когда будет на это время.

GPW 2013. Konstruktive Paranoia

  • Title
  • 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
      • eXecutable, Translatable UML
      • 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?
  • 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
  • How about its good parts?
    • A dialof 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.
  • Software Development as sculpting
      • SW development as sculpting. Version_2013-03-13_for_LJ
    • We pretend to sculpt in stone, although we are making pottery.
      • (or playing with plasticine)
    • Clay vs. stone
  • Proof
    • toilet teapot_from_yamauba_LJ_560637
    • You have seen such software many times
  • The Legend of The Right Process
    • GPW_2013_KP_img_03_IT_process_and_pyramids

      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.

  • 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.
    • 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
  • Software project outcomes
    • Source code
    • Documentation
    • Knowledge
      • most valuable part
      • most ignored part
      • usually is not documented
  • Bugs vs. errors
    • Bugs
      • The process
        • find
        • catch
        • discover
        • remove
        • find the bugs created by bug removal
      • 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.
    • Errors
      • The process
        • find
        • correct
        • learn
      • This is boring
  • The error Sources
    • User requirements
    • Management decisions
    • SW architecture
    • SW design
    • SW development
    • Libraries
    • User data
    • User commands
    • SW environment
  • Paranoia
    • Anything can be wrong.
    • "Can be" or "is"?
    • Welcome to the real world.
  • 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 errors that it prevents?
    • If you X, you feel better.
  • The silver bullets
    • It is impossible to add quality
    • It is impossible to buy 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
      • may contain errors
      • may produce errors
      • may be not applicable for your conditions
    • Your implementation may be not correct
  • 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
  • The cost of errors
    • Direct harm
    • Indirect harm
    • The error correction cost
      • can be reduced
  • The error correction processes
    • error detection
    • communication
    • search for the error sources
    • analysis of the error conditions
    • analysis of correct behavior
      • How must it be?
    • development
    • proof of error correction
  • Highest cost
    • Error correction
      • Communication
        • slow
        • inaccurate, erroneous, incomplete
        • harmful
      • Analysis
        • questions
          • What?
          • Why?
          • What instead?
      • The heaviest process is the context load
    • Errors
      • Errors in requirements
        • Test with the real data.
        • Test in the real conditions.
      • Old errors are more expensive
        • Reduce the errors lifespan.
  • 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.
  • 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
        • assumptions
        • your knowledge
    • 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!
  • Custom diagnose module
    • Why custom?
      • project specific output
        • STDERR
        • dialog
        • socket
        • file
        • CSV file
        • ...
      • project specific errors
    • Most frequent functions
      • set_debug_mode();
        • 0 or 1
      • DBG()
        • comment and uncomment
      • LIFESIGN()
      • ASSERT()
        • send high level information
          • Why is this not correct
          • What assumption or state is not correct
        • describe what you know about the error conditions
      • ERROR()
        • $diag->ASSERT(0,...)
      • DUMP_HASH_AS_JSON()
        • Json file 2 MB
        • Manual verification
        • Perl script to check state
  • Negative filters
    • Preconditions
      • check
        • data
        • internal state
        • assumptions
    • Postconditions
      • check
        • end state
        • results
        • errors
    • Invariants
      • detect
        • infinite cycle
        • incorrect state
    • Anything that is not proved to be correct is suspicious
  • Discover errors as soon as possible
    • Test your assumptions
    • Test your algorithms
    • Test before you move forward
    • Prove each step
    • die "OK";
  • 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"
          • 2013-03-03?
          • No
          • the last Sunday on February
          • user calculations in Excel
      • User Name
        • "1@23F32"
          • XML export was wrong
    • Crosscheck input values if possible
  • 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. GPW_2013_KP_img_04_user

      Your software must be recoverable after all types of maintenance.

  • Talk to user
    • Users and errors
      • 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
    • Report to the appropriate level
      • Stop execution
      • Block dialogs
      • Present errors in a simple way
      • Deliver error messages with results
      • Shout
    • Prevent unnecessary communication
      • Make your error descriptions user friendly
        • What is wrong?
        • Who is responsible?
        • How to correct?
Tags: agile, it, management, qa, quality, se
Subscribe
  • 11 comments
  • 11 comments

Comments for this post were locked by the author