Dubroy.com/blog

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.

I recently ran across a post by Brendan Eich (he of Javascript fame) entitled Threads Suck, in which he talks about support for concurrency in future versions of Javascript.

Speaking as someone who has a few years’ experience with serious multithreaded code — I’m talking dozens of threads manipulating several gigs of shared data — I agree with his assessment. Multithreaded programming is hard. It’s the quantum mechanics of programming. The simple act of observing your program will cause its behaviour to change inexplicably (see Heisenbug, Schroedinbug).

This is more relevant now than ever because it appears that Moore’s Law is coming to and end, and that the future is multiple processors with multiple cores. In other words, if you want your application to run faster, you gotta go concurrent.

So, that puts us in a bit of a pickle. The future is in concurrent programming, but we’re really bad it. So either all the programmers in the world need to get a lot smarter, or we need to find a better way to do write concurrent programs. It turns out there is a better way to write concurrent programs…which leads us to Erlang.

Erlang is a functional programming language invented at Ericsson and released as open source in 1998. Instead of multiple threads manipulating shared state, Erlang supports message-passing concurrency. Why is this good? Joe Armstrong explains in What’s all this fuss about Erlang?

In message passing concurrency, we say that there is no shared state. All computations are done in processes and the ONLY way to exchange data is through asynchronous message passing.

Erlang Has No Mutable Data Structures (Not quite true, but true enough).

No Mutable Data Structures = No Locks

No Mutable Data Structures = Easy to parallelize

Erlang has been getting a lot of buzz recently. Some people are even calling it the next Java. As much as I’m intrigued by Erlang, I have to say I’m really skeptical that a functional programming language will become “the next Java”. But Java was Smalltalk gussied up in C++ clothing…what will an “Erlang for the masses” look like?

But even if Erlang itself doesn’t become hugely popular, many of its features may eventually find their way into more mainstream languages. Stackless Python and Candygram are two examples in the Python world. Either way, it seems like we’re in for a major change in the way we write our code.

I’m usually annoyed by the fact that the Windows terminal application uses rectangular selection, rather than the standard line-based selection. The problem I normally run into is when I try to cut and paste a line that wraps in the terminal window:

So you end up with a bunch of extra line breaks in the text when you paste it. I see how this could be useful if you are cutting and pasting columns of text, but I personally find that it happens so rarely that it’s not worth the pain that rectangular selection causes me most of the time.

But — JOY! — I’ve found a cool scenario where it does work really well for me. When I’m doing Python development (have I mentioned that I’m in love with Python these days?), I keep two terminal windows open: one for launching my application, and another one which is running the Python console, which I use as a sandbox to quickly test out snippets of code. It turns out that rectangular selection comes in really handy for moving working code from the Python console into my text editor, like this:

The rectangular selection turns out to be a handy way to omit the “>>>” that begins every line in the Python console. I still have a problem with line breaks, but luckily Python code rarely runs over 80 characters. Now if only there were a way to get it to automatically ignore the syntax errors…

The other day I installed some software from Microsoft Research, and for some weird reason, I decided to read the EULA. I found this gem (which, after Googling, seems to be a pretty common phrase in these things):

You may use any information in intangible form that you remember after accessing the Software.

Oh really?!? I can?? Gee whiz, thanks, guys. “Ya know, under normal circumstances, we’d wipe your memory, but what the hell, we’re in a good mood today — you can keep it.”

I know these kinds of ridiculous claims in EULAs aren’t a new thing, and Microsoft’s licenses are probably no worse than many other big software companies. As I understand it, these click-though (aka clickwrap) licenses — if they are even enforceable — are subject to standard contract law. Still, it seems to me that it shouldn’t be legal to draft a contract which denies or grants privileges which are already protected by law.

The intellectual property situation in software development is getting scary. Jeff Atwood wrote a good post not too long ago called The Coming Software Patent Apocalypse. Software patents are actually scarier than the ridiculous EULAs, because you can infringe a patent by complete accident. Unlike copyright, patent protects against independent invention — in other words, you can infringe on a patent even if you can prove that you had absolutely no knowledge of the patented invention.

Since the number of (US) software patents seems to be growing exponentially, it’s really becoming a minefield for small developers. Many people have said that it’s impossible to write software without infringing on a number of patents. Linus Torvalds has even said that the only realistic approach is to bury your head in the sand.

If you’re interested in the topic, I definitely recommend reading A New View of Intellectual Property and Software. It’s a bit dated now (published in ‘96), but it’s a great summary of the problems with existing IP laws related software, and has some interesting suggestions about how to fix things. One of the authors, Pamela Samuelson, also recently published a proposal for copyright reform in the US.

(Photo by galuppi on Flickr)

This morning Signal vs. Noise linked to a post by Paul Stovell called We are what we repeatedly code:

The best developers I know write great quality code every time they touch an IDE. This is because they realize that writing good code is something you have to practice, something that you have to do over and over again to be able to do right. They realize that writing great code is something you do all of the time, not something you save for a party trick.

I agree with him on this. But what exactly is “quality code”? Paul uses an example of a small, throw-away tool he wrote recently:

I could have written the tool as one huge Main method in a console application. Yet, instead, it’s all nicely factored. There are base classes, adapters to reduce the dependencies on the outside systems, encapsulation, interfaces, a couple of occurrences of the strategy pattern, and even the odd XML-doc comment thrown in here and there. Hell, I even gave the DLL a fully qualified company namespace.

I get what he means: write every piece of code as if it will ship. But I can’t agree with any definition of quality that is measured by the amount of design patterns you use. All the things he described — encapsulation, interfaces, design patterns — are all well and good when used appropriately, but their abundance, or even mere presence, does not indicate quality code, any more than the presence of salt and pepper indicates a good soup.

I’m reminded of my first co-op term at IBM on the SWT team. Steve Northover, the SWT technical lead, has a couple of golden rules. One of them is “that which obscures my code is bad”. Encapsulation, interfaces, the adapter pattern, the strategy pattern…all ways of solving specific problems, but also ways of obscuring your code. So many people seem to believe that adding more structure will produce better results. We see a similar pattern in government (endless bureaucracy), education (standardized testing), and business (meetings, reports, yearly reviews, middle management). These things begin with the best of intents, but often end up causing more harm than good.

In software development, there’s a growing movement of people who believe that “less is more.”