I found a blog post about pair programming. The post itself wasn’t anything special (talking about how the names Pair Programming and especially Extreme Programming might scare away conservative managers). But I found the comments interesting, and I could really sympathise with several of the commenters who do not like pair programming.

I have tried pair programming a few times. It works (from my point of view) when both of us are roughly on the same level, and only when there is a problem that clearly needs more than one pair of eyes, because it’s risky or complicated. It’s worked well for some tricky SQL queries, as well as for a complex web page (a mixture of UpdatePanels, Repeaters, and javascript with embedded C# code blocks).

If the other developer is clearly more junior than me, pair programming kind of works as a method for knowledge sharing. I could get the job done noticeably faster on my own, but then we’d need additional time for handing over or explaining what was done, so the two might as well get done together. In those cases pair programming should be considered as a teaching/learning method rather than as a programming method.

But I do not like to do it for general run-of-the-mill coding – there has to be a specific reason for it.

Saying you should pair program “just because” is an inflexible approach, sort of like saying “hammer works for nearly any purpose”.

I do not need another person to help me focus (which is one of the advantages often mentioned). On the contrary, if someone is looking over my shoulder while I code, it really distracts me. Whereas if I am looking over someone else’s shoulder, I get incredibly frustrated by how inefficiently they work – because almost always they will be inefficient compared to my standards. They don’t know their tools, they don’t use keyboard shortcuts, they type slowly and carelessly. And I sit there and wait and sigh quietly.

I imagine I would enjoy pairing with an experienced and efficient programmer, but there aren’t any where I work – there’s no one more experienced than me. This is actually the greatest drawback of this job. I have no one to learn from; I can only learn by doing and by reading, and that’s only going to take me that far. I am a big fish in a small pond, whereas I would much rather be a tadpole in a big pond.

I like working with good tools. Work is more fun when I feel that the tools I have make work go faster and more smoothly, and give better results. It’s important to me that the kitchen knives I use have a good edge, that the chopping board is solid, that my pruners are sharp and the cleaning cloths are absorbent. I do not understand how people can make do with dull knives and cheap plastic chopping boards.

Likewise I like to work with good software. I need good software. I don’t understand how people can stand having Notepad as their text editor, not because they are uninformed and believe that Notepad is all there is, but because they can’t be bothered.

My two latest favourites are Selenium and SourceMonitor.

Selenium is a tool for testing web applications. Very easy to get started with, powerful, and flexible.

It’s got a “recording” module which records your actions in Firefox – what pages you open, what links you click, what text you type – and also lets you easily specify test conditions such as “verify that, after I’ve clicked all these things, this particular text is present on the page. You can save the tests in html format, and the file structure is so simple that anyone can edit and extend the tests. But you can also export the tests in your favourite programming language, or, if you prefer, write the tests from scratch in that language.

I used the Firefox addon to record the first tests and exported them to C#, and then went on writing the rest of the tests directly in C#. The whole process was very straightforward. We now have about 45 automated tests for core high-level functionality.

Plus, it’s free!

SourceMonitor is a tool for estimating code complexity. It is also free.

I’m very aware that our code needs refactoring, because large parts of it are so complex that they are effectively unmaintainable. But because everything needs refactoring, and I’m still not familiar with all of the code (because it is so hard to read), I don’t know where to start.

SourceMonitor has been very helpful for finding the hot spots, for prioritising the files and methods that are in most urgent need of cleanup. It quickly shows which files and methods are largest or seem most complex. It can sort them by size, complexity, levels of nesting, number of calls out to other methods, etc. This can be done for the project as a whole, or for a particular file. SourceMonitor also saves the results of each analysis run, so you can see how things change over time. I like seeing measurable progress, so this feature really appeals to me. There is something immensely satisfying in knowing that I have just reduced the size of our code base by 400 lines and at the same time made it better.

Before choosing SourceMonitor I also looked at FxCop and NDepend, but both were too complex for our current needs, and did too much. We’re nowhere near the level of control that these two applications provide, such as enforcing naming rules. I expect that I’ll try them again in half a year’s time. I might have chosen NDepend anyway, because the demos look so slick, but it costs money, and given how little of its functionality we will use for now, I would find it hard to justify the cost.

FxCop is free just like SourceMonitor, and I did try it out, but it was not particularly easy to get started with. The main hurdle was that FxCop needs compiled assemblies to work with, which makes it very difficult to use with ASP.NET web sites. SourceMonitor analyzes source code instead. I also found SourceMonitor’s sparse interface much more comfortable on the eyes and the brain than FxCop’s flood of messages.

Yesterday and the day before were the two most boring days of coding I have ever experienced. I hope I never have to do anything like this again…

We’re reviewing our database access code and decided to switch from executing plain SQL statements and stored procs, to using parameterised queries. In practice this meant replacing a method that built SQL statements as strings, with one that created SQL commands, and replacing all calls to the previous method with calls to the new one.

Because the new method returns a different data type, we couldn’t automate this. Each method call had to be changed manually.

Unfortunately the various previous developers did not believe in having a separate data access layer, so there is data access code everywhere. And I mean literally everywhere: every single aspx file has at least one, and often up to 10 database calls.

This led to a sum total of exactly 879 method calls that had to be changed. Manually. One by one. It took me most of Thursday and half of Friday to slog through them all. That’s more than 80 method calls per hour, or one every 45 seconds.

The only good thing about this (apart from making the application more secure) is that we are now even more convinced that we need to refactor this beast into a more manageable shape, and sooner rather than later.

Quite randomly in the middle of a session, Visual Studio went bonkers and started saying “No files were found to look in. Find was stopped in progress.” whenever I tried to search for anything.

Visual Studio being what it is (a buggy but widely used tool), I went to Google. And Google delivered: the solution is to press Ctrl + Scroll Lock. Huh? As a fix that’s on par with spitting over your left shoulder on a Thursday with a full moon.

And if that wasn’t weird enough, the bug has existed in the last 3 (three) versions of Visual Studio: 2003 and 2005 and 2008 (which we use). And no one at MS has bothered to fix it.

I’ve been at my new job almost two months now, and by now I feel like I’ve been doing it for a long time. I think much of that is due to how small and informal the team is, and how tightly involved I am. I am half the development team. My previous job (at a big bank) was framed and structured by all sorts of procedures, automated processes, approvals, systems, and schedules. Here I just sit down and do whatever I decide needs to be done.

On the one hand this leads to a lot of freedom and independence and responsibility. Our speed of response is stunning: if an urgent bug is found, the fix can be in production minutes after we’ve tested the fix.

But there are downsides, too. There can be confusion and lack of direction, because there was (until recently) no clear process in place for prioritising requirements or for scheduling and planning releases. There is tedious manual work which is easy to get wrong, because the deployment process is not automated. And so on.

The good thing is that it’s all changing. The other half of the development team is almost as new to the firm as I am (although he has worked there a few summers, he only started full-time a couple of months before me). Since we’re both new, we have no emotional investment in the current processes and systems. And we’re planning to change just about everything.

A new source control system is coming soon (SVN instead of VSS). A new development process is already being tried out (Scrum-inspired). Development tools to improve code quality (Resharper) have been introduced. Automated unit tests are slowly being put in place, and automated acceptance tests are being discussed. Automated build and deployment will be coming next.

My last job was, in a way, the perfect preparation for this. Had I come straight from school, or from another unstructured chaos-inspired place, I might not even know that things could be done differently, and we would have muddled on, just like the developers before us seem to have done. The gears would grind slower and slower, but we would probably be able to keep moving for several more years.

But I have seen the other end of the scale, and I know – not theoretically but from my own experience – the benefits of an automated build process, deployment scripts, code reviews etc. I know how much easier life could be. I know what we should be aiming for, and even though the ideal setup here will be very different from what we had there, I know how to figure out the way to get there.

If any of my previous colleagues are reading this, I’d like to send them a big thank-you for preparing me for this! You all thought I was working for the bank, and in reality you were all working on training me.

An approximate excerpt from a CV, from someone applying for a developer job at the company I work for:

I program in my spare time. [...] I also write programs to help me with online games. For example I wrote a program in Java to help me play NukeZone. The program simulates IE and gives me an overview of the whole economy in the game world, which gives me an advantage over all other players. It uses proxy servers to avoid being detected so my account does not get cancelled. All the data are saved in a MySQL database and displayed on the screen.

Hmm. You cheat in games, and you’re boasting about it. And you think this would somehow help your chances of getting hired?

Think again.

A very bad bug was accidentally introduced into one Linux distribution two years ago. (Bruce Schneier has a brief overview with links to more.)

The bug itself is interesting enough. But far more interesting is how it got there. Basically, a Debian developer found what to him looked like less-than-perfectly clean code in the OpenSSL library. A tool for checking code quality complained about a specific line of code. The developer wondered if he could remove that line, asked some people, got what he thought was approval, and decided to go ahead. It turned out that he hadn’t really understood what he was doing, and no one else noticed that what he removed was a very crucial step.

All sorts of improvements to the development and code review process are being discussed, and lots of finger-pointing is going on. But the root of the issue is that someone wrote non-obvious code and didn’t comment it. A developer wrote code with no thought for those who might be reading or maintaining it. It would have taken them 5 seconds to add a one-line comment confirming that, yes, they did indeed mean to put this unorthodox line here.

I’m not the first commenter to say this. I just feel really strongly about writing maintainable code!

(This is my last post about the Wordpress migration, I promise!)

I liked Wordpress better than Movable Type as soon as I’d installed it, and my opinion hasn’t changed. If you’re using MT and haven’t tried WP, do try it out!

The only advantage of MT that I have noticed thus far is that it is possible to manage several blogs via one control panel. But on the other hand most settings and templates are blog-specific anyway, so I’m not sure how much time that actually saves (apart from software upgrades).

Just about every part of WP is more user-friendly than the MT equivalent. The control panel is better designed and easier to navigate. The templates are more transparent and much easier to work with. Instead of MT’s strange tags (of which there are two flavours and I could never remember what the difference was) WP uses normal php functions.

Wordpress is also more feature-rich and more flexible. I can create static pages in addition to blog posts, add a list of links, easily switch between themes, add direct “edit this” links to individual posts, etc. And from a developer point of view, the WP functions give me more control with less work (mostly because they have many more parameters) than the MT tags.

Wordpress makes tinkering a lot more convenient because pages are served dynamically. MT on the other hand pre-builds and saves all pages, so each template change leads to a full rebuild of all the affected pages. With 600+ blog posts, the rebuild caused by a change to the main template takes long enough to make me really reluctant to change things. (And there is no option to rebuild just one post as a test case.)

The documentation for WP is an order of magnitude better than that for MT. Compare: the MTCategories tag vs the wp_list_categories function.

My initial plan was to use an existing theme for this blog, perhaps only changing a few fonts and colours. I browsed a bunch of themes, downloaded half a dozen, and tried them out. When I had picked the few that seemed most promising, I took a look at the code of each one to see which one would be easiest to modify. The Wordpress template structure turned out to be so clear and transparent and the documentation so helpful that I ended up writing my own theme, using the existing themes only as a source of ideas and to get an idea of what functions were available. And I did this when I had no experience of Wordpress, whereas I never got comfortable enough with MT to write a theme from scratch, even after having used it for over two years.

So I got a nice exercise in web design, learning PHP and CSS, both of which I’d touched before but not really used much. Now I can write passable PHP code and do some pretty nifty things with CSS. Hmm, perhaps I could find a way to squeeze in some javascript here, too?

I also had the pleasure to use the Firefox Web Developer extension. A very nice tool, so good that it’s worth downloading Firefox just to get that extension.

The Best Software Writing I is, well, a collection of good writing about software. Edited by Joel Spolsky, who is quite a good software writer himself.

The book covers a wide range of topics – from the design of social software to how to hire developers. However they all tend towards the “peopleware” side of things: the interaction between humans and software, rather than the technical minutiae of writing code. The selection has clearly not been guided by any sort of overarching theme or purpose, but rather by what Joel is interested in.

And that, I think, is the greatest weakness of the book: an unclear aim. Joel claims on the back cover that “the goal of this book is to encourage better writing about software by highlighting some of the best writing of the year”. That’s an admirable goal, but it leads to a book that’s aimed at everyone and no one in particular. It’s even unclear whether the book is mostly meant for a technical or non-technical audience. Almost all of the essays assume some familiarity with software development, although not at a very technical level – a technically-minded non-developer wouldn’t have any difficulty. And yet there are footnotes explaining basic concepts in idiotic terms: “Dev = developer = an actual computer programmer”. Huh?

Some reviewers disagree, and mean that the book’s greatest weakness is that you have to pay for it, while most (or possibly all) of the material can be found online for free, including Joel’s introduction. But I like the feel of a book in my hands, and I also like to have a book in my bookshelf so it reminds me to re-read it occasionally. So even though I’d read several of the essays and blog entries before, I chose to buy the book rather than look for the rest online.

The quality of the essays varies. Some were worth reading once, and I’ll skip them the next time. There was a bit too much Eric Sink for my taste (come on Joel, three essays by Eric and only one by Paul Graham? What were you thinking?) and I really don’t think that why the lucky stiff is an example of good software writing. On the other hand, A Group Is Its Own Worst Enemy by Clay Shirky is so good that it’s almost worth buying the book just to read this one essay.

Because the book was written with no one in particular in mind, I’m not really sure who I’d recommend it to. The most likely audience would be technically-minded people interested in the human factors of software development. But the contents of this book aren’t new, the thoughts aren’t new, so someone who’s interested in the field will most likely have read these or similar materials already. Worth picking up if you haven’t.

Amazon UK, Amazon US.

Two interesting blog posts about programmers and their preferences.

Here’s one that explains the fundamental difference between (most) programmers and (most) managers:

So here’s my theory: Managers must work shallow and wide, while programmers must work narrow and deep. People who are naturally tuned to one particular method of work will not only enjoy their jobs a lot more, but be better at them. I’m a deep guy, I should be doing deep work.

I didn’t say it was a particularly insightful theory.

It may not be an insightful theory but it certainly strikes a chord with me. I’ve said many times to both to my current manager and the two previous ones that I have no aspirations whatsoever to move up the traditional career ladder that inevitably leads to managing people. In fact if I was forced to I’m pretty sure I’d rather quit. Wide vs. deep is not the only reason for this preference but is certainly a big part.

The other talks about the role that personal preferences play in technological choices, and about why you need to know your audience before you can tell them what they should do.

When someone tells you “you need better tools: try Lisp”, ask “what about Lisp do you think would help me?” If they start listing reasons without first trying to understand who you are, may I say there’s a problem.

This is something I have encountered many times. People who recommend me some music or other, and when I ask them why they think I would like it, their only reason is “because this band is great” or “well I just think you would”. Book reviews that effectively say “everyone will like this book” or “best book of the year”. Of course they may sometimes be right, but more often it’s just a sign of sloppy thinking.