RubyConf, Day 1, 4p: Hurting Code for Fun & Profit
Ahhh, a nap makes all well. Last session of the day. Okay, you want to see these slides and the video once it’s posted by ConFreaks.
“Legacy code is any code you haven’t written.”
“People will press charges if you hurt them. Code won’t.”
“My name is Ryan and I like to hurt code. And I’m OK.”
Ruby Sadism: deriving pleasure from inflicting pain on software, esp. bad software.
Ruby Asceticism: cahracterized by or … [not fast enough, in the slides] … self-discipline
unit test is self discipline, YAGNI is abstention
“Technical debt: skipping design is like borrowing money, refactoring is like repaying principal, interest is paid as time dealing with complexity.” – Ward Cunningham, ComplexityAsDebt, c2.com
Use the Pareto Principle (aka 80/20 rule) to focus efforts
Increase the signal:noise ratio. Big alligators, little alligators, swamp.
“A developer’s obligation is to make sure that the code as written makes the clearest possible statement as to how the solution was understood …” –Ward Cunningham, TechnicalDebt
Introspection Oriented Design: Find the “I” … how did I miss that bug, where did I go wrong.
[HE QUOTED COVEY’S FOUR QUADRANTS! I’M VERY EXCITED! COULD YOU TELL?]
Expand your mind; more knowledge is better.
Write a lot of code. Make a lot of mistakes. Learn.
Push yourself, then push yourself more.
Mentarbator vs. Code Cowboy … find your sweet spot in the middle.
Tools to Help
Continuous integration and Autotest (with the doom guy)
Flog: complexity reporter based on ABC metrics; the higher the score, the harder to test.
Coverage tools: good to spot gaps, but don’t tell you the quality of your tests. 100% coverage with bad tests means nothing
Heckle: test mutator; if your tests pass after heckle, your tests are bad.
Be passionate. If you love your code, hate it, hurt it.
Q: Doesn’t using emacs violate your complexity rules?
A: Hey, I need an operating system, don’t I?
Q: When does [code-generation] violate complexity?
A: When it gives you a bad feeling.
Q: How much does your Evergreen background influence your philosophy?
A: Probably inverted my philosophy influenced the school I was compatible with. Stalker.
Q: You talked about design and about how you should always be thinking about it. Should you design the whole thing in advance or what (Chelimsky)
A: I design iteratively, TDD-based. If you try to solve the whole problem up front, you’re going to have issues that many have written about.
Q: How do you work with people who write bad code?
Hoy: I’ve seen him make somebody cry.
ZS: Who did I make cry?
Hoy: It was in private and I’m not going to say. It wasn’t me.
A: I try not to. Sometimes I’ll throw down the gauntlet and write something competing. Other times I’ll take advantage of ruby’s dynamic nature to just include what I need … I call it duck-raping
Q: WRT tech depth, how do you not revisit code flags?
A: I use a tag system (fix refactor hack doc and others). It lets me keep my brain on track and move on. [me: this is important]
Q: Have you found a way to automate heckle into your build process?
A: I have one lib (the png lib) that’s fully heckle-proof. Last iteration I hooked heckle into autotest; when it went green, it’d invoke heckle. The problem is the geometric expansion of tests.
Q: Given that only one of your libs passes heckle, do you just seek a better score?
A: Heckle shows you the diff of your test and what it changed without making the test fail (e.g. replace an assignment with a nil). A rats nest of code with tight dependencies where it breaks if you change anything will pass Heckle.
Q; are there tools you need as an ascetic that don’t exist yet?
A: Yes. Can’t name one off the top of my head.
Q: Pair programming … useful for you?
A: Ask Eric. (laughs) I find I get a 250% output increase.
Q: What’s your test:code ratio?
A: I don’t measure it often … generally 1.5:1 -ish but with artificial inflation of individual tests per argument, method, etc.
blog comments powered by Disqus