Following on from the previous article in the series, another "programming in the small" thing that annoys me is when warnings from the IDE are ignored.
This is more a matter of taste than previous articles - but it is based on reasoning rather than following a cargo cult.
If you look at the warnings from your IDE, they sometimes indicate the chance to do the best refactoring - deleting code. Eclipse, for example, will warn of unused imports, unassigned fields, and uncalled private methods. These are warnings I want developers to act on - and delete unused code. Unused code is code you might accidentally read, keep compiling, or slow you down from seeing the code that's actually used.
Sometimes IDEs provide warnings for things that aren't really a problem. The result of that is that in a lot of teams, developers just ignore all warnings, as the IDE has "cried wolf" too many times for warnings to be taken seriously any more.
I like to set the warnings of the IDE such that the ones I'm interested in are switched on, and the ones that cause "false positives" are switched off. I prefer to have no warnings at all, with some warnings that might sometimes be useful switched off, than to have more warnings but have to ignore some of them.
It's much easier to tell if a new warning has appeared when there are usually none. If you don't have the "false positive" warnings switched off (because you want some warning that is sometimes useful) the problem is that then you've got to remember which of the warnings you've got are the "false positive" ones, which can waste your time looking through them.
If the warnings are set such that there are no "false positives", then you know that if there are any warnings, you need to take notice of them, see what they are saying, and take action. Therefore, with warnings set appropriately, the team can follow a simple rule of not checking-in warnings - just like they wouldn't check-in compilation errors or code that failed the automated tests.
If you have no warnings in your code, it makes it much more amenable to running the splendid "find bugs" Eclipse plug-in. If you start off with no warnings, then you can run "find bugs" and know that all of the warnings are "find bugs" ones. Although "find bugs" is really good - it can produce too many "false positives" for me to want to run it all the time or to have a "don't check in warnings" policy apply to "find bugs" warnings, so I only run and look at "find bugs" warnings occassionally.
It would be great if Eclipse (or other IDEs) (and "find bugs") allowed you to ignore specific warnings - not just types of warnings. Then you could have the warnings set higher, and ignore "false positives" (that you have checked manually once) so you don't have to switch "often useful but sometimes bogus" warnings off.
Eclipse Monkey, from Bjorn Freeman-Benson and Ward Cunningham, lets you script the Eclipse IDE.
In Eclipse (version 3.1.2 - maybe this is fixed in other versions) when you paste multiple lines into a java file, it doesn't automatically convert the string into multiple lines for you. This came up when pairing yesterday, so I've written the following script, which converts whatever text is in your copy buffer into a multi-line string ready for pasting into java:
--- Came wiffling through the eclipsey wood ---
/*
* Menu: Convert multi-line string
* Kudos: Ivan Moore
* License: EPL
*/
function main() {
systemClipboard = Packages.java.awt.Toolkit.getDefaultToolkit().getSystemClipboard();
contents = systemClipboard.getContents(null);
msg = contents.getTransferData(Packages.java.awt.datatransfer.DataFlavor.stringFlavor);
msg = msg.replace('\\','\\\\');
msg = msg.replace('"','\\"');
msg = msg.replace('\n','\\n" +\n\t"');
newContents = new Packages.java.awt.datatransfer.StringSelection('"' + msg + '"');
systemClipboard.setContents(newContents, newContents);
}
--- And burbled as it ran! ---
To install this script, install eclipse monkey, copy the script above (including the "---" lines at the beginning and end), then from the "Monkey" menu in eclipse, select "Paste new script".
To run the script, copy some text, and then from the "Monkey" menu in eclipse select "Convert multi-line string". Then paste, and admire the multi-line goodness.
If you know of a better way of doing this in Eclipse (don't say "IntelliJ IDEA"), then please comment - although that wasn't the only reason for writing this script - it was also educational to write a Monkey script with a definite goal rather than just hacking around, which is all I've done with Monkey before yesterday.
Thanks to Monkey, it's much easier to extend Eclipse than it used to be; you don't have to write a plug-in for simple things like this example. I'll be using it more.
While at SPA 2006, I was talking to someone about pair programming. They said something along the lines of it being difficult to get accepted where they work. Someone else said that they'd not seen pair programming work anywhere. I piped up that I'd never seen it fail. I claimed to have pair programmed with around 100 people. Now I'm a bit more sober (it was a conference, after all), I've been reflecting on whether that was really true, or if I'm just full of ... beer.
When I first heard of XP, I liked the sound of it. Except for pair programming, which I thought was obviously nonsense. I was talking to a friend and ex-colleague, Tim Mackinnon, and he suggested that I suspend disbelief and try it for a few days. What's the worst that could happen? I might not like it for a few days then I could go back to not pair programming if I wanted.
So, I tried pair programming for a few days, pretty sure I wouldn't like it but willing to give it a go. That was late 1999 or early 2000 - I don't remember exactly - I've been pair programming, or cajoling teams into pair programming, most of my work time since then.
There's lots written about pair programming elsewhere; I'll just give a short list of what I've observed (which I'm sure isn't exhaustive).
Benefits:
- It's more productive overall
- You get higher quality code
- It's more fun
- Most people learn more by pairing (even very experienced developers)
- Inexperienced but capable developers learn lots very quickly by pairing
- It's more focused - less surfing, more working
- It's more focused - less gilding the lily, more getting it to work
- It's more focused - fewer dead ends, more working on what really needs to be done
Disadvantages:
- It's more tiring
- It requires a suitable physical environment (e.g. desks you can pair at)
- It's best if everyone works in the same place - remote pair programming can work well, but pairing is better in person
- It's best if everyone works the same times during the day - I've tried pairing on a team with "flexi-time" and it's not as good as having fixed hours
- It doesn't suit everyone
- It doesn't suit all types of work
I've got a bad memory, so I've had a look through my CV to remind me of the projects I've worked on since starting pairing. It turns out to be 14 projects, all with some amount of pair programming - more on what that means later. I've tried to remember as many people that I've pair programmed with as possible (that is, pair programmed with rather than just worked on the same project) - I came up with 85 names - 15 short of my claimed 100 - either I was exagerating (is that possible?) or, more likely, those people have been abducted by aliens who have then erased my memory of having pair programmed with them.
Of the 14 projects I've worked on since starting pairing, 9 used pair programming very nearly all the time for very nearly all the team's production code. The only non-pairing exceptions for those 9 would be quite rare. Of these 9 projects, 1 hasn't gone into production yet, 1 was cancelled for good business reasons, and 1 was an investigation not a delivery. Of the remaining 6 of those 9, all 6 went into production very successfully (although I have to admit, I didn't enjoy them all equally, dispite the success and the pairing).
Of the remaining 5 projects that didn't use pair programming as much, they did have, at nearly all times, some proportion of the team pairing - I would say averaging around half. Of these projects, 1 didn't deliver for various good reasons that I won't go into here, 1 was cancelled, again for various good reasons that I won't go into here, 1 I left before it was due to finish and I haven't heard how it's done, 2 delivered successfully.
To summarise, of the 14 projects, 8 successfully went into production. Of the remaining 6, 1 is still in progress, 1 I don't know the fate of, 4 were cancelled or didn't deliver.
hmmm. That's the big question.
It depends what you mean. I'd say pair programming didn't fail. It can be difficult to assess the real reasons why a project was cancelled or failed. As far as I know and can tell, those projects were cancelled or failed for reasons unrelated to pair programming, but of course, you'll have to take my word for it unless you were on those projects yourself - so I don't think I can prove my claim apart from using the "proof by repeated assertion" technique that I've been practicing over the years.
hmmm. Another good question for which "proof by repeated assertion" might be needed.
There were lots of factors in the success of these projects; good developers, good team and project management, test driven development, continuous integration, refactoring, etc etc. Out of all the factors that lead to success, I'm convinced that pair programming is a significant one.
I've never worked on a team that has tried pair programming and then given it up. I've heard of it happening, on a team very close to me in one case; just not experienced it myself.
I've introduced pair programming at a few clients where some people (both managers and developers) have been resistant. Some of those people have been "fully converted" and now advocate pair programming themselves. Some gave it a try but didn't take to it well, but didn't stop the rest of the team pairing. I haven't been on a project where pair programming has been abandoned.
Writing this article is (believe it or not - stupid me for not doing this sooner) the first time I've gone through all the projects I've worked on since starting to do XP/Agile and done any sort of assessment of them. I'm rather pleased that I have now. I might even do some more.