ruby codebases in an
entropic universe
or, how not to kill a Ruby project in eighteen
months
niranjan paranjape
mechanical engineer.
one rube goldberg machine.
     lots of ruby code.
http://github.com/niranjan


http://twitter.com/niranjan_p
sidu ponnappa
programmer.
     bibliophile.
failed entrepreneur.
http://github.com/kaiwren


http://twitter.com/ponnappa
quality / entropy
quality
quality is valuable
quality is hard to measure
  it’s effects are also hard to measure
(especially in software)
flexibility
encapsulation
scalability
encapsulation
encapsulation?
grouping related data and behaviour.
         also, data hiding.
not really
the principle of segregation of design decisions
 in a computer program that are most likely to
   change, thus protecting...
so...
encapsulation is a means of limiting the effects
                   change
conversely
in a system that does what is needed, and, if
what we need never changes, we don’t care
            about encap...
so, what’s the problem with
         change?
eventually, it comes to this:
entropy
codebases have entropy
given enough time, the entropy of a codebase
 increases to a point where changes become
           ...
analysis
1
ok, it’s covered
let’s get back to the analysis
quick analysis
• this method is HUGE (smell!)
quick analysis
• this method is HUGE (smell!)
• multiple branches (obscene number,
  actually)
quick analysis
• this method is HUGE (smell!)
• multiple branches (obscene number,
    actually)
•   multiple exit points
boiling frog

once upon a time a domain rule wound up in a
                   controller
 over time controller became the ...
the metaprogramming
     lightsaber
another example
basically
metaprogramming...
don’t
other fun examples

•   overriding responds_to? on Object
•   un-defing id on Object (thanks Brian!)
•   editing boot.rb in...
bad ideas attract other bad
          ideas
entropy
complex engineering
     problem
made worse by... the
 lightsaber in ruby
lightsabers require discipline
lightsabers require precision
http://www.thetoque.com/images/stories/lightsaber.jpg
yeah, like that
    anyways...
ruby projects require more
           care
solutions?
1
specs
everything begins with a
       safety net
they describe how the next developer (including
     yourself) should consume your code.
they are specifications. a spec doesn't prove
 anything, but it does tell you that for one very
particular scenario, your c...
2
specs
they are the only confidence you, as a developer,
     should have in your code. whether it's an
acceptance test script wri...
3
observe trends
trends to watch
quantifiable
code coverage
cyclometric complexity
file size
spec file size
call duplications
churn
class reopen count
performance
environment setup time
unquantifiable
public API methods stay the
   same, but the specs
          increase
modules without a contract
number of entities that need
   setup for one spec
how?
ci builds
(ratcheted?)
metrics
specific issues
bad code
specs
DRYing prematurely
poor modelling
team dynamics
stick to idiomatic code
      conventions
but know when to deviate
too many conventions in a
       codebase
principles vs. mechanics
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Ruby codebases in an entropic universe
Upcoming SlideShare
Loading in …5
×

Ruby codebases in an entropic universe

1,520 views

Published on

