Self Reliant Systems


Published on

The code we produce in IT typically have the knowledge "up front", meaning that when the problems arise in production the original programmers aren't around anymore. In this session I propose an approach where we build more "business knowledge" into the code itself and not just settle for simplistic checks like "is there space on the hard disk".

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

Self Reliant Systems

  1. 1. JavaSelf Reliant SystemsBjörn Granvik
  2. 2. Self Reliant SystemsIn Code, In Process, In MomentBjörn GranvikCTO, Jayway
  3. 3. Enclaimer§ The information in this presentation hasbeen painfully gathered through experience.§ Events and characters are purely based onreality. However, names of the innocent andthe guilty have been changed in order to benice.§ Programmers have been hurt during theseexperiments…
  4. 4. Toyoda and His loom30:1 - looms:personsStop the line!
  5. 5. Our Reality?MeProjectsTest serverTestsTest serverStagingserverProductionserverProductionserver 2Productionserver 3LoadBalancingJoeMr SmithSADUCRTESGKWStoptheline?
  6. 6. CodingAnything that changes the behavior of your"parameters"Admin console, tweaking the productionLoad balancers, pools, indexes, ……programming
  7. 7. The Problem
  8. 8. The GuildStuck in craftsman mode Almost all parts are "made to order"Impossible to replicate the systemImpossible to "know" the systemMonday morning – every morning, every dayIT medieval ages
  9. 9. Symptom: Whazzup?
  10. 10. Symptom: More Whazzup!
  11. 11. Symptom: Running?Q: How do you know if your system is working?Surf to your web site/application.Try something. Does it work?Check memory/processes/portsCheck log filesCheck GKW…now what? - Wake the programmer!
  12. 12. Symptom: Compile?BackupContinuous IntegrationContinuous Feature Creep…Q: Five years on, does your code compile?…now what?– Buy single malt, call the programmer!
  13. 13. Symptom: Change Spec?Search for keywords in codeCheck for unit tests…Q: Changed specification – what do you do?…now what? – Change and Pray.
  14. 14. Why not analysis/reports?Some are needed but...Word etc cannot be verifiedAlmost all are wrongWeve tried that…Exercise: Read any project document and see if itis correct.Conclusion: We cannot rely on them.
  15. 15. Why not tools?Only answers general questionsCatch 22The tooling industry Tool vs. product: 10x precision!We – the IT Industry 2xs …Yeah right!Exercise: Compile your colleagues project…Conclusion:We must build our precision/knowledgeinto our components!
  16. 16. Theory
  17. 17. The Line …in theoryAny feedback oriented system willeither adapt and succeed - or fail fast.
  18. 18. The Component …in theory
  19. 19. What to do …in theoryBuild it inFeed it backPay it forward
  20. 20. In CodeWord is Evil!“Coding" beyond developers machine is Evil.Put it all there into the componentSelf Testing Requirements Healing …Component should adapt
  21. 21. In ProcessNot in process  automatically forgottenAutomatic & repeatableFeedback Oriented
  22. 22. In MomentDo the job in the moment Where all knowledge is there All the developers are present programmers, testers, business analysts, etcCode like you will be gone after three iterations
  23. 23. Examples
  24. 24. NO!Example -1: Wheres that lib?Yes
  25. 25. Example 0: LoggingTrivial! But forgotten.Think "production and runtime", not justdevelopmentWhat to do: Use your favourite logging framework Log to correct level Info – important info and state changes Debug – well, just debug info Log appropriately per machine/situation/etc
  26. 26. Example 1: TestingTesting - from unit to acceptance level JUnit, TestNG DDSteps ...and many moreNew: Deploy the code with this ability Self test in productionUse Case PingUCC – Use Case Coverage
  27. 27. Example 2: Running?Make it easy to decide if your system is up andrunningNew: Is it installed properly? Is it up and running? Dead easy to spot a (non)working system! Easy to spot level of problem Less calls to second/third level of support
  28. 28. Example 2: Running!Use Case PingProcessSocketsMemory......Dependent Systems
  29. 29. Example 3: Dynamic ComponentsOSGi etcRuntime is conquered!Hot deploy in architecture, not just for monolithsEach module should contain: Function, i.e. Code (F) Logging (L) Health Check (HC) Tests (T) From unit up to acceptance Use Case Ping and Use Case Coverage Agile Requirements (AR) …
  30. 30. Example 3: Dynamic Components"Screenshot"A is-integration-tested with BA depends-on BA part-of BfoobarMy PhoneGoneBigSystem
  31. 31. Example 3: Dynamic ComponentscontdMetadata Runtime, test time, compile time dependencies Licenses Interface compatibilityLots of it, but not usedCould be used for versioned build and development system meta info possibly machine searchable via POM, RDF etc Discovery mechanism for components ...
  32. 32. Example 4: Agile RequirementsNuked RequirementsImpossible to traceChanged req - Which code changed?Do references Findable in codeDo 1:1 relationship Refactorable Codable/compilable Runtime support
  33. 33. Example 4: AR Example//REQ specB#123@requirement(uri="req:custA.prod3.specB#123")Still not in one placeUnit TestsRequirement, RequirementManager
  34. 34. Example 4: AR Aspect@Aspectpublic class ColorMustBe256Requirement {@Around("execution(*")public Object invoke(ProceedingJoinPoint pjp)throws Throwable{// ...Do some check on ColorObject result = pjp.proceed();return result;}}
  35. 35. Self Reliant SystemsIn CodeIn ProcessIn MomentBuild it inFeed it backDo it when you still can
  36. 36. Self Reliant SystemsQ & A
  37. 37. Remember!Enter the evaluation form and be a part of making Øredev even better.You will automatically be part of the evening lottery
  38. 38. Self //moreBased on the component, not on the tool
  39. 39. Feedback speedsFeedback Is crucial!Fast Feedback Minutes Continuous integrationFurious Feedback Seconds Pair Programming Continuous Compilation (IDE)The faster feedback, the faster success or failure
  40. 40. Spot the Signs!Java 6: Monitor and debug always "present" jhat – analyze heap jconsole …Trifork P4, a profiler – use it in production//moreCustom monitoringSelf test
  41. 41. Codex HammurabiHammurabi, King, Mesopotamia Circa 1700 BCLawBoth law and houses still here