Martin Fowler Keynote

Posted by Brian Eng on June 24, 2006

A little odd that he's been asked to give the keynote, since he's never used Ruby on Rails! (Although he's been using Ruby for a long time.) So he's going to be talking about something else instead...

Software Design

What makes good software design?
Opinionated software - don't try to be all things to all people
Active Record pattern - not that useful in an "enterprise" setting - but so what?
But if you can live in a world where Active Record makes sense, it makes life a lot easier.
He's never seen an Active Record implementation as complete or as useful as Rails.
One framework to do everything = disaster
The Rails core team vision should never change.
Simplicity
Java - enormous power, but overly complicated, for pretty much anything
Rails has further driven toward simplicity.
Two camps
VB/PHP - "We have great disdain for Visual Basic"
Enterprise - "1 week application in 9 months"
Quick and clean
Traditionally, to do something quick, it has to be dirty... to do something well, it takes a long time... no more!
Smalltalk - quick and clean - and Ruby/Rails continues that notion
Quick doesn't have to be dirty. There should more attention paid to that in software.
Testing as a key part of software development. With strong testing culture, a lot of the concerns with traditional software development go away.
Should someone you're doing work for care that you're using Rails (or any other technology)?

Yes, technology affects the whole of the conversation between developers and customers.
The secret, the hardest part of software development is building exactly what the customer needs.
Extreme Programming -> quick and clean -> conversational mode.
Find out what is needed by a mutual process of exploration.
Don't spend a lot of time aiming. Just fire.
Drive down cycle time by using short iterations and engaging the customer in the process.
In order to get the cycle time down, you need the technology and tools to do that. This is where Rails comes in.
Physical proximity (on-site customer) is important. But you've got have something to show them. Again, Rails.
In this age of Web 2.0 (TM)... there is this culture of just give the product to the customer. Then see how they use it. Ship the product, then gather the requirements. The opposite of the traditional process. Fire, aim, fire, aim. As long as the bullets are cheap.
Technical plumbing is interesting to some people. But mapping the software to the business problem is really interesting. Rails makes the technical plumbing stuff go away.
The best value occurs when software people work hand-in-hand with business people. This is a very important cultural shift that Rails is helping to enable.
Ruby

Ruby just suits me better than Perl, Python, Java.
Rails is important because it drives interest in Ruby.
Rails is successful because of the power of Ruby.
Rails is so simple, it's really Ruby that is important.
We shouldn't even be having RailsConf!
One of Smalltalk's greatest failures - it wants to be everything
Post-Modernism's notion = everything is the same
Even a nice system, beautifully designed, is basically the same as the next.
The heart of Ruby's success is that it's aware that it is a hodgepodge of stuff. Rails only part of the solution. It's about being to throw a bunch of stuff together to create a working solution. Not a very controlled environment. Here are the complexities and inconsistencies - deal with it. Ruby and Rails encourages that.
One last reason Ruby and Rails is important: the people in the community. And it's the most important thing.