75 constraints used in 2015 across the Globe for Global Day of Code Retreat

Tomorrow on 18th November 2017 isĀ Global Day of Code Retreat 2017 #GDCR17 This will be my 3rd year in a row to attend and practice my craft. After 13 years of experience writing code it still feels like a ride in a theme park to attend Global Day of Code Retreat. In year 2015 I copied all the constraints from the website www.coderetreat.org

Image result for code retreat

Here are the 75 unique constraints that was used on that day

  1. Introduction to the problem
  2. Pair Programming
  3. Test Driven Development
  4. Small methods (<=5)
  5. No side-effect methods.
  6. No if-else
  7. No conditional statements
  8. No loop
  9. Ping Pong
  10. No constraints
  11. Babysteps
  12. Mute ping-pong
  13. Brutal refactoring game
  14. Zombies!
  15. Tell don’t ask
  16. Hexagonal board
  17. Simplicity
  18. No boolean flag
  19. No array
  20. Explore, Stabilize, Implement
  21. Pure Functions Only
  22. One Level of Indentation Per Method.
  23. No TDD, Honeymoon round
  24. TDD, keyboard only
  25. On paper
  26. TDD focus on behaviour
  27. TDD Like you mean it
  28. Code swapping
  29. No language primitives across method boundries.
  30. Make a test list No code in first 0 minutes, make a list of tests, then decide in which order to implement them
  31. No touchpad, no mouse.
  32. Intention, naming convention.
  33. Extreme OO
  34. First 0 minutes paper only, no arrays and no lists
  35. Acceptance tests only
  36. Use no matrix
  37. No Return statements!
  38. Pair programing, 0 min test paper only
  39. Fixed roles one writes tests, the other implements and swap 0 minutes before end all of the sudden šŸ˜‰
  40. Maxlines per method
  41. No predefined datastructures
  42. Four Rules of Simple Design
  43. Closing Circle
  44. Commit every 5 minutes, delete the rest Reduce the time to 3 minutes Last round 1 minute
  45. Taking baby steps write exactly one test within 2 minutes and commit it if you are in time, if not revert the changes
  46. Clean code
  47. Everything is represented by an immutable object, objects cannot change state.
  48. Primitive Revulsion.
  49. Three Laws Compliant.
  50. Total Ego Annihilation.
  51. So Fresh, So Clean.
  52. Cells talking to cells De-emphasis on the GoL world / board.
  53. Pairs can only communicate via tests
  54. Round Robin dojo
  55. Legacy code! This is a longerĀ  where devs unknowingly write untested legacy code with no restraints and halfway through they need to switch partners and maintain and refactor that code
  56. Driver gets keyboard
  57. Shortcuts are not allowed (e.g. ALT-TAB)
  58. Muted pair!
  59. Switch to 3 dimensions
  60. Object Calisthenics
  61. TDD + Simplicity + Immutable + Hive Board
  62. Noun Avoidance / Verb It Up, Verby Mc. Verberson
  63. Procedural (no tests) OR immutable objects
  64. Mob programming (basic Game of Life, no other constraints)
  65. Hive board (cell only has 6 neighbors instead of 8, a grid can be represented as a beehive) + mute mode (nobody can talk)
  66. 4 Verbs Only
  67. With graph constraints
  68. Extreme OO
  69. Evil Coder!
  70. Tell, don’t ask Only void methods
  71. Extract ’til you drop
  72. Exploratory testing
  73. Healing grid
  74. Let’s see how many alive cells you have on a 100X100 matrix after 1000 iterations ?
  75. No exceptions

Hope this list helps you tomorrow…

Constraint: Share this post Now!!! šŸ˜‰Ā 

Advertisements

Real experience of adding first sets of Tests to existing code base

I recently joined a team of very skilled and talented people. We wanted to put in Tests for an application which was running in production for quite some time. I cannot specify the details of the project but it had tens of thousands of line of code in it. It was developed in Microsoft Dot Net and SQL Server and a web application.

I would like to share some insight and recommendations:

  1. Long running tests and writing long dependency tests setups is the norm
  2. Adding technical debts in tests will be needed but keep it as clean as possible.
  3. Don’t worry of Unit Tests in the beginning. It will be lot harder to do it.(Add Integration tests, refactor code in smaller units, add unit tests later)
  4. Some types of test that willĀ help you during this initial testing phase :
    1. Pinning Tests : http://c2.com/cgi/wiki?PinningTests
    2. Characterization Test : http://c2.com/cgi/wiki?CharacterizationTest

You must be thinking you already know all this stuff above. But the view point I want to share here is some real world numbers and facts.Ā Firstly add Ā aĀ automated code coverage to get the results of your tests with just one click. (a simple .bat file worked for me)

  1. I was working with the code for first time.
  2. It took me 16 hours to put in first 6 tests.
  3. TheseĀ where clean, re factored and commit ready to Git.
  4. Code Coverage was 6% after 6 tests.
  5. When I added 5 more tests the code coverage was 15%
  6. Tests were covering different classes of different modules.

This stats may be controversial and its true that code coverage doesn’t signify that your code has 100% automated tests for all possible scenarios,Ā However here are some reasons to go with it.

  1. It give some numbers to go for duringĀ initial stage of adding tests.
  2. It will help you to add test harness for different areas of applications.
  3. You can share reports with team and get feedback on what’s next.

Happy Coding!