Click here to monitor SSC
  • Av rating:
  • Total votes: 14
  • Total comments: 2
Richard Morris

David Heinemeier Hansson: Geek of the Week

07 August 2013

Ruby on Rails, the open-source web application framework, grew out of David Heinemeier Hansson's work on Basecamp at 37Signals. It is now so popular with developers that it has been  shipped with Mac OSX  since 2007, and has a dedicated Windows following. Rail's focus on software engineering patterns and Agile philosophy were so intriguing that we decided that DHH should be Geek of the Week.

David Heinemeier Hansson is the Danish programmer who developed the open-source Ruby on Rails (often called ‘Rails’) and so created one of the most popular tools among web developers. It won him the Hacker of the Year Award in 2005.

He helped transform the forward-thinking software firm, 37signals, from a consulting company to a web application company by writing the company’s first major release Basecamp, an online project management tool and then released the software that underlies it as an open-source web development framework.

Since then, Ruby on Rails has been used to build several high-profile websites including Twitter and YellowPages.com, and is now being adopted by organizations such as the BBC and LinkedIn.

Many of its converts have been won over by its opinionated philosophy.  Because Rails is Open-source, its development is being driven by a daily contribution of code from thousands of volunteers.

‘I actually tend to find the most rewarding progress to be the cumulative effect of thousands of tiny improvements,’ says Hansson.

 ‘That's what sets Rails apart from many of the also-rans. Yes, we've had the pleasure of popularising tons of major improvements to web application development, but the secret sauce is really the thousands of little things that the vast network of contributors have decided to care about.’

The popularity of Rails has spawned imitators in other programming languages - it's already been ported to JavaScript and PHP and programmers at the BBC have recently developed Perl on Rails. Its mainstream adoption has been boosted further by its inclusion in the Mac's latest OS.

Hansson points to what he says is ‘a natural cultural allegiance’ between Rails developers and Apple users:

‘We appreciate the same things. We find happiness and passion in things that are beautiful, tastefully executed and help us get the job done faster. The fact that Leopard ships with Rails is only a natural extension of that cultural bond.’

With this increase in attention, Rails is undeniably becoming more commercial. This is something  that Hansson doesn't mind at all.

‘I have absolutely no problem with commercialism. What good is it to enjoy doing Ruby on Rails if you have to return to the Java or .Net mines every morning to slog through another day? We want people to be happy doing real work, making a real living.’

David has also written three books including Re-Work a book about starting and running businesses in a better way. The book reached the New York Times, Wall Street Journal and Sunday Times best-seller lists.  

When he’s not working or writing David races sportscars and has competed in the World Endurance Championship LMP2 class at Silverstone, the Spa-Francorchamps in Belgium and the 24-Hours of Le Mans, the world’s oldest active sports car race in endurance racing.


RM:

