Dubroy.com/blog

I ran across an interesting post on programming.reddit called Anecdote Driven Development, or Why I Don’t Do TDD. The article focused on testing, but what I found most interesting was the part about how long a method or function should be:

I recently wrote some code for Class::Sniff which would detect “long methods” and report them as a code smell. […] Ben Tilly asked an embarrassingly obvious question: how do I know that long methods are a code smell?

I threw out the usual justifications, but he wouldn’t let up. He wanted information and he cited the excellent book Code Complete as a counter-argument. I got down my copy of this book and started reading “How Long Should A Routine Be” (page 175, second edition). The author, Steve McConnell, argues that routines should not be longer than 200 lines. Holy crud! That’s waaaaaay to long. If a routine is longer than about 20 or 30 lines, I reckon it’s time to break it up.

Regrettably, McConnell has the cheek to cite six separate studies, all of which found that longer routines were not only not correlated with a greater defect rate, but were also often cheaper to develop and easier to comprehend.

I’d never heard this before, but this is great, because it verifies what I’ve believed for a long time…

That which obscures my code is bad

Last year I wrote a post called If this is Object Calisthenics, I think I’ll stay on the couch where I argued (among other things) that making your methods as short as possible is NOT a good idea. My justification was that it just makes the code more complicated: “That which obscures my code is bad.” But this is even better…actual empirical evidence.

I don’t have a copy of Code Complete, so I did a bit more research to see if I could find the actual studies. I found a good summary here (links added by me):

McConnell cites the findings of several studies of the correlation between the size of routines and the cost and/or fault rate of routines. Some findings which favor longer routines are:

• Routine size is inversely correlated with errors, up to 200 lines of code. [Basili and Perricone, 1984]
• Larger routines (65 lines of code or more) are cheaper to develop per line of code. [Card, Church, and Agresti, 1986; Card and Glass, 1990]
• Routines with fewer than 143 source statements (including comments) had 23% more errors per line of code than larger routines. [Selby and Basili, 1991]
• Routines averaging 100 to 150 lines of code need to be changed least. [Lind and Vairavan, 1989]

Hmmm. It looks like the studies are all about 20-25 years old. I wonder if — or how — the results would apply now. I took a quick look at the papers (the ones I could get my hands on), and the programming languages used were: Fortran [Card ‘86], Pascal and Fortran [Lind ‘89], and a mix of custom languages (one being PL/1-like) and assembly [Selby ‘91].

Does anyone know of any more current results? (Greg?) It would be interesting to see if this can be shown with more modern languages. But intuitively, it makes sense. In her book Software Engineering: Theory and Practice, Joanne Atlee summarizes it nicely:

Card and Glass (1990) point out that the design complexity really involves two aspects: the complexity within each component and the complexity of the relationships among components.

By making your methods shorter, you’re just trading one kind of complexity for another.

Update: In the comments, Stephane Vaucher pointed to a much more recent study (from 2002): The Optimal Class Size for Object-Oriented Software. They point out that the conclusion that shorter methods are more error-prone is misleading, at best:

The observed phenomenon of smaller components having a higher fault density is due to an arithmetic artifact. First, note that the above conclusions were drawn based exclusively on examination of the relationship between fault density versus size […] However, by definition, if we model the relationship between any variable X and 1/X, we will get a negative association as long as the relationship between size and faults is growing at most linearly.

Another way of putting it is: short methods may have more defects per line, but they still have fewer defects overall. There may be a justification for not making methods too short, but these studies do not provide one.

The one sure thing is that the more code you write, the more bugs you will have.

Writing software is incredibly hard. Every programmer knows this. The software we write is complex, unreliable, and difficult to maintain. And this isn’t a new thing — the term “the software crisis” was coined in 1968.

The thing about software is that it’s remarkably easy to write a program that mostly works. And it’s difficult to tell the difference between a quick hack and a stable, reliable, and robust system, because the software development process produces almost no visible artifacts.

When you look at a building, it’s easy to get a quick sense of how well-built it is. Which of the two buildings below would you rather be in during a heavy storm?

Besides the program itself, the only visible artifact of the software development process is the source code. And that is only viewed by the programmers, through the tiny lens of the text editor. What if we could make the entire process more visible?

