A bloody excellent IT Conversation podcast by Jason Fried of 37signals, taken from O’Reilly ETech 2005.
Jason covers a lot of issues that are at the heart of Agile Development, particularly when it comes to keeping your codebase lean-and-mean, and the YAGNI principle.
Seriously: everyone should listen to this.
From Ron Jeffries, courtesty of the XP Mailing list:
“YAGNI is about coding, not about thinking”
From the JUnit mailing list, courtesy of J.B "JUnit Recipies" Rainsberger
JBR’s postulate 1. For every testable design that requires exposing elements “just for testing”, there exists an equivalent testable design that does not require exposing elements “just for testing”.
A very interesting article, originally published in 1992, on Code as Design Yet more proof that there isn’t anything new about Agile (and that’s it’s best part! 😉
There’s always a lot of debate in the various agile groups about what BDUF is, why you should avoid it, when you should avoid it, and why is it bad (or good) for you. I just thought I’d outline my own opinions here.
Continue reading “Peering into the crystal ball: BDUF vs emergent design”
This has been said before, I know, but it’s worth re-iterating: a test should test one thing, and one thing only.
First, some scope definition. Using Kent Beck’s terminology, I’m talking about developer tests, not acceptance tests. Also, by one thing, I mean that there should be only one thing that breaks the test (which is very different from saying any failure should only break one test…). In addition, the one thing that breaks should provide diagnostic information – a test failure shouldn’t leave you scratching your head to determine the immediate cause
Continue reading “Testing pattern: don’t test too much at once”
Two interesting examples of how the word “accountability” can mean different things.
I had a comment lodged on an older article recently. The poster was complaining about the poor quality of the JWebFit sub-project of JWebUnit In particular, he was complaining about how it meant their project wasn’t delivered on time. There’s an anti-pattern here.
Continue reading “Learn in the quiet times”
I love it when I get to delete code. Deleting code, particularly dead code, is such a wonderfully therapeutic exercise. You should try it some time.
Continue reading “Deleting code gives me a warm fuzzy feeling…”
Steve brings up a quote that I’ve always liked: By definition, risk-takers often fail
Continue reading “Failure is necessary to succeed”
Software is too expensive to build cheaply.... 