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

Open letter to Business Analyst

Business Analyst plays a very important role in the entire cross functional agile team. They are the more real truth about the requirement of the business to software developers. Since Business Analyst have seen much software being build and broken over the years they develop a strong skill on how the solution works. They are very much aware of the overall flow of the software or High Level Architecture. An experienced Business Analyst in a team with senior developer and junior developer. It is natural that they with experience start captaining the project. Also there can be a deliberation and debate over the logic of the requirement, thus putting out all possible input conditions. There is nothing wrong about it but when you are not a part of everyday coding. It doesn’t make any sense to decide on what will be the table names, will the logic reside on database or code level. It should be the job of developer. Definitely all suggestions are welcome, however you cannot dictate terms.

Here are my reasons why it should be a job of developer to do the detail decision:

  1. Developer has their own design challenges to deal with. All the decisions are taken based on the requirements provided by Business Analyst.
  2. There are underlying coding style or design choices which a developer is comfortable with. This will help them in long term maintenance of the project. Also there can be multiple solutions to a particular problem.
  3. The design of procedural programming will be difficult to adapt in object oriented programmer or functional programming.
  4. The performance issues of 1999 i.e. of memory and latency is no longer valid on today’s day and age.
  5. In memory functional programming helps parallelism easier than last decade.

This is just a rant and my humble way to put few points forward.

Happy Software Development!