Self Reliant Systems
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Self Reliant Systems



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 ...

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".



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Self Reliant Systems Presentation Transcript

  • 1. JavaSelf Reliant SystemsBjörn Granvik
  • 2. Self Reliant SystemsIn Code, In Process, In MomentBjörn GranvikCTO, Jayway
  • 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. Toyoda and His loom30:1 - looms:personsStop the line!
  • 5. Our Reality?MeProjectsTest serverTestsTest serverStagingserverProductionserverProductionserver 2Productionserver 3LoadBalancingJoeMr SmithSADUCRTESGKWStoptheline?
  • 6. CodingAnything that changes the behavior of your"parameters"Admin console, tweaking the productionLoad balancers, pools, indexes, ……programming
  • 7. The Problem
  • 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. Symptom: Whazzup?
  • 10. Symptom: More Whazzup!
  • 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. Symptom: Compile?BackupContinuous IntegrationContinuous Feature Creep…Q: Five years on, does your code compile?…now what?– Buy single malt, call the programmer!
  • 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. 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. 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. Theory
  • 17. The Line …in theoryAny feedback oriented system willeither adapt and succeed - or fail fast.
  • 18. The Component …in theory
  • 19. What to do …in theoryBuild it inFeed it backPay it forward
  • 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. In ProcessNot in process  automatically forgottenAutomatic & repeatableFeedback Oriented
  • 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. Examples
  • 24. NO!Example -1: Wheres that lib?Yes
  • 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. 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. 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. Example 2: Running!Use Case PingProcessSocketsMemory......Dependent Systems
  • 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. Example 3: Dynamic Components"Screenshot"A is-integration-tested with BA depends-on BA part-of BfoobarMy PhoneGoneBigSystem
  • 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. 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. Example 4: AR Example//REQ specB#123@requirement(uri="req:custA.prod3.specB#123")Still not in one placeUnit TestsRequirement, RequirementManager
  • 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. Self Reliant SystemsIn CodeIn ProcessIn MomentBuild it inFeed it backDo it when you still can
  • 36. Self Reliant SystemsQ & A
  • 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. Self //moreBased on the component, not on the tool
  • 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. 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. Codex HammurabiHammurabi, King, Mesopotamia Circa 1700 BCLawBoth law and houses still here