Mention in Wired piece on 37signals
ryan / Tue, 26 Feb 2008 08:32:25 GMT
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.
Subscribe
I’d but that book because Kathy Sierra’s on it. Wish she’d come back to the blogging world.
Ryan wrote: ...programmer happiness is the most important factor in making quality software…
Shouldn’t “end-user happiness” be the most important factor?
@Andrew Rutkin:
I think customers will, generally speaking, be happier with the software they use if the programmers that made that software are happy writing it.
You need to love what you do before others love what it does! Cool Article…
“Performance is cheap”: I think you are dead wrong there, performance has always been an issue in Software development. The software needs to be usable, not just maintainable. Balance must be found, you can not concentrate on one to the detriment of the other.
Couldn’t agree more with the sentiment. But how can this possibly be realized in practice? Unless we’re talking open source development, there will always be pressure to get the release out quicker, squeeze more features in, or improve response times…
That’s certainly true for a large segment of software development – many things can be easily scaled by just throwing more hardware at it.
However, some problems are still requiring hard core performance work. If you need to handle enormous amounts of data in real time, there are not too many options except squeezing out every ounce of performance.
(I happen to be working on video games. The amount of data both in the actual game and in the content pipeline is quite big, and it all needs to be processed as fast as possible – because we want to iterate on the game itself, not the underlying tech)
Ryan write: ”’I’m not designing software for other people,’ Hansson says. ‘I’m designing it for me.’”
You’re joking, right?
Maybe this works if you’re a representative member of the user population for the thing you’re designing/building. This may be the case with 37 Signals, but, generally speaking, this is rare. What if you’re a developer asked to design and build a tool for a user population of which you are not a representative member?
And that’s just the beginning.
I mean, seriously—developers are not designers. Being good at building things does not mean you’re good at designing them.
And having the responsibility of building something means that you’re always going to be looking for the easiest/most elegant way to implement it—which is often at odds with what is best for users. In my experience, there’s just a fundamental conflict of interest.
I’ll say it again: Developers are great, but they’re not designers. And they should be expected to be.
I concur with Jake in that developers should be designers. I think that they are but many are not good ones. I like to think about software more as a craft. You got some freedom in the way you do software, and i really like doing software for a purpose.
If you think like me, you really enjoy watching people using your software and improving it. I guess for a programmer to “be happy” with software is to have the motivation of doing it for a purpose, having continuous feedback with customers and having the opportunity to improve his skills.
@Oscar:
Agreed. Craft. Freedom. Desiginopers. :D
Email me if you want a job.
4 hour work week!
(And as far as representing the user. Be the user aswell, even if you have to become someone else. I mean Ethanography is interesting but you have to taste it to know it. )