I’m thinking of visualizations along the lines of the comparison of system calls in Linux/Apache and Windows/IIS that I posted a while back. But this is just one idea. What other ways could we visualize Code Smells? (Maybe we could actually smell them!)

Aside from visualizing various aspects of the source code itself, could we show how well tested a piece of software is? We could show how many tests were run recently, what their results were, how good the code coverage is, the number of crashes encountered in the field, etc. With projectors and LCD displays being so cheap these days, there’s no reason a development team couldn’t have a few displays dedicated to these kinds of visualizations.

What do you think? Could this help improve the quality of software? What if companies openly published these kinds of things?

This week, I’m doing all my coding on a borrowed MacBook. It’s the most time I’ve ever spent doing development on a Mac. I’ve done a bit here and there on my Mac Mini, but usually I just use that for web browsing, downloading episodes of Degrassi High, and such.

Of course I needed a text editor, so I figured I’d give TextMate a try since it’s highly recommended by many Mac hackers. My first impression has been good. It’s a got a nice, simple, no-frills interface, some slick built-in themes (Espresso Libre ftw!), and the bundles come in pretty handy.

I’ve found a few small things that have thrown off my rhythm though. The regular find command (⌘-F) doesn’t do an incremental search, and hitting Enter again doesn’t bring up the next match. Yes, I know about Ctrl-S, but geez, I gave up Emacs like eons ago, and I’m just so used to typing Ctrl-F (on Windows) or ⌘-F (on the Mac) to search. And I want it to work that way in every application.

Another thing that I miss is the way the Home and End keys work on Windows: they move the cursor to the beginning and end of the line. On the Mac, they take you to the beginning and end of the file, which you can also do on Windows by hitting Ctrl-Home and Ctrl-End. I really miss the Windows behaviour, because it’s my favourite way to nuke a line or a whole section of code: whack Home, then hold down Shift and use the arrow keys to select the lines you want to kill.

Anyways, the point of this post is not to complain about TextMate, because it is a fine piece of software, and I’m sure it won’t take long for me to adapt. But this experience got me thinking about the whole experience of programming in a text editor, and made me realize that this hasn’t really changed much in 30 years.

Where’s the innovation?

In 2008, on almost every operating system, your choices for a text editor are roughly the same:

• vi, the modal editor for UNIX-loving, bearded hackers
• Emacs, the non-modal editor for LISP-loving, bearded hackers
• Some kind of WIMP-y editor, for everyone else. Sure, there are plenty of “choices” in this category, but it’s like the choice between Coke, Dr. Pepper, and root beer: they’re still all sugary, caramel-coloured beverages. TextMate, Eclipse, Visual Studio, Notepad, etc. — the actual act of editing text is almost exactly the same in all of them. These guys basically work like your standard WYSIWYG word processor, with a few extra features for coding.

Now let’s go back 30 years, to 1978. I wasn’t breathing 30 years ago, let alone coding, so I had to go to Google for a little history lesson. But as I understand it, here were your choices in 1978:

• a line editor like ed, which I’ve been told was roughly like trying to write with a pen tied to the end of a metre stick
• vi, the modal editor for UNIX-loving, bearded hackers
• Emacs, the non-modal editor for LISP-loving, bearded hackers
• Some kind of WIMP-y editor, if you were lucky enough to be working at Xerox PARC

So where’s the innovation?

At this point, you might be thinking, who cares? Emacs/vi/TextMate is good enough. The thing is, the text editor is still the primary user interface for coding. That’s why some people get so religious about their preference. It just seems weird to me that there have been so few attempts to try something truly new. And I find it hard to believe we reached the pinnacle of programming UIs in 1978.

A few ideas

Most editors are just as good for writing a blog post or screenplay as they are for writing code. But the structure of code is completely different. You rarely open up a source file and read it from beginning to end. But most programming environments seemed to be designed for that kind of workflow.

In the end, I think that’s the real kicker: most programming languages are file-based. For some reason, we seem to be so attached to coding in plain text with 80-character lines. If you drop this assumption, things start to get a bit more interesting. But that only takes us to where Smalltalk IDEs were at in the 80s.

Anyways, most of the dynamic languages aren’t inherently file-based. By that I mean that it’s not too difficult to interface with the interpreter without using text files. So that’s not a good excuse.

Here are a few things I’d love to experiment with in a programming environment:

