The Norbauer Software Design Philosophy
After a happy series of acquisitions and mergers, Norbauer has been retooling from being primarily a large international web application consultancy to a smaller, more focused team working on a suite of productivity apps (to be announced late 2013) for retail sale. As I've been working on that process, working both on cross-platform/in-browser and Windows desktop apps, it has been helpful for me to reflect upon the engineering and aesthetic values that led me to software in the first place. I've thus been thinking back a lot to an interview I did in 2008 with software/design theorist Amy Hoy. As much for my own benefit as anything else, I'm reproducting that discussion below.
AH: How would you describe yourself in, oh, 15 words or less?
Let’s see. How about: "I seek beauty, and elegance out of complexity—which are pretty much the same thing."
Admittedly, it sounds a little pompous, but it’s not far from the truth.
AH: How did you first get into programming?
In 5th and 6th grades, I was put in a weird, experimental “gifted” classroom with 15 other kids from around the county (largely I think because my teachers were exasperated and didn’t know what else to do with me.) The curriculum consisted of nothing more than setting a bunch of nerds loose all day to daydream and follow their own pursuits.
This is where I met and fell in love with a certain Apple IIe. And thus I spent two entire years of my formal education teaching myself to program Star Trek adventure games in Apple BASIC.
Needless to say, my transition back to normal public school wasn’t pretty.
AH: How did you continue programming as you got older?
As a dabbler, mostly.
In high school and one summer in college, I interned at a NASA software facility where they worked on code for the space shuttle, so I came to know the surreal and ugly world of huge-scale software development early on. I primarily worked on re-writing their inscrutable procedure documents for clarity, and I created a few web apps in ASP for internal use.
Oh, and I also made a lot of software for my college thesis research in psychology with Visual Basic.
AH: And how did you get into Ruby specifically?
It all started during my second year of grad school as a social science researcher on a PhD track. I was growing disillusioned with academia. I was beginning to realize how hard it is to get tenure doing the sort work I wanted to do—work that could have a real impact on the world beyond the Ivied Walls. The academic system is, bewilderingly, structured so as to encourage irrelevance and obscurity.
So I dropped out of grad school and taught myself PHP to pursue a business idea I had been toying with for a couple years—a capitalist, rather than academic, approach to addressing a social problem.
That business became Lovetastic, which was my first experiment in building a business and playing seriously with web applications.
Shortly thereafter, I attended 37signals’ Getting Real workshop—back before there was a book of the same name. Even though the workshop didn’t specifically advocate any particular technology, a lot of what Jason and David said that day (along with the beautiful code the latter presented in his slides) pointed me in the direction of Rails.
I went straight back to the hotel and read everything I could find on Rails (which I had been interested in for several month months) and I decided that same day to rebuild Lovetastic from scratch in Rails. In a few months, it went from 20k lines of PHP spaghetti code to 2k lines of well-organized, elegant Ruby code that was a pleasure to deal with.
Since then, Ruby has become a huge part of my life. I run a Ruby/Rails consulting firm with teams in New Delhi and New England, and we all get to work together on some amazing projects for some very smart and thoughtful clients. It’s amazing how one’s choice of technology can act as a filter for the kind of clients you’d want to work with.
AH: Why was Ruby and Rails such an instant draw for you?
As Lovetastic went live and grew in complexity, I found myself experiencing a terrible sense of creeping dread every time I contemplated feature improvements or additions, because I knew that any one change was likely to break five other things.
PHP made it too easy to be a bad programmer, making it a lousy tool to put in the hands of a lazy and slightly daft guy like myself. I don’t just need an angel on my shoulder; I need a dominatrix. And that’s precisely what Ruby (via Rails) is for me. Quite simply, Ruby and Rails taught me how to be a good programmer. It encourages me to seek elegance in the way I express the core logic of my application, and to abstract away complexity and repetition as soon as they show up.
AH: You also are someone with a passionate interest in design and design philosophy. How did that come about?
Ha. Yes, well, my favorite terms of self-derision are “effete aesthete” and “pathetic peripatetic.”
The thing is: I’ve always been drawn to what you might call “big questions,” for some reason or another. The reason I chose psychology as a major in college, for example, was because I viewed that discipline as a way to study the big transcendent questions of philosophy (conciousness, motivation, etc.) using the tools of science.
Equally, my love of design has always been about big questions: the power of images, colors, and lines to convey profound ideas using really elegant visual cues.
I think this all started with Mrs Morgan in sophomore English class. On the first day of class, she read to us Keats’s “Ode on a Grecian Urn:”
Beauty is truth, truth beauty,—that is all
Ye know on earth, and all ye need to know.
She then proceeded to lead us on a year-long tour through words and paintings, with a particular emphasis on Romantic period poetry and painting, along with modernist architecture. She loved art and design and saw them as inseparable from the study of language, which I suppose is what English class is technically supposed to be about. At that impressionable age, she helped me appreciate the grander implications of studying visual aesthetics, something which remains with me to this day.
She was the first teacher to make me realize that the careful study of old poems and paintings isn’t just a rote exercise to prepare for the AP English exam or an “Art Appreciation” quiz, but rather that those activities are really just about the study of ideas. They’re about distilling the whole of our universe and human experience into simple, beautiful concepts that anybody can discuss and understand.
Science at its best does the same thing, and in a somewhat more limited way, so does good programming.
AH: What do you mean by that?
Simplification, unification, and reduction: these are the values of a great craftsperson, whether she’s a tradesperson in the guild of ideas, words, paintings, or software. Shakespeare’s Hamlet, the theory of evolution by natural selection, and Ruby on Rails: each of these is in some way a form of digesting something that seems huge and intimidatingly incomprehensible (death, creation, and the crafting of involved web applications, respectively) into a set of basic, approachable concepts.
AH: Do you ever think to yourself, “Hey. I did the psychology education. I’m a programmer. I run a social web community. I manage a programming team. I write and design stuff. Maybe I should add another field to that list?” [sarcasm alert]
I have to resist the temptation every day.
I guess the reason I’m such a dilettante is that I refuse to make distinctions between disciplinary boundaries. Everything to me is about the underlying ideas. When I find ideas I like, I follow them wherever they lead me.
The ideas involved in everyday design can say things as varied as “this object is rooted in an awareness of history,” “the happiness of the user of this object is worth caring about,” “nature and humanity are one and the same.” But they’re all interesting to me. Attributes like “clean lines,” “lots of whitespace,” or “flat vector illustration,” are important and interesting to discuss, but what’s really at stake is what those things say—the ideas the designer is trying to communicate to his user.
AH: How would you say your background has affected your experience of software development?
Rather unsurprisingly, it has meant that I’m drawn to aesthetic questions. This obviously applies to the way the code itself is written, but there is also beauty to be found the broader concepts of good programming—in particular, searching for ways to abstract away the crushing complexity of these wily networked computing devices we sit in front of all day.
David Hansson was one of the first people I ever heard use the words “beauty” and “happiness” in reference to software development. This totally changed the way I thought about programming. Or, more precisely, it liberated me to be honest about what I felt all along: the programming is, when at its best, an exercise in artistry and craftsmanship (and therefore something I can give a damn about.) Programming should be about making things that seem complicated easy to handle.
In this way, programmers are really lucky. Unlike biologists or mechanical engineers, who have to deal with the world on its own terms, programmers deal in a world that is entirely of their own making. We have the luxury of being able to re-work and re-invent our world to make it easier to understand. Physicists don’t have the option of re-writing the laws of relativity in order to make the cosmos easier to understand for everyone, but programmers do have an analogous power. If something like the exchange of data over the web, or the modeling of database records as programmatic objects is too complex, we have the power to invent a new world that makes everything easier to get our head around. Rails, of course, does precisely this.
AH: If you had a magic history wand, what’s one thing you’d change about the technology industry?
I would eliminate the insecurity that makes so many folks in the industry feel the need to come off as “plausible.” The fact that we’re craftspeople gets lost in all the meaningless bullshit stupid-speak that everyone spews like a nervous tick to prove how “serious” and professional they are.
Eighteenth century furniture makers (among the best craftspeople human civilization has known) didn’t feel a need to talk about their rattan synergy verticals or the going-forward scalability of their organic people-ready growth competencies in wood assemblage. Their embellishments may have been inspired by a certain movement in design or a set of ideas (as Shaker furniture makers were), but primarily craftsmen of the past were just worried about how to make beautiful objects that suited their purpose elegantly: tools for the tasks of everyday life.
Technology is just tool-making. If this process comes off as “complicated” or “sophisticated,” we shouldn’t congratulate ourselves on how smart we are to be able to work with all this complexity, we should be ashamed of our failure. Tool-making is an elemental, ancient pursuit—one which many anthropologists argue is the most ancient and distinguishing pursuit of our species (even more so than language.) It’s about making life easier, for our users, yes, but also for ourselves. We too easily forget that. Programming should be the art of the easy.
Norbauer's RubyRags, acquired by Littlelines
We’re really excited to announce today an exciting new initiative for RubyRags (a community-spirit-building project selling Ruby and Rails themed apparel to Rubyists across the globe).
We at Norbauer Inc created RubyRags a few years ago and it grew quite popular in that time, but our consulting work prevented us from giving the project the proper attention. As of today, however, our pals the brothers Matt and Josh Sears over at Littlelines are taking over the RubyRags reigns, and they have some truly awesome plans for it. We believe they’re the perfect fit for the project: not only are they huge supporters of the Ruby and Rails communities, but they also have a keen design sensibility and an enthusiasm for e-commerce.
We can only share a few of the new things in store for RubyRags with you publicly now. But, suffice it to say, Littlelines plans to restock all the popular designs that have run out of stock, and more importantly, they plan to start releasing new designs at a regular interval, similar to how PeepCode releases screencasts. RubyRags hasn’t introduced a design in years, so this is a particularly exciting development, and I’m really eager to see what they come up with (especially since Josh is an illustrator himself).
Join the RubyRags mailing list for to stay in touch with what RubyRags is up to in the coming months.
Congratulations to Littlelines, and to all of us who will get to benefit from what they have planned!
The Psychology of OmniFocus: How to Wrap your Head Around the Finest (and Most Perplexing) GTD App on the Market
Though I have been hard-core enthusiast and sometime black belt of GTD since around the age of 20 (i.e., nearly a decade), I’ll admit to having had a certain initial reluctance and skepticism about OmniFocus. Perhaps this was due to the seeming eternity the notional app spent as vaporware, but I think it was mainly my bafflement at first opening the program shortly after its beta release. In its tiny default font and weird spacing, it presented the user with an empty list and almost no guidance on what the program does or how to use its amazingly complicated array of options for every conceivable combination and permutation of projects, lists, children, parents, siblings, start dates, dependencies, etc. I futzed with for a few minutes, realized I didn’t have a full week to spend learning a piece of software that seemed to make a simple task more complex and didn’t allow me to sync my data across computers, and I gave up.
As syncing and other improvements like increased clarity of features and flexibility of configuration options and the ability to customize the appearance of lists came along, OmniFocus was already dead to me. It wasn’t until much later when a chance frustration with the weight and drudgery of my own makeshift pen-and-paper GTD implementation drove me to give it another try that I learned precisely how amazing an implementation of David Allen’s system the folks at OmniGroup had ultimately come up with. It renders elegant and easy elements of the GTD workflow that were previously either cumbersome or completely impossible to do properly with a paper-based system (or, worse, a system based on a hack of an existing piece of software built for another purpose).
I will add, however, that it wasn’t until spending a few hours slogging through the manual that I finally “got” this about OmniFocus, and frankly I can’t imagine anyone else just downloading the software, playing around with it, and making it their primary productivity tool spontaneously. The learning curve for OmniFocus is honestly far steeper than with any other piece of desktop software I have ever used. What I have since learned, however, is that the payoff is very much worth the effort.
We were recently cited in a Wired article on Rails.
I had a nice time chatting with Andrew Park of Wired recently about some of the subjects on which I have so frequently opined in this and other venues: simplicity in software, programmer happiness, and the role 37signals has played in promulgating those values in the tech world.
Park cited me as a source in the resulting article; (and graciously made a salutary reference to Lovetastic and my consulting firm.)
It’s an interesting article, and I’m glad to see more journalists paying attention to the fact that Rails and 37signals applications are important as much for having shifted the contemporary discourse about software as they are for the technologies in question themselves. But I think if the article had any weakness, it was that it didn’t very thoroughly discuss something to which it only alluded in its closing sentence: “’I’m not designing software for other people,’ Hansson says. ’I’m designing it for me.’”
Not enough attention has been paid to the growing movement in the software development community that suggests that programmer happiness is the most important factor in making quality software—the argument that code is meant to be read by humans first and computers only secondarily—that in order to write software that addresses real human needs we need to approach the problem of software development from a more human perspective. These “emo programmers” (if I may borrow Kathy Sierra’s coinage, which was originally intended as a joke) recognize that the most costly aspect of software today is the labor involved in making it. Performance is cheap. On the other hand, creating, customizing, and maintaining huge (and hugely complex) bases of inscrutable software code is very expensive.
There is increasing sentiment in the software world that we should be happy to take performance hits if it means the process of software development can me made more sustainable, pleasant, and simple. That’s what Rails does. And in this it embodies a sweeping philosophy about the manner in which software development should proceed, which stands firmly in opposition to the prevailing view in much of the Fortune 500 world.
I’d like to see us take up “emo programming” as a badge of pride to describe this nascent philosophy. Original terms of dismissiveness like “suffragette” and “tory” have subsequently been taken up as banners around which to rally movements, so there is no reason we shouldn’t do the same. Hopefully this article is an early sign that more people are paying attention to this movement and taking it seriously for what it is: an entirely new way of thinking about the how and whys of software development, and about the fundamental relationship between humans and their computers.
Death and Underachievement: A Guide to Happiness in Work
The trite wisdom of contemporary folklore instructs us that the arrival of the New Year is a time to reflect on the achievements of the preceding 365 days and to bear down and “resolve” to achieve more in those to come. Over time, we learn what a hydra-headed beast this is: no matter how many projects or actions we may whack off our ineluctable lists, it seems that yet more (often increasingly ambitious) commitments spring up in their place. With each new year come self-recriminations for our failure to meet the unlikely goals we’ve set for ourselves—lose weight, read through those piles of books and RSS feeds, start picking up our socks, and a stultifying brainstorm of new projects we’d like to take on.
This New Year as I contemplate my resolutions, it’s the underlying concepts of achievement and productivity that are on my mind, and by extension the still grander issues of purpose and meaning in work. I invite you then, patient reader, on a desultory First Night journey with me as I take our mutual favorite hobby—the idle navel-gazing contemplation of productivity—to its most absurd yet logical conclusion: to ask whether eradicating the need for achievement itself might not be the key to happiness in work.
The (more or less) paperless life
I know, I’ve been nerding out writing for 43folders a lot lately and promise to write a cranky post here at NRS soon. In the mean time, though, here is my latest how-to over at the folders.
I can’t plan out a new piece of software—or write an essay for that matter—without first messily scribbling my ideas out as mind-maps or rough user-interface sketches onto paper. My brainstorms are too messy and flow too quickly for the computer to be able to accommodate my chaos, yet that early disorder is essential to crafting the order and structure that will follow.
And yet I used to have serious reservations about this tendency to spoodge my thought process onto tree carcasses. It wasn’t until I finally learned how to get rid of paper, that I was able properly to embrace its use in my work.
My new 43folders post: an ancient implementation of the GTD "Tickler file"
Check out my latest blog post over at 43folders. Nothing big, just an intriguing (and totally nerdy) serendipitous discovery about the history of GTD.
Part 2 of my 43folders article: the practice of outsourcing
As Merlin puts it:
Ryan Norbauer returns with the hotly-anticipated conclusion to his series on the psychology and practice of outsourcing your life. If you haven’t read it yet, be sure to start with part 1.
my 43folders article: Enlightened outsourcing
Celebrated productivity stud-bunny Merlin Mann recently asked me to expand on my outsourcing post here at NRS for his readers over at the venerable 43folders.
Here’s a teaser:
In a matter of a few months, I’ve gone from being an obsessively micro-managing perfectionist entrepreneur who reserved even the most miniscule tasks for himself, to someone who gets assistance on an almost daily basis from no fewer than fourteen outside sources, from New Delhi to New York. And a wonderful thing has happened. I find myself robbed of all those enticing excuses to avoid doing what I ought to do, and I’m actually spending time on things that matter instead. I can honestly report that nothing I’ve ever tried, including GTD, has so radically transformed my ability to bring the big plans I have for my little universe actually to bear upon reality.
And the full monty.
Social networks aren't products
Nobody wants to be the only person to show up at a party. Not only does it make you look like a loser, but it undermines the whole point of going to a party in the first place. Nobody gives a damn how good the cupcakes are; if scarcely anybody shows up, your party is a failure. Equally, nobody goes to MySpace or Match for the cupcakesâ€â€or, to be more precise, the quality of the user experience. People flock there because that’s where everyone else is.
Check out the full text of my feature over at Vitamin Magazine (now part of the Treehouse network).
