Noel Rappin Writes Here

Previously on Locally Sourced: About a year ago, I started this newsletter with a bunch of posts that I originally called XP 2020 and later called Entropy Essays – you can find all the posts here. I got bogged down and never got to the punchline… There’s a common thread in the story of how testing, object design, and pair programming have been adapted since XP and Agile became buzzwords. I think estimating fits here as well.

Trying to Define Undefinable Terms: The Locally Sourced Story Previously on Locally Sourced: I’ve been writing about XP and Agile. Most recently, pair programming. And how I think about technical decisions. I started to write a different essay here, but then I realized that I was sort of depending on having written something like this. So I wrote this. I’ve been writing all these posts about Agile and XP methods and I’ve been talking about process and about trust, but I haven’t defined them in the way I use them and I haven’t talked about how I think they are related.

We hope that 1 + 1 = 3 Previously on Locally Sourced: I’ve been doing a lot of these oddly titled posts about XP and Agile practices. Like testing. Or OO. I wrote about inclusion on agile teams. And about team metrics. Next up: pair programming. And even though it sounds a little pretentious to my ears, I really do think this is going somewhere, and I think between the last one and this one, the shape of the argument is starting to make sense to me.

Or Why is a Software Team Like A Shortstop Previously on Locally Sourced: I’ve been writing these Entropy Essays about Agile and XP practices. Here’s the most recent one. You can see the rest here. Tell all your friends and colleagues to subscribe. One of the great things about writing this newsletter is that it’s forced me to think some ideas through in more structured ways than I might have if I was just talking to myself in my own head.

Or: Trust Goes Every Which Way, And Makes Agile Work Previously on Locally Sourced: I attempted to justify all this agile stuff. Before that, more agile stuff. Also, I have a book out, and good marketing practices would suggest I mention that from time to time. This time around, I’m worried that all these words won’t help make the central point: Everybody on a software team should feel included and safe in their work because it’s the right thing to do.

I mean, really… Previously on Locally Sourced: I wrote about an XP practice. Then I wrote about it some more. Then I wrote about a different XP practice. Then I wrote about it some more. (Okay, it’s a bit of a stretch, but a domain metaphor was an XP practice, and OO modeling went hand in hand.) In any case, with more about Agile and XP coming up, I thought it was time for some self-justification.

Maybe more about the past than you needed to know? Previously on Locally Sourced: I wrote about kinds of object-oriented design. Before that, I asked why you hired that test. I didn’t exactly set out to write 1300 words on the history of OO design, but I pulled out some old books and got nostalgic. Tune in next week for more on Agile, communication, and inclusion. As I was writing the last post, I started skimming through a couple of my Object-Oriented textbooks from the mid-90s.

Speed matters. But not precisely. There are only two things that matter when thinking about the speed of your automated tests: How fast can you run the relevant set of tests to let the tests be helpful in development? How fast can you run a complete, green build for deploy? We’re talking about the first one in this essay. In development, you want to be able to run the tests you are writing and a subset of tests that are most likely to break based on your changes.

Charles Max Wood posted this on Twitter: Am I misunderstanding agile? or is it inappropriate to try to peg velocity? — Charles Max Wood (@cmaxw) October 26, 2012 @noelrap They’re telling us we behind on the sprint. My understanding of agile is velocity is set by team pace, not wishful thinking. — Charles Max Wood (@cmaxw) October 26, 2012 @noelrap You can push for deadlines, but you can’t tell us that we’re behind on the sprint just because we’re not going to achieve velocity.

I’ve been working on my tutorial session for WindyCityRails (tickets still available…). The session is about how to test when you are working in a legacy app that doesn’t have tests. Naturally, that requires some legacy code for the attendees to work with during the tutorial. My own worst Rails messes are either back in the 1.2.x time frame or I don’t have access to them any more. I don’t have the right to distribute legacy code that I have inherited, and most of those people wouldn’t want me calling their code a junkpile in public.

While I’m commemorating anniversaries this summer, I just remembered another one. Ten years ago this summer was when I first read the original Kent Beck “white book”, Extreme Programming Explained, which is one of only a couple of books that completely changed the way I approach whatever it is that I do. Considering that I’ve spent most of the last ten years practicing, advocating for, and writing about XP and Agile development, it’s not an overstatement to say that Kent’s book, and the ideas about how to be a professional programmer, changed my professional life.

Not much time this morning, not many accumulated links. So just a little bit today. Book Status Still writing the new parts of the legacy coding chapter, last night a little bit on removing dependencies. I think only one more section to go before that’s a complete draft. Next up, I think, is making the code samples Rails 3 compatible. One quick thing Sometimes you don’t realize how weird something is until you try to explain it.

Repeating yourself is clearly an occupational hazard of blogging. I’ve been trying to put together a post about pair programming for a while. Somewhat randomly, I found myself wandering through my blog archives at Pathfinder, and I came across this little essay, which was the last thing I wrote at Pathfinder before, shall we say, Events Transpired, so I probably blocked it a bit. I definitely blocked the responses that were on the Pathfinder blog the following week, because, well, Events Were Transpiring.