How to manage entropy on Ruby codebase or, how not to kill a Ruby project in eighteen months

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
1,520
On SlideShare
0
From Embeds
0
Number of Embeds
42
Actions
Shares
0
Downloads
9
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide


  • intro
  • intro


  • intro
  • quality and entropy are the two themes underlying our talk.
  • Quality

  • how would you measure the value of a codebase? $ revenue generated? Time saved? LoC? None of these have a baseline against which you can measure success or failure
  • how would you measure the value of a codebase? $ revenue generated? Time saved? LoC? None of these have a baseline against which you can measure success or failure
  • The need to adapt software to changing realities is what drives feature requests. The quality of a static codebase doesn’t matter as long as it *works*
  • So... some part of code quality is encapsulation
  • is the code factored in a manner which allows tuning parts of it without affecting other parts
  • Which is encapsulation again
  • So what exactly *is* encapsulation
  • This is what we’ve been taught in college

  • David Parnas’ paper




  • This is a controller action. This is also really, really bad code. Is this familiar?
  • Which brings us to entropy
  • This is a controller action. This is also really, really bad code. Is this familiar?
  • As you work on a codebase the complexity of the code always increases and quality decreases. The difference is that unlike Physics, entropy increase isn’t constant - but more on that later, so hold your thoughts.
  • Let’s walk through this code quickly and see what’s the problem. We aren’t talking about fixing it - but just looking to understand the problems that exist.
  • Step 1 when dealing with ANY code - specs.
  • Ok, that’s good.
  • Coverage is good. It means we have *some* kind of safety net. How good that safety net actually is depends on how the specs were written, but lets defer looking into that for a bit.
  • This is a controller action. This is also really, really bad code. Is this familiar?
  • any method that has more handful of lines, or deals with more than a single concept is big. A one page method is an abomination.
  • This is a controller action. This is also really, really bad code. Is this familiar?
  • any method that has more handful of lines, or deals with more than a single concept is big. A one page method is an abomination.
  • This is a controller action. This is also really, really bad code. Is this familiar?
  • any method that has more handful of lines, or deals with more than a single concept is big. A one page method is an abomination.
  • Clearly this isn’t a good idea. And the people who wrote this would agree with me, and it was never their intention to get to this point. But they did, somehow, one if statement at a time and they started living with broken windows. That said, this could happen anywhere, in any language, right? Lets look at some Ruby specific fun and games involving the...
  • The Ruby programmer that starts to understand metaprogramming is like a Jedi apprentice with a lightsaber. Power without wisdom/experience. It appears that all problems are easily solved using a few quick slashes and hacks. For example...
  • Read the comment at the top of the page if you will. “This method is regenerated at runtime based on what the prefix is set to.” Uh, huh. And that’s a good idea how?


  • The metaprogramming lightsaber is fun, but sometime... ***? Like seriously, ***?


  • well, that’s a mechanic right there - the principle is that you need to wait until you have the judgement to apply the right tool for the job
  • Clearly, these are bad ideas. They might have seemed like good ideas to begin with, solving the problem quickly with a hiss and a sizzle. Even though they do solve the problem, they don’t do so in a manner that is well encapsulated, easy to spec and easy to understand. Over time, they act as points where cruft starts to accumulate.
  • eventually, you’re like the boiling frog. you did one little thing which wasn’t ‘clean’ as a quick hack, and then two months later you realise someone else saw it, though it was a good idea and replicated it everywhere. eventually you get
  • which, in a nutshell, is entropy on a codebase. After a while you can’t make any change without tripping over something (or someone).
  • entropy is a complex engineering problem
  • this is why Ruby codebases need more care and love than most other codebases

  • You need to know when, where and how to use the lightsaber

  • The point is... (next slide)
  • basically...

  • Step 1. Specs.

  • preferably one that doesn’t take too much time


  • Back to step 1. Specs.
  • no, seriously. we can’t emphasise this enough. with something as flexible as Ruby, you need specs.

  • Back to step 1. Specs.

  • As entropy on any code base always increases, it is essential to keep an eye on trends, and refactor/redesign every once in a while to make sure that it doesn’t go out of control
  • to make sure it doesn’t deteriorate like this
  • the trends you should watch
  • the trends you can quantify
  • the trends you should watch
  • the trends you should watch
  • the trends you should watch
  • the trends you should watch
  • reek



  • how long does it take a new person to get productive on your codebase

  • which means the same entity does more



  • first, you need a build
  • first, you need a build


  • bad specs, poor coverage




  • Using a hash


  • Ruby codebases in an entropic universe

    1. 1. ruby codebases in an entropic universe or, how not to kill a Ruby project in eighteen months
    2. 2. niranjan paranjape
    3. 3. mechanical engineer. one rube goldberg machine. lots of ruby code.
    4. 4. http://github.com/niranjan http://twitter.com/niranjan_p
    5. 5. sidu ponnappa
    6. 6. programmer. bibliophile. failed entrepreneur.
    7. 7. http://github.com/kaiwren http://twitter.com/ponnappa
    8. 8. quality / entropy
    9. 9. quality
    10. 10. quality is valuable
    11. 11. quality is hard to measure it’s effects are also hard to measure
    12. 12. (especially in software)
    13. 13. flexibility
    14. 14. encapsulation
    15. 15. scalability
    16. 16. encapsulation
    17. 17. encapsulation?
    18. 18. grouping related data and behaviour. also, data hiding.
    19. 19. not really
    20. 20. the principle of segregation of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed.
    21. 21. so... encapsulation is a means of limiting the effects change
    22. 22. conversely in a system that does what is needed, and, if what we need never changes, we don’t care about encapsulation
    23. 23. so, what’s the problem with change?
    24. 24. eventually, it comes to this:
    25. 25. entropy
    26. 26. codebases have entropy given enough time, the entropy of a codebase increases to a point where changes become impossible
    27. 27. analysis
    28. 28. 1
    29. 29. ok, it’s covered let’s get back to the analysis
    30. 30. quick analysis • this method is HUGE (smell!)
    31. 31. quick analysis • this method is HUGE (smell!) • multiple branches (obscene number, actually)
    32. 32. quick analysis • this method is HUGE (smell!) • multiple branches (obscene number, actually) • multiple exit points
    33. 33. boiling frog once upon a time a domain rule wound up in a controller over time controller became the place to put domain rules
    34. 34. the metaprogramming lightsaber
    35. 35. another example
    36. 36. basically
    37. 37. metaprogramming...
    38. 38. don’t
    39. 39. other fun examples • overriding responds_to? on Object • un-defing id on Object (thanks Brian!) • editing boot.rb in your Rails project • using instance_variable_get anywhere
    40. 40. bad ideas attract other bad ideas
    41. 41. entropy
    42. 42. complex engineering problem
    43. 43. made worse by... the lightsaber in ruby
    44. 44. lightsabers require discipline
    45. 45. lightsabers require precision
    46. 46. http://www.thetoque.com/images/stories/lightsaber.jpg
    47. 47. yeah, like that anyways...
    48. 48. ruby projects require more care
    49. 49. solutions?
    50. 50. 1
    51. 51. specs
    52. 52. everything begins with a safety net
    53. 53. they describe how the next developer (including yourself) should consume your code.
    54. 54. they are specifications. a spec doesn't prove anything, but it does tell you that for one very particular scenario, your code probably works.
    55. 55. 2
    56. 56. specs
    57. 57. they are the only confidence you, as a developer, should have in your code. whether it's an acceptance test script written by a QA (manual or automated) or the world's tiniest spec, this is your starting point. without specs, the only assumption you can reasonably make about your code is that it doesn't work.
    58. 58. 3
    59. 59. observe trends
    60. 60. trends to watch
    61. 61. quantifiable
    62. 62. code coverage
    63. 63. cyclometric complexity
    64. 64. file size
    65. 65. spec file size
    66. 66. call duplications
    67. 67. churn
    68. 68. class reopen count
    69. 69. performance
    70. 70. environment setup time
    71. 71. unquantifiable
    72. 72. public API methods stay the same, but the specs increase
    73. 73. modules without a contract
    74. 74. number of entities that need setup for one spec
    75. 75. how?
    76. 76. ci builds (ratcheted?)
    77. 77. metrics
    78. 78. specific issues
    79. 79. bad code
    80. 80. specs
    81. 81. DRYing prematurely
    82. 82. poor modelling
    83. 83. team dynamics
    84. 84. stick to idiomatic code conventions
    85. 85. but know when to deviate
    86. 86. too many conventions in a codebase
    87. 87. principles vs. mechanics

    ×