If some code should be refactored, stop what you are doing and refactor it.
Now, Chris is really smart and probably doesn’t mean exactly what he said, but it’s easy to misinterpret his advice. I’ll agree with him that you should be eager to refactor code when you discover the need. Don’t let that technical debt accrue interest longer than necessary! However, you shouldn’t be reckless about it.
Don’t do a refactoring in the middle of making another change.
If you are working on a story and in the middle of making a code change when you discover the need to refactor something, make a note of it (I usually create a chore in Pivotal Tracker) and forget about it until you’re done with the change in progress. After you complete the change, come back and do the refactoring. Make sure all tests are green before starting to refactor, and are green when done. The refactoring change should be a separate commit in git (separate checkin in SVN, etc).
OK, I’m pragmatic and realize that that approach doesn’t work all the time, but it’s a good ideal to shoot for. I considered discussing cases where it would be OK to refactor something in the middle of another change, but on second thought I think I’ll leave that be for now. You’ll learn that for yourself better than by following someone else’s advice on the subject.
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.
So I’ve been writing a faux-legacy application, or at least enough of one to make the needed points in the tutorial. The idea stumped me for a bit because the app needs to be both complex enough to plausibly show the issues in legacy testing and simple enough so that setup and changes can actually happen in a short workshop.
Aggressive corner cutting on features that aren’t essential to the presentation.
Don’t look anything up and don’t use gems or plugins, not least of which to prevent setup issues.
Make no effort to put things in the “right” place.
Randomly, do something a little bit less elegantly than normal. Oh, and some metaprogrammy Ruby things were off limits, assuming I was writing as somebody who didn’t know Ruby that well.
Boy I sure was able to write that code fast without the pesky rules! I guess that TDD stuff isn’t that great after all.
I think I believe the second point more than the first. It’s hard to look at this code and not see some major pain coming in the future. That said, you have to acknowledge the emotional power of seeming to write fast code.
The temptation to say, “I was deliberately writing ugly code. If I just stopped doing that, then boy, I could go really fast and not use TDD, I can control bugs without TDD.” And the thing is, that’ll be true for a while. Maybe a long time, if you’re pretty good and working by yourself.
XP or not XP, that is the question. The answer is XP.
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.
I spent most of the winter, spring, and early summer of 2000 working on a largish web project for a Fortune 500 company that you’ve definitely heard of, but which made a regular practice of scaring the hell out of any vendors who might want to ever advertise the fact of their association.
This company was large enough to have a technical conference/fair for the IT departments of its various subsidiaries. I remember attending as a vendor, and being in a presentation from the company’s legal department that prominently featured the comment, “you vendors have the silly idea that your liability is limited to the size of your contract with us”.
Anyway… the project was a collaboration among several subsidiaries that had never worked together before. Not only was this the largest project I had been on by far, but there were also about a half dozen customer companies that all had different ideas about how the project should run — it wasn’t unusual to have conference calls with about three dozen client representatives to about five of us. I always kind of thought that the reason our tiny web company was picked for the project was to act as an impartial referee.
Unsurprisingly, we made every mistake there was. We picked tools that were not adequate to the task, and although our application design wasn’t bad, regressions were a constant feature of our staging deployments. The customer kept changing the goals of the site, not to mention tiny details, and we had no way to organize or manage the changes. We had an ongoing argument with one of the internal teams who wanted us to change our entire database schema. Our own management grabbed half the development team to completely redo the interface less than a week before the deadline.
In the wake of the initial delivery, my company did some retrospective sessions. I had heard about XP a little at that point, and was looking for some way to vocalize my feeling that the project had been a structural failure, even though we had more or less delivered on time. Which is how I came to read the book in the first place.
Unsurprisingly, XP’s emphasis on sustainability, clear descriptions of priority and responsibility, testing, refactoring, and quality code resonated with me pretty strongly. It seemed like a rebuttal to every pain point we had in the project. I remember reading directly from the book at a retrospective meeting, prompting some wisecrack from a manager about my academic bookishness. Guilty, I guess.
With one thing and another, it was several years before I was in a position to impose a full Agile/XP project structure on a project. Until then, what I was able to do was test — even in places where that wasn’t part of the team’s normal process. The fact that test-first seemed so helpful made the whole Agile structure seem more plausible, and when I was finally able to put an Agile project in place, I was ready to make all new mistakes.
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.
Me: We use Fibonacci numbers, 4 isn’t a Fibonacci number.
Me: [Long pause] Well, um, that’s a good question.
That said, Fibonacci points seems to be something that got popular when I wasn’t paying attention, and it kind of seems to me that, theory aside, 4 is a useful concept in practice for, you know, marking a story that is bigger than 3 points, but not quite 5 points. On our team, we have at least one story in that slot every iteration, and somebody (okay, me) always bemoans that the story should be a 4.
Those of you who want to join this little “Why Not Four?” crusade, should start chanting “More Four! More Four” or “What do we want? Four. When do we want it? Three to five days from now” at your iteration planning game events. Together, we can see a brave new world without an awkward pause between three and five.
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.
First off, a real problem I have when writing about pair programming is that a significant percentage of the people I’ve been pairing with recently are likely to read this. I don’t mean anything by it — it isn’t you it’s me. I apologize in advance, and all that.
No programming technique is always appropriate, and that goes for pair programming, too. Some tasks, especially the rote, boring yak-shaving ones, don’t need a pair, and the team should have leeway to make that decision.
Have a plan with your pair. The Pomodoro 25 minutes on/ 5 minutes off thing is effective, but you need to agree to it (or some variation) when you start. However, a project with a long build time or test suite run time really kills any kind of Pomodoro-like schedule.
Pair programming is part of the agile bet — in my experience it’s almost always a short term time loss with the hope of better performance over the long haul. I know there are studies that say that two programmers pairing are faster that two programmers working alone. All I can say is that isn’t consistently my subjective experience. It is common to work in a pair that is short-term faster than I would be on my own, but I don’t always feel like the pair is faster than both programmers would be on their own separately. Again, that’s in the short term.
The bet is that the investment will pay off over time in lower defect rates and better knowledge transfer. And I do think that’s reasonable, but it’s by no means assured.
I think the best long-term goal of pairing is to keep knowledge from being siloed within the team. Anytime you are forced to say something like, “that’s a search problem, Fred has to work on it”, that becomes a potential bottleneck for your team. So rotating pairs such that everybody gets to do everything is an important part of what makes pairing work.
hate it when pairs rotate, because they don’t know who to talk to about issues having to do with a particular feature. If you are pair rotating frequently, people outside the team need to have some way of discovering who is the current contact on a story or set of stories.
Logistics are a major pain in pairing. You pay for mis-alignment of time. One person gets in a half-hour earlier. They eat lunch at different times. One person gets pulled into a meeting (a particular problem if you are pairing senior and junior members), hell, one person goes to the bathroom more. Every disconnect gets felt when a team is pairing. Mandating specific hours and eliminating work at home is emphatically not keeping with the spirit of agile as I understand it, so what’s the solution?
Pairing, by definition, leads to a loud work environment — pairs need to talk. Some people will definitely find this to be a problem, and I think it can work against concentrating on a problem.
Ultimately, I think it’s a problem if pairing is the only way that team members are allowed to work, both for logistical reasons, and also for loud work environment type environmental reasons. Which leads to the radical mush-mouth position of “pair when it’s appropriate, don’t when it’s not”, which is a really annoying conclusion to come to at the end of a blog post like this.
While I’m in the self-promoting mode, the book is also available for pre-order at Amazon and other exciting locations.
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. There’s a brand-new Advanced Rails class that will be August 30th through September 2nd, and a version of the Boot Camp that meets weekly on Mondays starting September 20th.
All of which sort of reminds me… a few years ago, when I worked at a major telecom company with a reputation for major waterfall development, I attended the “agile” track of an in-house seminar on software techniques in use at the company. Everybody in attendance there claimed to be agile, but only about 1/3 (by show of hands) were doing any kind of automated testing. It was, to say the least, a weird flavor of Agile. But I guess, you do what you can do and what works for your team.
Finally, I’ve been yammering here about iPad text editing and Dropbox for a few weeks, so I should mention Droptext, which seems to be the first iOS editor that saves and reads from Droptext. It’s rather minimal at the moment (and kind of crashy), but I suspect the mere fact that it reads Dropbox files means that it’s automatically useful.
June 16, 2010: What Shoulda We Do?
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. But, of course, I can’t help thinking about how this affects me, and having Shoulda be primarily a complement to, rather than an alternative to, RSpec has an interesting effect on the book I’m in the middle of writing.
It’s so funny how these things change. It’s been about eighteen months since I started writing what would become Rails Test Prescriptions. At the time, I was not a big fan of RSpec, largely because I didn’t like the heavily mocked style that seemed to go along with it. With the emergence of Shoulda and the factory tools, Test::Unit had gained basic functional parity with RSpec. It also seemed like Shoulda/Test::Unit was really starting to gain community mindshare.
So, I wrote the book intending it to be a basically tool-agnostic guide to Rails testing, but with most of the examples in Test::Unit on the grounds that a) Test::Unit is part of the core Ruby and Rails stack, so it’s always around, b) it’s what the core team uses, c) I personally was using Test::Unit, and d) RSpec already had a book, so it seemed prudent for many reasons to find my own space. Those of you who bought the Lulu version will remember that it has longish chapters on Shoulda and RSpec, treating them more-or-less equally as alternative mature test frameworks.
In the interim, tools have ebbed and flowed. Cucumber came out, with very strong RSpec support (especially at first), starting a bit of a trend of new tools supporting RSpec over Test::Unit. The single-assertion style from Shoulda seemed to gain some traction among RSpec users. I started actually using RSpec more, and liking it.
At the same time, some things haven’t changed. I’d still like the book to be framework agnostic to the extent possible. Test::Unit is still the Rails default, and is probably still easier for a somebody new to testing to understand. But I think I have some re-writing in my future.
Martin Fowler on what makes a good team room for an agile project.
Speaking of RSpec 2, here’s one of what I hope will be many posts from David Chelimsky about a new RSpec feature, metadata and filtering.
Gitbox is a new Max OS X interface for Git. Currently seems less full featured than the GitX fork that I use, but it does seem like a nice start.
Relevance announces PDFKit, a new library for PDF generation, along the lines of PrinceXML. I don’t see this as a replacement for Prawn at all, though. There will always be cases where direct generation makes more sense. And there will always be cases where conversion makes sense. I think doing a book with Prawn would have been challenging, for example.
Finally, here’s a simple little survey of the Ruby community. I note parenthetically that RSpec has 42% of the vote for Preferred Testing Framework, with Shoulda and Test::Unit having a combined 31%.
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.
Jake Scruggs asks if you are really doing Agile development.
Mike Gunderloy makes a list of the services and tools that he finds useful in his development business. A great post if you are a small consulting firm.
Harri Kauhanen posts about how to sell Ruby on Rails projects. I’ve heard most of these in sales meetings over the last few years, though my impression was that it was getting better.
The Rubinius Ruby interpreter reached a 1.0 milestone on Friday, as noted by nearly every Ruby person on Twitter. So far, I haven’t used it, and my RVM install of it failed.
In a less interesting story, Ruby Gems 1.3.7 was also released.
This Onion article about David Simon doing a series in Wilmette, IL, cracked me up, but mostly because I grew up there.
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.
Kent Beck is publishing some old pieces again, including one about how the original XP book made the mistake of equating “the team” with “the developers”.
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.
Still messing with Capybara and Webrat. Somewhat hampered by the fact that most of the usage of these tools is via Cucumber, so there’s not a lot of documentation on them as standalone tools (particularly Capybara). Muddling through, though.
Two Ruby tip articles caught my eye. This one, by Alan Skorkin, is a complete overview serializing objects with Ruby. And here’s a small tip from Ruby Quick tips about ensuring that an incoming option hash has only certain keys. I think the benefit of doing that is as much in revealing intention as anything else.
In our Agile section, we’ve go Nicolas Alpi reviewing what it is like to pair program. I have a half-written post on pairing floating around MarsEdit here… I’m still ambivalent about it even after largely pairing for the last six months. I think some of that is a personality thing, but I also think the idea that pairs do a better job of staying on track has been a little oversold — it happens, but there are other offsetting issues. I really should finish that other post.
Also, part two of Kent Beck unedited and screencasting about testing. I admit I haven’t watched this part yet.
Don’t take your iPad to Israel (insert holy tablet joke here), as of a couple of days ago, the Israeli government has been blocking them at customs pending approval of their WiFi and security standards. In the meantime, those people who tried are being charged for every day the iPads sit in customs, and also agreed to pay a 16% Value Added Tax according to Israeli law.
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.
Still working on Webrat and Capybara. Still waiting for a cover. Somewhat doubtful that the beta will happen this week, but I haven’t been told that for sure.
Confused by ==, equal?, and === in Ruby? You won’t be after this article.
Hey, it’s another big-time Agile founder: Ward Cunningham being interviewed. Pull quote: “When you’re doing it well it feels a little plodding, you’re not racing ahead like you might do on your own. But what happens is that it never slows down.” Can I get that on a T-Shirt?
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.
Tweetie is probably the only case where I actually prefer the iPhone experience to the desktop experience, but I’d also be very sad if Tweetie for Mac was orphaned. (Not least because I just bought the MacHeist bundle in part as a way to get the Tweetie Mac beta sooner…). Later update: Tweetie developer Loren Brichter said on the MacHeist forum that the next Tweetie/Mac beta will come out.
I actually suspect that at least some of the existing iPhone Twitter clients will be able to continue — there’s clearly room in the ecosystem for apps that have much different opinions than Tweetie. It depends on how aggressive Twitter is planning to be. Dropping Tweetie’s price to free strikes me as agressive, although it may just be that the Twitter team is averse to direct ways of making money.
As for the Apple story, it’s a familiar space. Apple does something — in this case, blocking apps not originally written in C, C++, or Objective-C — that might have a reasonable user or branding component (keeping the iPhone platform free of least-common-denominator cross-platform apps) and taking it just too far for users or developers to be comfortable with it. That’s, of course, an understatement, as a lot of developers are really angry. Gruber’s point about the Kindle apps is good (and was later cited by Steve Jobs), but on the whole, I think this is a bit to far for Apple, or maybe I’m just upset that that the door seems to have been slammed on MacRuby apps for iPhone ever being feasible.
Still working on the Webrat/Capybara chapter. Describing two tools that are so similar is really challenging for me — when there’s a difference, keeping it clear which tool is under discussion.
Also I’ve got the probability that I’ll have an article in an upcoming issue of the Pragmatic Magazine. This will probably be based on material from the book, but edited to fit the magazine article format. Probably either factory tools or mocks. Or maybe Ajax testing. Haven’t decided yet.
Don’t think I’ve mentioned this yet, but here is a cool presentation of RSpec tricks. Some of these don’t work in RSpec 2, though.
While we’re on the presentation kick, here’s a nice intro to Git from James Edward Gray.
If you’ve ever tried to deploy Agile in a hostile environment, then the recent This American Life episode about the General Motors/Toyota NUMMI plant will resonate for you.
The sound levels are really low&#8230; but hopefully you&#8217;ll find it helpful.
You can also <a href="http://www.slideshare.net/robbyrussell/launching-ruby-on-rails-projects-a-checklist">view the slides</a>.