Update Beta 4 of Rails Test Prescriptions is now available, with two new chapters, one on Rcov and coverage in general, and one on writing better tests. Buy here. While I’m in the self-promoting mode, the book is also available for pre-order at Amazon and other exciting locations. More Promotion And while I’m here, I should mention that Obtiva has updated their training schedule. Obtiva offers a 4-day Boot Camp for learning Rails and TDD that will next be offered August 2nd through 5th.

Top Story Thoughtbot talks about their plans for Shoulda moving forward. The big takeaway is that, while the context library will be separated out for use in Test::Unit, both Shoulda style and Shoulda effort will be focused on RSpec integration. I have some complicated thoughts about this one. I’m thrilled that Shoulda is being maintained – it’s a tool I’ve used a lot, and I was starting to get worried. And they should move their open source tool in any direction they want.

Book Status The Cucumber chapter is nearing final edit for beta. I cleared up a handful of errata, of which probably the most serious was a mistake on how to get the fixture data to pass the first test in the book. I’m hoping to get Beta 3 out later this week, and then I have to decide which direction for beta 4. Oh, and the book: still on sale.

Top Story JRuby 1.5 is out. Highlights include improved Rails 3 support, better support for Windows, better FFI support, better startup time (yay!) and a lot of other tweaks and fixes. Book Update Still Cucumbering, hope to finish today. The book is still on sale, of course. And I’d still love to see more comments in the forum. I’ll be talking at Chicago Ruby on June 1, exact topic TBD (let me know if you have a preference), but I’m leaning toward talking about how to avoid test problems and write good, robust tests.

Top Story As part of the Chirp conference, Twitter and the Library of Congress jointly announced that the Library will be storing Twitter’s entire public archive. I’m sure your expecting an easy joke about how many sandwiches the LoC now knows about in their archive, or about how scholarly papers about the archive will be limited to 140 characters. (Or, for a more academic joke, limited to 140 authors…) All that aside, though, I think archiving and making all this available is pretty neat.

Top Story iPads. Lots of them popping up in and around work. Probably some more coherent impressions coming later. Wait, once again, Twitter has a big announcement after I start writing this. This time, they are going to start placing ads in the Twitter stream in various ways to be announced today. My quick reactions: a) I long suspected this day was coming, b) if the ads in clients are any guide, they aren’t particularly burdensome, c) implementation details will decide how irritating this is.

Top Story For a while, it looked like the top story was going to be Apple’s new developer Rule 3.3.1, described here by John Gruber. More on that in a second. But the real top story is the news that Twitter has bought Tweetie, intending to rebrand it as Twitter for iPhone, and dropping the price to a low, low, free. Eventually, it will be the core of Twitter for iPad.

And now some testimony from Brother Nicely-Nicely Johnson, I mean, James Turner, from O’Reilly Radar: The Cult of Scrum: If Agile is the teachings of Jesus, Scrum is every abuse ever perpetrated in his name. In many ways, Scrum as practiced in most companies today is the antithesis of Agile, a heavy, dogmatic methodology that blindly follows a checklist of “best practices” that some consultant convinced the management to follow.

In true blog form, a declarative statement: Hear ye, hear ye! Any so-called Agile team that ever tries to translate “points” into actual units of time is presumed dysfunctional until proven otherwise. You’ve done it, I’ve done it, we’ve all done it. Doesn’t make it a good idea. In the spirit of my last post, allow me to over-explain. A typical Agile project handles estimation by splitting the project up into smallish user stories and assigning each one a point value, typically between one and five, though different teams have different standards.

New post on the Pathfinder site. I had fun writing this one. It’s on some lesser known variants of test-driven development. http://blogs.pathf.com/agileajax/2008/02/lesser-known-te.html

Two things on the Pathfinder blog. Agile Publishing, on publishing experiences and agile methods. Live Ruby: Testbed, an attempt to work through a small test and metaprogramming problem live and on the blog. Enjoy.s

Another blog post up on the Pathfinder site. This one is about Agile in general, and features what I think is the World Blog Premiere of the soon to be famous Boring Software Manifesto. Enjoy.

My first post to one of Pathfinder’s official blogs is up, it’s a companion piece to the blog post here on Test-Driven Development, and you can find it here.

Of course, since I muse in an agile way, I reserve the right to change my mind based on future developments… Software development usually takes place in a complex environment where your goal can change quickly. In general, there are two ways to deal with a complex environment. One is to try to anticipate, in advance, every possible permutation you might need to deal with, and the other is to manage your environment with the flexibility to respond to new challenges with minimum effort.

Three posts that caught my eye today. Ruby School Gregory Brown over on O’Reilly net has an article about using Ruby in Computer Science courses, at least in later algorithm classes. It’s not a bad argument, but I think it’d be more convincing if the Ruby example was a little cleaner and easier to read compared to the pseudo-code. Let’s see… The last time I had to care about this issue was about eight years ago when my grad institution was going through a somewhat controversial revamp of the CS curriculum.

Of all the exciting ideas and revelations that came from Kent Beck’s original XP book, Test-First Programming has been the one that most significantly affected the way I work on a day-to-day basis. I love programming test-first. It’s a great way to take a large, amorphous task and solve it piece by piece. It’s also a nice morale boost – “Hey, I know that my code does nine things. Let’s go for ten…”