David, in general do you feel programming languages are getting better over time?
DHH:
It seems like revolutionary changes in programming languages are getting few and far between. In the 10 years I’ve been working with Ruby, there hasn’t been a single big event in programming languages where I thought ‘Wow, I can’t miss this!’
On the other hand the rate of iterative, gradual improvement is as high as ever. The open source model of constantly improving on a solid core idea is alive and well. Ruby itself might not feel materially different from when I picked it up in 2001 at a first glance, but there has been thousands of small improvements that all add up to a large step forward in usability.
RM:
Do you think we need to get better at predicting what we’re really going to need in the future? And do you think programmers display intellectual curiosity about how programming languages developed, what influenced what, who did what and what is now considered a mistake?
DHH:
I don’t think predicting the future is a generally applicable development model. When we encounter new problems that are poorly solved with today’s programming languages, we’ll see people interested in improving them.
RM:
What part of Ruby on Rails was the most difficult to write?
DHH:
Active Record. Crossing the mismatch between an OO programming language and SQL is fraught with danger. It’s very easy to go too far. To not respect the underlying relational model and think that everything should just adhere to the OO paradigm. Striking the right balance of allowing the best of both worlds to shine was tough but it was very satisfying to get it right.
RM:
It’s one of those things about Active Record. A lot of people avoid it because it feels like the class is doing too much and many prefer to use Repositories that return business objects. How did you get Active Record in Rails to work so naturally?
DHH:
I looked at all the options before settling on Active Record. By far the easiest and simplest code came from using that pattern over something like a data mapping or similar. So that made the choice simple.
RM:
Am I right in saying that Rails was originally a toolbox which helped you build Basecamp or was it the other way around?
DHH:
It’s more the other way around. First there was Basecamp, and then I extracted Rails from it. I built a bunch of general-purpose libraries and frameworks in order to build Basecamp with Ruby and then realized half-way through the process that this could benefit others as well. I was extremely aware of tools that weren’t necessarily helping productivity so I sought out tools that might help.
That’s how I found Ruby. It was such a nice experience for me and a nice productivity booster. I was coming from PHP and had also looked at Java and other environments and I wasn’t finding anything that would allow me, as a single programmer, to deliver all this stuff.
And I then built Ruby on Rails to allow me to build Basecamp and drive this project in the ay we wanted to, because we didn’t want to bring on any more programmers. We wanted to keep those constraints that we had and so we just had to make tools that allowed us to do that.
And I think that’s also a big explanation for why Rails is having the success that it is; it was born in an environment that was so focused on productivity and was so focused on being able to deliver within constraints. I’m building Rails while I’m building Basecamp, rather I’m building Basecamp, and every step of the way I’m extracting Rails.
RM:
On your webpage you mention beautiful code. What to you are the characteristics of beautiful code?
DHH:
Beautiful code is similar to beautiful prose: Succinct, it has flow and rhythm, and it’s an expression of clear thinking that doesn’t jump around different layers of abstraction all the time.
RM:
So do the lessons of writing English for a human reader help you with writing all aspects of code? Are there any trade-offs for example if efficiency is important?
DHH:
Absolutely. I find that the best programmers, at least best high-level programmers, tend to be great writers as well. Programmers who wish to improve their code should improve their writing. Yes, occasionally you’ll have to sacrifice beautiful code for speed, but that’s an optimisation to make only after the fact that you’ve proven something to be too slow. Never upfront.
RM:
Is there an upper bound on how big a piece of software can be and still be beautiful?
DHH:
Most likely. It becomes exponentially harder to keep things succinct and coherent the larger the work. I try not to press those limits, though. I find it far more interesting to focus on how little software I can write to solve a problem than how much.
RM:
Much of what 37Signals offers has been driven by the company’s needs rather than what people have asked you for. Is the philosophy: innovate for your customers rather than them driving your innovation?
DHH:
In my experience it’s the only way to make something great. When you’re trying to guess what someone, somewhere might use your software for; you’re likely to build a bloated mess rife with options and configuration points. If you’re building for yourself, you get the proper feedback on what’s enough.
RM:
You’ve been the mainstay of developing products including Campfire, Ta-da List, Backpack any one of which could have been a business in itself. If 37Signals was a larger company before developing these products would they have been  made still?
DHH:
Smaller groups and companies carry less mass so they have an easier time  changing  direction. This means trying different things, building new products. Because the  tools and process we work with are so productive, we can appear to be a much  larger company than we really are by putting out a number of different products. But our goal is to keep the head count low.
RM:
Is there anything you would have done differently when you launched Basecamp?
DHH:
I don’t spend much time looking backwards and thinking about regret. Onwards and upwards!
RM:
What been the most surprising and rewarding thing about running a business?
DHH:
Providing a stable, fulfilling environment for employees who want to stay with us for their entire career.
RM:
Can you remember any hair-raising moments?
DHH:
We’ve had plenty. When we were first starting out, I was the only programmer and systems administrator. I finally took a vacation to Hawaii and of course Basecamp crashed while I was on the plane. So I had to spend the first few hours after we landed sorting things out.
RM:
Do you think software patents are a good idea?
DHH:
%!*k  no. They’re devil spawn and need to be destroyed.
RM:
Is this because all software isn't some single invention but a complex set of  very detailed rules? Also patent don’t lead to competition but rather stifles it?
DHH:
Patents in general are a strenuous case, but patents on software is like patents on math or writing. It doesn’t make any sense. It certainly stifles innovation and  breeds trolls who extract value from society at large.
Richard Morris

Author profile:

Richard Morris is a journalist, author and public relations/public affairs consultant. He has written for a number of UK and US newspapers and magazines and has offered strategic advice to numerous tech companies including Digital Island, Sony and several ISPs. He now specialises in social enterprise and is, among other things, a member of the Big Issue Invest advisory board. Big Issue Invest is the leading provider to high-performing social enterprises & has a strong brand name based on its parent company The Big Issue, described by McKinsey & Co as the most well known and trusted social brand in the UK.

Search for other articles by Richard Morris

Rate this article:   Avg rating: from a total of 14 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: Software Patents
Posted by: Anonymous (not signed in)
Posted on: Monday, August 19, 2013 at 12:50 PM
Message: Ironiy : Hansson admires so greatly the Mac and Mac OS, the spawn of Apple, the king of software patent trolls. Then his statement regarding software patents - "%!*k no. They’re devil spawn and need to be destroyed."

Subject: RE: patents
Posted by: Robert young (view profile)
Posted on: Wednesday, August 21, 2013 at 7:52 AM
Message: It's actually worser: current Apple OS is built largely from BSD unix, which, because the left wing hippies at UC/Berkeley were, well, left wing hippies, has a license which allows others to take the codebase and claim it as proprietary to themselves.

 

Top Rated

We don't need Source Control: we're Database Developers
 As part of our long-running series of articles where we ask working database developers how database... Read more...

The Proposals Conundrum
 When you work for a small software development (or any services) company, one of the major challenges... Read more...

David Heinemeier Hansson: Geek of the Week
 Ruby on Rails, the open-source web application framework, grew out of David Heinemeier Hansson's work... Read more...

Alex Payne: Big in the IT Business
 Alex Payne worked on developing Twitter for three years. When he started, it was a small side-project:... Read more...

Seth Godin: Big in the IT Business
 Seth Godin has transformed our understanding of marketing in IT. He invented the concept of 'permission... Read more...

Most Viewed

The Future of Reflector
 Simple Talk asked freelance writer Bob Cramblitt to sit down with the two people behind the agreement... Read more...

Linus Torvalds, Geek of the Week
 Linus Torvalds is remarkable, not only for being the technical genius who wrote Linux, but for then... Read more...

Bad CaRMa
 From hope and euphoria, to desperation, firings and the ultimate demise of a company. Tim Gorman charts... Read more...

Driving up software quality - the role of the tester
 Have you ever wondered what a software tester does? Helen Joyce, test engineer at Red Gate software... Read more...

Don Knuth and the Art of Computer Programming: The Interview
 Fifty years after starting the 'Art of Computer Programming', (TAOCP), Don Knuth is still working hard ... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.