• Better support for random access. The structure of code is more like hypertext than it is like a book.

• Richer annotations. Comments take up valuable screen space. It would be nice to be able to have more unobtrusive comments in the code. This would also allow you to do things like have a discussion thread about a section of code, link to other relevant methods, etc. Even something as simple as comments that auto-wrap to the width of the window would be a nice touch.

• Better support for looking at several sections of code at the same time. Some editors (including Emacs) allow you to split the window into several viewports. That’s a start, but it could be improved upon I think. That reminds me, I’ve been meaning to try Acme for a while.

• Tighter integration between the editor and the runtime. One example is having your editor be able to tell you “every time you’ve run this method, this variable has been of type X”. Another example is if your editor visualized code paths — maybe you could overlay a heat map on top of the source code for profiling purposes

• Explicit support for exploratory programming. When I code in Python, I like to keep an interactive console open, where I can try out little snippets of code. With a bit of tweaking (e.g., not tossing out my entire method when I make a syntax error on the last line), I could see this becoming a primary way to write code.

What do you guys think? What are your favourite programming editors/environments, and why? Any other ideas about how programming UIs could be shaken up?

I just got back from meshU, a one-day conference focused on design and development for the web. I went on a bit of a whim; the student tickets were only 30 bucks, and there were lots of interesting speakers. Well, it was a good decision — the three talks I saw were well worth the price.

(As an aside, I see that I’ve been added to Patrick Mueller’s Planet OTI aggregator. OTIers, read on! Today’s post contains at least two OTI connections.)

Avi Bryant: Turning the Tables: Moving Beyond Relational Storage

The first talk I attended was by Avi Bryant of Dabble DB fame. Avi talked about why how not to use a RDBMS. There’s been a lot of interest lately in alternatives to the relational database — CouchDB, Amazon SimpleDB, and Google BigTable being the most famous examples.

Avi mentioned that there are two main cases where it’s advantageous to have something other than a relational database. First, if your dataset is massive, as with Google. In this case, it’s just not feasible to use a RDMS. The second case is if your dataset is really just many small, independent datasets, in which case it might be simpler and more scalable to use an alternative technique.

At the end of the talk, Avi demoed MagLev, which is a Ruby interpreter built on top of a Smalltalk VM (OTI connection #1). This was really cool, not just because it’s Ruby running on top of Smalltalk. It was cool because MagLev can transparently persist heap objects to disk, and distribute them to other VMs, either locally or running on other machines. For example, you can define a function in one VM, and then call it from another VM. Wow. As far as I know this was the first time MagLev has been shown in public, but there’s going to be a talk at RailsConf 2008.

Daniel Burka: Iterative Design Strategies

The second talk I attended was by Daniel Burka (OTIers probably know Daniel’s brother Peter). Daniel is the lead designer for Digg and a co-founder of Pownce. Daniel gave a great talk on iterative design strategies. You can check out the slides here.

It was really interesting to hear some of Daniel’s stories from Digg. He said that one of the times that they redesigned the comments, they were getting a lot of negative feedback from users. But they also noticed that under the new system, stories were getting more comments than ever before. So although there was a vocal minority who weren’t happy with the design, it was an overall success. The moral of the story is that you need to look at the implicit feedback as much as the explicit feedback.

Another thing I took away from Daniel’s talk was that I should read How Buildings Learn by Stewart Brand. I’ve had this recommended to me enough times that I’ve finally decided to buy it.

John Resig: Building Interactive Prototypes with jQuery

John Resig is the creator of jQuery, “the write less, do more Javascript library”. This talk was pretty timely for me. I just started using jQuery a few weeks ago for a Firefox extension that I’m writing, and I’m pretty much in love with it. So it was practically guaranteed that I would like this talk, since it was further demonstration of all that is awesome about jQuery. I did learn one new thing from the talk — I’d never heard of the jQuery Form Plugin before, and it is really cool as well.

I’m not sure what more I can say about this one. If you’re a web developer, or a designer who codes a little, you should seriously check jQuery out.

So that was my day. $30 well spent at meshU. Thanks to the organizers: Mark, Mathew, Rob, and Stuart.

Via Raganwald, I saw this post by Andrew Birnstock: Perfecting OO’s Small Classes and Short Methods. The post is a summary of an essay by Jeff Bay called Object Calisthenics, from the new Pragmatic Programmers book The ThoughtWorks Anthology.

“Object Calisthenics” is supposedly an exercise to get you to write better object-oriented code. Reading through the suggestions, I couldn’t decide if the article was serious or not. From Andrew’s summary:

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.

2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.

3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

From what I can tell, this really is serious. These are supposed to be the object-oriented equivalent of chin-ups, designed to whip you into shape to write better OO code.

This strikes me as so bogus, I can’t even begin to describe it.

I’m not against OO: I’m a huge fan of Smalltalk, and I cut my programming teeth at one of the oldest object-oriented development shops. In fact, I keep thinking of something that Steve Northover used to say to me when I was on my first work term at OTI:

“That which obscures my code is bad.”

If you’ve ever seen a large body of code that adheres to The One True OO Style^TM — like say, Smalltalk class libraries — you’ll understand that almost every step you take towards “true OO” is just another way of obscuring the meaning of your code. If you break your code up into 10 different methods, then that’s 10 different places I have to look to figure out what is going on. You’re just writing spaghetti code by a different name. If you’re building a very large library, then maybe, just maybe, the additional flexibility is worth it.

I think Paul Graham sums it up best in his essay Why Arc Isn’t Especially Object-Oriented:

My own feeling is that object-oriented programming is a useful technique in some cases, but it isn’t something that has to pervade every program you write. You should be able to define new types, but you shouldn’t have to express every program as the definition of new types.

Despite the fact that there is little evidence that using multiple monitors will make a programmer substantially more productive, many coders will subjectively claim that they can’t live without a second display. Why do people feel so strongly about the issue? And is it possible that the perception of efficiency is just as important as real efficiency?

The Scientific Angle

A few months ago, I experimented for a while with a dual-monitor setup. My main computer is a 14″ Thinkpad, and I connected to either a 24″ widescreen LCD (in my lab at U of T) or my 20″ widescreen at home. After a while, I found that I wasn’t really seeing the “obvious benefits” that some people rave about.

I had heard about studies that supposedly proved that you can be up to 50% more productive by adding a second display. In my post Multiple-Monitor Productivity: Fact or Fiction? I looked at these studies, and concluded that in some isolated tasks — like cutting and pasting, or working with a large spreadsheet — you can see a significant benefit if you add a second monitor. But for most programming tasks, the benefits are going to be minimal (but still there).

After another study was recently published by some researchers at the University of Utah, Jeff Atwood took the time to put together a summary of the studies of all the studies we could find — a “a one-stop-shop for research data supporting the idea that, yes, having more display space would in fact make you more productive”. In case you couldn’t tell, Jeff is a big fan of multi-monitor setups:

I have three monitors at home and at work. I’m what you might call a true believer. I’m always looking for ammunition for fellow developers to claim those second (and maybe even third) monitors that are rightfully theirs under the Programmer’s Bill of Rights.

The Subjective Claims

If you read the comments on Jeff’s article, you’ll see that, despite the lack of empirical evidence that programming tasks will significantly benefit from multiple monitors, many programmers are pretty attached to idea:

• Leon Mergen: “People who claim there is no benefit (or little benefit) in programming with multiple monitors, obviously haven’t really expercienced it.”

• SB: “Have you ever actually used (like, for many months/years) multiple LCDs? … I don’t know how a programmer could go from multi-LCD setup to single display & not claim some, even if minor, productivity dropoff.”

• Brian: “I personally find that in my case having a second monitor is ALWAYS more convenient and increases productivity.”

This morning I finally ran across a paper which talks about these subjective benefits. Jonathan Grudin’s Partitioning Digital Worlds: Focal and Peripheral Awareness in Multiple Monitor Use has some interesting insights. Grudin interviewed 18 people who used multiple-monitor setups, and came to the conclusion that:

A second monitor improves efficiency in ways that are difficult to measure yet can have substantial subjective benefit.

One of his interesting observations was that it’s not just about the screen real-estate, it’s also about the partitioning (emphasis mine):

A strong demonstration that multiple monitors can be more about partitioning than about increasing space is provided by the two participants who dock their constantly synchronizing palmtop computers next to their desktop monitors. One keeps his calendar visible on the palmtop, the other keeps email visible. The increase in space provided by the palmtop display is not significant and there is no information on the palmtop that is not available to the desktop computer. The value is in having instant access to a resource in a known location in peripheral vision.

This the same conclusion that Jeff made after seeing the results of a small, informal multiple monitor productivity study: two monitors is better than one large monitor.

Another interesting finding in Grudin’s paper was just how much people hate to use the taskbar or Alt-Tab to switch windows:

Given the ease of minimizing and restoring windows, why bother with a second monitor? Repeatedly, people indicated that they considered it a relief not to have to use buttons, “escaping from the need to Alt-Tab.” The ability to avoid a few keystrokes is welcomed with great subjective enthusiasm, although it might be difficult to objectively measure an efficiency gain.

Perception vs. Reality

To me, this really captures what the argument’s all about. It’s not necessarily about actually being more productive — perceived productivity is just as important. It reminds me of Bruce Tognazzini’s famous finding on the relative speed of the mouse vs. the keyboard:

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.

In my experience, many people who love multiple monitors are the same people who are obsessed with knowing every keyboard shortcut in their text editor, and who can’t live without mouse gestures in Firefox.

Don’t get me wrong. Even if the benefits are unproven, minimal, or even non-existent (as in the mouse vs. keyboard case) — it doesn’t really matter. The most important thing is that you, as a programmer, have the tools that you want to do your job. I definitely don’t question the productivity benefits of being happy.

A couple weeks ago, I trekked through another Toronto snowstorm all the way up to the Canadian Film Centre. Normally I’m a downtown snob and don’t go north of Bloor, but I made an exception this time because my friend Geneviève was demoing a project at the CFC Media Lab.

A Hierarchy of Needs for Design

While I was there, I happened across a copy of Universal Principles of Design. It’s a really cool book which describes 100 design principles: from general-purpose concepts like Ockham’s Razor and the 80/20 rule, to specific techniques like Iconic Representation (”the use of pictorial to improve the recognition and recall of signs and controls”). It’s kind of like a universal set of design patterns.

I only had a chance to flip through the book for a few minutes, but I really liked what I read. And Donald Norman recommends it, for what it’s worth.

One of the principles that I really liked was Hierarchy of Needs. Inspired by Abraham Maslow’s famous psychology theory, the authors proposed a Hierarchy of Needs for design:

A design must serve the low-level needs (e.g., it must function), before the higher-level needs, such as creativity, can begin to be addressed. Good designs follow the hierarchy of needs principle, whereas poor designs may attempt to meet needs from the various levels without building on the lower levels of the hierarchy first.

What about the code?

This got me thinking about coding. As a programmer, you are designing not only the product itself, but also the code. For the end product (the software that you are producing) the Design Hierarchy of Needs can be applied. But what about the code? What would a hierarchy of needs for code look like? Here’s what I came up with, but I’d like to hear what everbody else thinks.

Keep in mind that this is a hierarchy of importance, with the lower levels being more important. It’s most definitely not a sequence of steps.

• Functionality: If your code doesn’t work, there’s no point making it in optimizing that inner loop, or refactoring it to be infinitely flexible.
• Reliability: Any software developer worth his salt knows that there’s a big difference between code that “works”, and code that is ready to be shipped. After your code is functional, you need to make sure that it is reliable. Run it through your unit tests, run it overnight, run it on grandma’s computer.
• Maintainability: Can other people understand the code? Can you understand the code? When bugs are discovered, you need to be able to fix a bug and be confident that you won’t be causing more bugs in the process.
• Extensibility: Is your code adaptable to meet new requirements? If your code is extensible, you will be able to grow and adapt your software to meet the changing needs of your customers. If not, you might have to throw it out and start from scratch.
• Elegance & Efficiency: If you are sure you are meeting the other levels of need, then and only then should you worry about making your code fast and beautiful. Unfortunately, many people get hung up on this level instead of focusing on the more basic needs.

What do you guys think? Anything you’d change about it?

Related: Andrew McKinlay wrote about A Programming Hierarchy of Needs, and Oliver Steele proposed The Programmer’s Food Pyramid. Kathy Sierra, whose blog Creating Passionate Users I sadly miss, also tackled the user hierarchy of needs, and asked What comes after usability?

It seems to be accepted wisdom, especially in programming circles, that more screen real estate makes you more productive. I’ve heard claims that you can increase your productivity by up to 50% just by adding a second display. After four months of using a big-ass LCD for development, I recently switched back to a 14″ laptop screen. And you know what? I don’t feel like I’ve missed a stride. So I decided to take at the facts behind the claim that more screen real estate makes you more productive.

The Claims

Jeff Atwood writes an excellent blog on programming and human factors, and he is an unabashed fan of multiple monitors. In his post Multiple Monitors and Productivity, he writes that using multiple monitors “is really a no-brainer for any developer who values his or her time.” He stresses the fact that it’s not purely about screen real estate — he recommends using two or three smaller displays rather than one huge one. The reason is that with bigger displays, the window management actually gets more complicated. This is what Jeff calls The Large Display Paradox.

Joel Spolsky is another well-known champion of a multiple-monitor setup for programmers. In The Joel Test: 12 Steps to Better Code, he advocates giving your programmers the best tools money can buy. And according to Joel, this means multiple monitors:

Debugging GUI code with a single monitor system is painful if not impossible. If you’re writing GUI code, two monitors will make things much easier.

It’s not just Jeff and Joel. Take a look at the discussion thread on the Slashdot article Multiple Monitors and Productivity, or Ask Metafilter: Where can I find case studies on productivity gains from dual monitors for developers?. Even the New York Times published an article on The Virtues of a Second Screen:

Survey after survey shows that whether you measure your productivity in facts researched, alien spaceships vaporized, or articles written, adding an extra monitor will give your output a considerable boost — 20 percent to 30 percent, according to a survey by Jon Peddie Research.

My Doubts

I definitely agree that for some tasks, it’s really helpful to have some extra screen real estate. If you’re a graphic designer, you probably don’t want to be peering at your poster layout through a 13″ keyhole. But for programmers, how many tasks actually benefit from more screen space? If I need to look at API documentation while I’m coding, I have no problem switching to another window to start writing my code. And on my 14″ widescreen laptop screen, there’s more than enough room to compare two pieces of code side-by-side:

In the end, I think it’s a case of micro-optimization. There are lots of small tasks that can be made slightly more efficient if you have a second monitor. But these tasks are not the real bottlenecks to programmer productivity. If you were a writer, would you expect to increase your productivity if you could avoid changing sheets of paper in your typewriter?

The Evidence

So what about the actual hard evidence? Let’s take a look at the studies that supposedly show this increase in productivity.

An article on the Microsoft Research site entitled Two Screens Are Better Than One claims that researchers “found a tool that can increase your productivity by 9 to 50 percent and make your work day easier.” Since the article didn’t actually cite the studies, I had to do a little digging. I found a paper called Toward Characterizing the Productivity Benefits of Very Large Displays which found a 9% improvement in a series of tasks that involved cutting-and-pasting and scanning a document for information.

Not bad, actually. A 9% improvement in tasks that are highly applicable to programming. But on the other hand, how much time do you actually spend in a typical day doing these kinds of tasks? And how much time do you spend typing, whiteboarding, talking to your co-workers, and just staring into the distance and thinking about a problem? Let’s be generous and assume that you spend a quarter of your day performing tasks like in the study. So by using a bigger display, you might be able to improve your productivity by about 2.5%. Remember, studies have shown more that a rock-star coder can be an order of magnitude more productive than your average joe ¹. Do you think these guys are more productive because they can cut and paste faster?

Okay, so we know where they got the 9%. What about the 50%? “Further studies showed even greater increases - at times up to 50 percent for tasks such as cutting and pasting.” Aha, there it is again. Cutting and pasting. Well, if your job includes 7.5 hours a day of cutting and pasting, then maybe you can cut that down to 5. You might make it a bit longer before you stab yourself in the eye due to the mind-numbing boredom.

Another study I’ve seen cited a few times is the The 30 inch Apple Cinema HD display productivity benchmark by Pfeiffer Consulting. This study showed that a 30″ display made users significantly more productive than a 17″ display. But the tasks were mostly designer centric, except for a task that involved manipulating a large spreadsheet, and one of combining several Word documents into another document (cutting and pasting again!).

Conclusion

After looking at the studies, I think it’s fair to say that some tasks can be made significantly faster if you have more screen real estate. On the other hand, I think it’s clear that most programmers are not going to be 50% more productive over the course of a day just by getting a second monitor. The tasks that can be improved are not the bottleneck to programmer productivity.

On the other hand, if you just can’t live without your dual- or triple-monitor setup, fine! I definitely agree that it can be nice sometimes. I personally find it difficult to manage the extra screen real estate, but that’s just me. If you’re a developer and you want a dual-monitor setup, then that should be reason enough for your boss to buy one. As Joel says:

Top notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.

Just don’t think that by adding a second monitor, you’ll start coding circles around the guy on his ThinkPad.

[1]: The fabled “10 fold difference” in programmer productivity is a discussion for another day. If you want to dive in, you could start with Jeff Atwood’s post on Skill Disparities in Programming.

I’ve just started reading Harold Thimbleby’s Press On: Principles of Interaction Programming, kindly lent to me by Greg Wilson. I’ve just finished reading the introduction, but one thing stands out to me already. Maybe you noticed it already: the subtitle of the book is Principles of Interaction Programming.

What the hell is Interaction Programming?

I don’t know about you, but until I picked up this book, I’d never heard the term interaction programming. As far as I can tell, it’s a term that Thimbleby made up. According to him:

Interaction programmers are computer scientists using their specialist skills to design, analyze and program interactive devices used by people.

I really like this term because it captures the fact that the interaction is inextricably linked with the internals of the system. We already have lots of terms to describe the study of the interaction between people and computers (human-computer interaction, usability, interaction design, and user experience, just to name a few). But these terms all seem to imply that you have a system and you have a user, and all you need to do is design the interaction between the two. Thimbleby’s view is that these terms are primarily concerned with “what things look and feel like, rather than how they work inside.” Using the term interaction programming challenges the view that the interface is created by designers and the functionality is implemented by programmers.

Why interaction programming matters

I’m definitely not arguing that there is anything wrong with interaction design, user experience, or choose-your-preferred term. There are certainly lots of talented people out there who play a very important part in developing usable interactive sytems without have intimate knowledge of the implementation details. But there are also many programmers who have the skills and desire to make the interaction a concern in every step of the development (see Jeff Atwood, 37 Signals, etc.).

It seems to be well accepted now that we should consider usability during all phases of a product’s development, but Thimbleby stresses that interaction programming should also be an integral part of the process:

Much of the initiative for better design can come from clear engineering creativity, knowledge, and perspectives based on sound computer science principles. […] Programmers can come up with solutions that would have escaped users or designers with limited technical knowledge; programmers can be more creative and more central in all areas of interaction design than anyone suspected.

Ich bin ein Interaction Programmer

I’ve always found it hard to describe what I’m interested in. I love coding, but I also care a lot about how people interact with computers. Yet I wouldn’t consider myself to be designer, since I don’t have the background or experience. Thanks to Harold Thimbleby, now I can express it pretty well: I’m an interaction programmer.

Leah Culver, the lead developer of Pownce, posted the slide deck from her talk at FOWA 2007: Pownce - Lessons learned. I learned a few interesting things about Pownce:

1. It’s build on Django.

2. They use Amazon S3.

3. Their desktop client is built using AIR.

By a freaky coincidence, these points happen to correspond to some links I wanted to share with y’all.

The Django Book

The Django Book, is a free, online Django reference. The book is still in beta (yes, they apparently do that for books now), and they’ve got a cool UI for commenting on specific paragraphs, and viewing those comments. Here’s what Chapter 1 looks like:

To view comments for a section, or to add a new comment, you click on the corresponding yellow dialog bubble on the left. For sections that don’t have any comments yet, a subtle, translucent bubble appears when you mouse over the margin.

Amazon S3 Service Level Agreement

Amazon S3 now has a service level agreement, guaranteeing 99.9% uptime. Lots of people have been raving about the Amazon Web Services arsenal, especially S3 (storage) and the Amazon Elastic Compute Cloud (aka EC2). It should be even more attractive to developers now that they have a guarantee.

AIR

Okay, this one’s a bit of a stretch.

Adobe AIR (Adobe Integrated Runtime) is a runtime environment for desktop applications based on Flash, HTML, and Ajax. It’s direct competitor to Mozilla’s WebRunner. If you’re interested in WebRunner and you live in Toronto, you might want to check out the Free Software and Open-Source Symposium at Seneca College later this month. Mark Finkle of the Mozilla Corporation will be doing a workshop on desktop-enabling web apps.