One of the many things that I love about SxSW is that they let the attendees vote for the sessions that they want to see. They are also very realistic that the attendees are not picking the sessions, but they do count for 30% of the vote. Their whole process is laid out on the main page at http://panelpicker.sxsw.com/. It’s 30% attendee votes, 30% staff and 40% advisory board.

The reason that I’m bringing this is that I’ve submitted some sessions this year for SxSW and I need your votes. Typically I don’t do this blatant of a self promotion and/or plea for help but I’m up against some of the best social marketers in the business. 🙂

Specifically, I’ve got two that are up for votes right now.

The first one is a joint session with James Ward who is one of the technical evangelists from Adobe. He and I are talking about the best and worst practices that we see at our clients every single day.

Title: Best and Worst Practices Building Rich Internet App

Description:
Seen a good RIA lately? A bad one? Because RIAs provide a similar user experience to desktop applications (with the ease of a web/browser-based deployment), confusion results from potentially conflicting practices depending on whether one approaches the RIA as a desktop or a web application. Let’s stop the madness.

Questions:

1. What is RIA?
2. What technologies are considered RIA technologies?
3. When should you use RIA?
4. When should you not use RIA?
5. What’s the learning curve for desktop developers to jump into RIA?
6. What’s the learning curve for web developers to jump into RIA?
7. What are the best practices for RIAs?
8. What are the worst practices for RIA?
9. How does one deal with multiple form factors?
10. What’s the best architectural guidance for a RIA?

The second session that I submitted is a joint session with Jason Gilmore, resident PHP Guru and consultant. He and I are talking about intelligently scaling your applications through cloud computing and our lessons learned actually doing just that.

Title: You Build It, They Come, Your App Scales

Description:
A startup’s biggest hopes – and fears – are hitting it big, and having to scale to 100,000 users overnight. See how PHP combined with Cloud computing provides the best of both worlds – low entry barriers, low startup costs and the ability to scale rapidly to meet demands.

 

Questions:

1. What is Scale?
2. What’s the difference between Scale and Performance?
3. What are the ways to scale an application?
4. How do you determine what scale you need?
5. What is cloud computing?
6. What is Azure?
7. How well does PHP work on Azure?
8. What considerations are needed to run on Azure?
9. How do you geo-locate an application?
10. How hard is it to get started with cloud computing?

I need your help getting the word out and the votes flowing. Please tweet about the sessions and/or this post and drive some awareness of my sessions! 🙂

Putting the “FUN” back in functional programming (or at least taking the “FU” out of it)

Randall Thomas kicked off the morning with a talk on Functional Programming. I have seen a number of talks on functional programming but was really looking forward to Randall’s take on it as he’s not only smart but he’s really entertaining.

The basis for functional programming was that there were a group of guys that were trying to figure out how to mathematically prove that an application was correct. This had strong basis in lambda calculus. The interesting idea here is that since the program can be mathematically proven, you can do things in a almost any order and it will still work. This means that you can

This is a big deal with systems that deal with concurrency. The reality is that any web application has to deal with concurrency. 3D video games deal with concurrency. Distributed computing, cloud computing and many of the things that we are doing on a daily basis have to deal with concurrency.

FU(Thinking) is when you start thinking functionally and solve a given problem in different way than you would have in the OO world.

Recursion is an example of this. Everyone has had to written and messed up a recursive function. The example that he used was calculating a Fibonacci sequence. In straight Ruby, the demonstration was 10-15 lines of code with a while loop, counters that were incremented and decremented and so on. The functional version of that was 4 lines with no looping,

I loved his quote “Amateurs copy, professionals steal” as he put up a demo that he borrowed from someone.

Honestly, he lost me a little on the deltas between procs and lamdas in Ruby.

He brought up the topic of Monads. When he asked the crowd who understood Monads and Jim Weirich didn’t raise his hand, I knew that we were in trouble. Then Randall admitted that he didn’t fully get Monads either. At that point, I knew that I wouldn’t get it probably ever. But he went on to say that mostly people talk about Monads in context of the obfuscated code contests and the like.

List processing is at the core of the things that we do on a day to day basis. There are three things that we do to lists every day.

• Transform everything
• Extract everything
• Combining (everything or something)

Functional programming is really good at list processing.

“iteration is the life blood of ruby – and now a word from some bad ass functional code.”

#Ruby magic – f(x) style
(1..10).reject{ |x| 0 == x%2 }.map.join(‘,’)

So what does that do? It prints out all of the odd numbers from 1 to 10. Notice that there’s no initialization, no main and so on. This is at the core of why people love Ruby. It’s an extremely expressive language.

I was partially nervous that this talk was going to be a pitch for a “Functional” language such as Haskell, Scala, F# or Clojure. But it wasn’t. It was explaining functional programming and help us bend our head around thinking like a functional programmer but accomplish what we need to do *most* of the time in Ruby.

Modeling Workflow Concepts in Ruby or (almost) Everything I Needed to Know about Workflow I learned from Schoolhouse Rock.

David Bock is a workflow consultant. He’s a great speaker and just a fun guy to hang out with.

State-Based verses Process-Based workflows is one of the core concerns in workflow camps.

State-based workflow – this is the thing that reminded David of Schoolhouse Rock. He was thinking about the example of getting a bill passed (http://www.schoolhouserock.tv/Bill.html). There are a lot of different states that a specific bill can be in at any given time. But how things progress from one state to another is the interesting bits. The states are just the points that you would tell your boss if he asked you how things are going. It’s been “Submitted”, it’s “In progress”, it’s “On order”, it’s “Completed”.

To implement a State based workflow, you can do it easily in Rails. David is also working on a project called “Stone Path”

Process-based workflow flips things on it’s head compared to the state based workflow. Or as David said, Process based workflow says that Schoolhouse Rocks was wrong. The state is not what’s an issue, what matters is who does it and how it’s done. This deals with what things can be done in parallel and more. These are things that state based models don’t deal with. There’s a fair amount more handholding and strictness to a process-based workflow engine as it really deals with the “How” of what you are doing, not just the end results.

There’s a project that deals with it well called Ruote.

If you users are novices, you need to choose process-based workflow. This will give them a lot more handholding and rules that they will have to follow.

If you users are experts, you need to choose the state based work flow. This will give them the freedom to skip around, push the boundaries, take shortcuts and anything it takes to get from one state to the next. This can be a good and a bad thing.

“Workflow” is not a tool, it’s a bunch of domain concepts that you can apply and implement yourself.

Playing Nice With Others

Jeremy Hinegardner did this talk about playing nice with other languages and data stores and the like. He talked about the idea that there are three types of persistence that are out there. None, Snapshot and Lifetime. There are times that we need one verses the other

Then he talked about a number of different tools that accomplish various bits along the path there.

Memcache – This is a memory based object caching scheme that is used heavily in a number of different languages including Ruby, Python and PHP.

Tokyo Cabinet – This is a set of libraries that cover a fair amount of ground. They can fit in either the Zero or Lifetime persistence.

Redis – “Redis is a key-value database. It is similar to memcached but the dataset is not volatile, and values can be strings, exactly like in memcached, but also lists and sets with atomic operations to push/pop elements.” – from the Redis home page.

Beanstalk – This is fast, distributed, in-memory work-queue service.

ZeroMQ – This is a memory based messaging system.

The most interesting part of the presentation to me was when Jeremy started showing how understanding what your persistence needs were and how that helped you make your decisions on which of the frameworks to pull down. For example, if you need
Lifetime persistence, you should look at Tokyo Cabinet and so on.

Building Native Mobile Apps in Rhode

The last talk of eRubycon was done by Adam Blum on writing mobile applications. The Rhodes framework is an application framework that all allows you to build applications in HTML and Ruby and deploy that application to iPhone, Windows Mobile, BlackBerry, Android and Symbian.

Their tag line is “The Open Mobile Framework”.

The architecture is that they built a small web server and Ruby implementation for each of the platforms. The framework actually loads up the HTML/CSS from the small web server and runs it in the local device’s browser control. I asked him if they ship a browser control or not and he said that they haven’t had to. Specifically he talked about the fact that Blackberry is actually the hardest to work with. They were surprised by the Windows Mobile browser. In their experience, as a browser is not fantastic compared to Webkit based browsers but as a browser control it’s actually very light and works well.

They have a public beta of RhoHub which is a deployment as a service for mobile.

Leadership 101

Jim Holmes kicked off day two with a talk called Leadership 101. This is an amazing talk. Jim, as humble as he tries to be about it, is an amazing leader.

He has posted his slides at http://is.gd/2avEy.

He started off the talk with a story about World War 1 and a story about trench warfare. I knew but it didn’t really hit home that the phrase “Over the top” started in trench warfare. In trench warfare, the troops dig in and build trenches that they basically live in except for when they are on the assault. The phrase “Over the top” referred to leaving that safety and crossing no man’s land, the area between the two armies where you were in the direct line of fire, and going to attack the enemy. This was not a safe thing to ask people to do. But the “brass”, was not on the ground in the trenches. They were miles and miles away in relative safety. In 1912 in France, there was a huge miss that was caused by this separation. They missed the fact that it had been raining for weeks and that the trenches had flooded, the river had flooded, the fields were swamps and there was no way to move quickly. It was suicide to go over the top. But they didn’t know that so they kept sending people over the top and ended up loosing 500,000 men.

The next thing that he talked about is that we, as technologists, need to grow. We are passionate about what we do and take pride in the technology that we implement. But we need to understand business value and how that relates to what we are doing. When we talk to the business owners, we need to express ourselves in terms that they understand. “The business does care, they just speak a different language than we do”.

The next step is to mentor. Take on mentors. Mentor others. But as you are entering these mentoring relationships, you have to be an active participant in the relationship. As one of his early mentors said “You are not a teacup and I am not a teapot and I can’t just poor information into you. You have to be an active participant in this relationship”. Mentoring is a two way street.

Another thing that he talked about is the idea of smart mistakes verses dumb mistakes. If you make a smart mistake, there shouldn’t be any negative consequences for smart mistakes. These are ones where you do the due diligence and make a decision after some thought and it turns out to be the wrong decision. That’s fine. The dumb mistakes are the ones where you make rash decisions without understanding or thinking about the consequences of the decision. These should have consequences.

In order to be a great leader, you have to have the respect of your team, peers, clients and more. But how do you get that respect? “You don’t get respect unless you give respect. You can’t demand respect back. You earn that respect”.

“It’s not just enough for you to be successful. Those around you, below you and behind you have to be successful too. Leading from the rear has never been successful.”

Jim did an amazing talk and really opened my eyes in a number of ways.

Your Rails are Rusty

Adam McCrea from EdgeCase did a talk next about doing Rails development and productivity. He started off the session talking about a project recently where they got started and it took them several iterations to get to a productive state.

The basic problem that he started off is that when he started Rails development, he accepted all of the defaults and was very successful. But over time he kept changing this default or that default and trying new plug ins. Each time he tried a new plugin, he added possible complexity and startup time. He advocates “minimizing decisions – automating as much as possible”. This is the core thesis of the talk. I whole heartedly agree.

“If you’re learning too many new things at once on a project, something has to go if you hope for success” – Joe Fiorini on  Twitter

Adam laid out a number of really good guidelines in his talk.

“Your needs may be more complicated than this, but don’t assume that they are”.

“If you don’t understand the source” of a given plugin, then you should run away. This is a great tip. You can blackbox Rails to a degree but it’s really hard to do that with a given plugin.

One of the things that I really liked that he talks about is that you should pick a default UI for all of your projects that you don’t have a designer to work with on.

Be Careful, Your Java is Showing

Joe O’Brien did a great talk next on developing Ruby as Ruby, not as Java, C#, C++ or whatever language you did last in Ruby syntax. There are some core changes in the mindset that you have to put yourself in to be truly successful.

Unfortunately, I was panicking over my upcoming talk a little so didn’t get to listen to him in great detail.

If someone wants to email me or put a summation in the comments section, I’d happily put it inline here and give them credit.

Enterprise Java

Charles Nutter was the talk right before me. As I was still building some of the demos and getting ready for my talk, I was not able to really get a lot of notes down.

JRuby is in version 1.3. They are rolling along pretty quickly. They are fully 1.8.6 compliant and are most of the way to 1.9. One interesting thing that he pointed out is that you can have 1.8.6 and 1.9 in a single binary.

He showed GlassFish running on JRuby.

He showed running JRuby on the Google Android device. This got a few good oohs and ahhs.

I really wish that I had been in a better spot with my talk to take more notes. Again, if you’ve got a good summation, please help me get that up here.

*Update* – my plea for a summary were answered by Gayle Craig, aha @gayleforce.

“Charles observed that when Ruby first gained it’s popularity, many Ruby developers were coming over from the Java world.  And now, some of those folks are going back to Java because their companies are not moving away from the Java platform, and because of the maturity and availability of tools that may not have been written yet in Ruby but are already available in Java.  If the rubyists embrace this, and work to find ways to build bridges between Ruby and Java, then that will continue to entice more Java developers over to Ruby instead of abandoning Ruby.  And that’s good for the Ruby community.  And that’s what JRuby is working to do.  Charles demonstrated some things in JRuby like ruby2java (a Ruby to Java compiler), become_java, and Jibernate (Hibernate through JRuby.) Charles highly encouraged developers in the room to contribute to JRuby, as there’s only a few of them working on JRuby and there’s plenty to do…”

Thanks Gayle!

IronRuby

I did the next talk on IronRuby. Largely, I did Jimmy Schementi’s talk from Oscon with my own twist. He posted his speaking notes at jimmy.thinking IronRuby at OSCON 2009 Mono, Moonlight, and scripting open source apps.

The short version of my take on the state of IronRuby is that it’s real this year. Last year and the year before, I talked about IronRuby but I really couldn’t show anything that I would actually consider putting it into production. This year, between the Gestalt stuff, the Witty app with the Repl/IronRuby scripting attached and many many more demos, I had some really awesome and powerful things to show people. I think I turned some heads.

It didn’t hurt that Leon Gersing, who wrote all of the labs and docs for Gestalt, was sitting in the back of the room. 

Why “Enterprise Tools” Are Bad for the Enterprise

Glenn Vanderburg did a talk the next time about the enterprise and how development goes there.

The first thing that Glenn did is rehash his first eRubycon talk on Ruby in the Enterprise. The quick summation goes as follows – “Here are tools that will let you build software quickly, cheaply, with below-average developers”….“Enterprise problems are not nearly as much technology problems as much as they are people problems.”…“You have to write Enterprise software with the expectation that it might still be in production in 30 years. I really liked that talk. These are drums that I’ve been beating, although not as eloquently as Glenn does, for quite some time.

Glenn then talked about a the state of the industry in the form of a case study with Verizon Business. The reality is that there are a number of enterprises that are starting to look at agile development and figure out how it will work for them. There are a couple of ways to go about that. There’s the whole sale change over, which have largely failed for a number of different reasons. The second way is to run a small pilot effort that tries a few small projects to prove things out. These largely succeed but there’s no real follow up.

The reality is that the overall organization might need to change in order set itself up for success. To demonstrate the point, Glenn talked about how accounting was done in manufacturing organizations of old verses today. At one point in time, inventory was considered an asset. While this makes sense on it’s face, it actually created a number of counter incentives for productivity and sales as factories started hording inventory and materials. This pushed a change in the industry to start looking at inventory as a liability. This pushes things like lean manufacturing and just in time ordering of inventory.

So, what we need to do is to start looking for those type of hidden counter incentives in the enterprise. These are actually not that hard to find, we just need to start identifying them and figure out how to articulate these incentives in the correct language for the business.

“Individuals and interactions over process and tools”

Context-Switching is one place where people loose a lot of time. This is not talking about multi-tasking, this is talking about having to change tasks quite often and have the change the mental model to work on.

The next topic was “One job at a time”. The idea here is that there are a lot of tools in Ruby that do one and only one thing. Cucumber is an example. It allows you to write a specific type of test but you can’t really get distracted and do other things while writing in Cucumber because it really only does that one thing.

The next topic was “Crazy as I wanna be”. The idea here is that enterprise tools try to sell you on the concept that with that tool you can do anything. And typically don’t have to write any code in the meantime. The reality is that the tools cannot replace smart people doing smart people. Ruby allows you to do whatever crazy things you want to do without having that crazy be the main stream. This is common for agile tools.

Glenn then started talking about the idea that you shouldn’t buy tools that have “Impenetrable Skin”. These are the tools that typically have lots of configuration options but if you have a need outside of the imagination of the original tools writers, you are stuck. Glenn prefers “Onionskin APIs”. These are the tools and APIs that you don’t have to crack up most of the time but you can if you have to. Rails and ActiveRecord are good examples of this.

Many enterprise tools are often large enough that they are they have their own ecosystem. What that means is they have their own group of people who’s sole job is managing and maintaining the tool. There are lots of examples of this such as databases, service busses and the like. The example that Glenn talked about quite a bit was ClearCase. The issue is that the tool is sold to the people that don’t use it all that much. These tools are sold to managers and project leads who use the tool an hour a week at best. It’s not sold to the developers who are going to use the tool 20 times a day.

The interesting issue is that as these tools start to gather their own ecosystem, the counter incentives start to mount. The use of the tool justifies the ecosystem which promotes the use of the tool regardless of whether or not it’s the right thing because it’s job security for them.

So many enterprises start by treating the symptoms verses actually fixing the problem. One of the treating the symptoms results is rules engines. Rules engines are not inherently the problem. The issue comes in when the rules engine is there because the engineering and development teams are unresponsive. The rules are really code but they are not treated as such. The result is that the people are making changes that are not tested and put through the correct rigor. This will eventually break and we’re back to the beginning.

The next set of symptoms that enterprises take on are really people problems. For example, why are there reuse repositories? Nobody uses them, ever. The reality is that reuse is far more of a people problem than it is a far more than it’s a technology problem. Requirements traceability programs are another great treatment of a symptom. The reality is that these problems are set up to assign blame. Many of the agile tools, such as Cucumber, leveraging index cards or Kanban boards get the benefits of the requirements traceability programs without the overhead and negatives.

The last topic is “Too much control”. The control that the business is really trying to force down is far less about moving forward than it is to keep people from making big mistakes. Too much control, however, stifles innovations and keeps people from making leaps of faith and trying new things.

To get the benefits that people are looking for with the control without the negatives, you need to ratchet up the communications and visibility rather than tightening down thing. Most of the tools in the agile and Ruby space fit this bill really well.

Panel discussion

Joe closed out the day by putting together a panel discussion with a number of people that have had success in the enterprise with Ruby.

Randal Thomas kicked off the panel with a story about a project where he taught a number of VB developers Ruby and was able to kick out and an application that was originally speced for 6 months in about a month. But the business freaked out and shut the project down. They went back and redid the project in “approved” technologies in about 6 months. David Bock followed with a similar story.

The topic quickly shifted to the idea that we really need to understand the business side and how to introduce ideas in such a way that you are not putting them on the defensive. David Bock and Glenn Vanderburg both recommended a book called Fearless Change: Patterns for Introducing New Ideas by Linda Rising.

One of the ideas is that they pitched is that you should start looking for allies. There will be a DBA somewhere that wants to run PostGreSQL and so on. Start quietly gathering that army and mount a campaign.

This is my third year at eRubycon. I’m thrilled to be involved and speaking again this year. I’m shocked every year when Joe picks me as a speaker. I’m just honored to be considered worthy of speaking on a docket with Jim Weirich, Glenn Vanderburg, Leon Gersing, Charles Nutter, Randall Thomas, Neal Ford and all of the rest of the amazing speakers that are here. It’s definitely one of my can’t miss conferences every year.

Joe O’Brien does a great job putting this conference on year after year. The logistics are smooth, the talks are great and the vision for the conference is crystal clear.

SOLID Ruby

Jim Weirich started off the day with a talk called “SOLID Ruby”. The whole talk is already up on github at http://github.com/jimweirich/presentation_solid_ruby. Jim is not only very informative but fun to listen to. I really like his delivery and sense of humor.

The first question that he asked is “How do you recognize a good design?” One of the things that Jim points out is that most people can recognize a bad design but we can’t describe what makes a good design. This is actually quite profound. How can we ensure a good design if we can’t describe what makes one? To demonstrate his point, he talked about the 1666 London fire and the subsequent plans to rebuild the city. He talked about 4 to 6 very distinct designs that were all presented to the king at the time. They actually didn’t build any of designs but rather did the first ever agile project with an incremental build and no huge design up front.

SOLID
S – Single Responsibility Principle (SRP)
O – Open Closed Principle (OCP)
L – Liskov Substitution Principle (LSP)
I – Interface Segregation Principle (ISP)
D – Dependency Inversion Principle (DIP)

SRP – Each class should have one and only one responsibility. You should be able to describe what your class does in a single sentence without using the words “and” or “or”.

OCP – You should be able to change the behavior of a class without having to modify it. This is the basis of inheritance. In Ruby, you can just open a class and “Fix it” right?

DIP – Jim took this one out of order because it made ore sense when trying to explain things. Depend on abstractions, not on concretions. In static language such as Java, C#, C++ it meas that you develop to interfaces. In Ruby, you don’t have to do that as there are no hard references to classes so you can swap out classes at will. If you want to swap out the class, you just have to have all of the methods that the code that leverages that class call. Jim calls this coding to a protocol verses coding to a spec or interface.

LSP – the question answered here is how do you know if you can swap out two classes? The reality is that it’s more than just are the methods require present. It’s what are the promises back as well. For example, if you have a square root function but you require a certain level of precision. From the LISP community, Jim pulls the phrase “Require No More, Promise No Less”. If you are well covered on testing, this will be automatic.

ISP – Make fine grained interfaces that are client specific.

To finish up, Jim opened things up for discussion but in traditional Jim fashion he did things a little different. He brought the questions for the discussion.

First question – “ActiveRecord objects implement a domain concept and a persistence concept. Does that break the SRP?”

Next question – “How do you verify that your client software only uses the (narrow) protocol you expect”?”

Next question – “Some SOLID principles are an awkward fit for Ruby as they were built for static languages. Are there design principles from dynamic languages that are awkward fits for static languages?”

One of the key points that Jim implicitly made is that Ruby the language auto-implements many of the SOLID principles and the the culture pushes the rest of them in great ways.

Testing the Enterprise

I was really sorry but I had to miss this talk. I’m planning on getting a summary from the speakers later tonight and posting some notes later. They posted their slides at http://fallenrogue.s3.amazonaws.com/Testing%20the%20Enterprise.pdf.

In short, Leon Gersing and Charley Baker have been working at the Gap on a large project. A big reason for the success of the project and the team is the rigor around testing.

I asked Leon to email me a short write-up and this is what he sent me:

+++++++++++++++++++++++++++++++++++++++++++++++++
“Testing the Enterprise” is about how we brought Ruby testing into Gap Inc Direct. GID has campuses in Columbus, San Francisco and offshore. In addition to the challenges in a distributed environment, training QA resources and developers new to Ruby, Watir, other libraries; we’ll be talking about incremental adoption of Ruby in the Enterprise, and how it enables us to move from a Waterfall SDLC into an Agile model.
We’ll be going over lessons learned, pitfalls and successes. The points of view will be from Leon Gersing, who has been responsible for the adoption of Ruby at our San Francisco campus over the past 4 years, and Leon Gersing from EdgeCase, who’s working with our Columbus distribution IT organization as they adopt Agile practices and using Cucumber have bridged the gap between developers, QA and product teams.
+++++++++++++++++++++++++++++++++++++++++++++++++

Rails in the Large: How Agility Allows Us to Build the World’s Biggest Rails App

Neil Ford came in next and talked about the largest Rails applications known to man.

The application itself is a car wholesaler web site called http://ove.com. He started out talking about how the project came about in the first place. They had a huge complicated web site built in Java. They were looking to do a ground up rewrite in either .NET or Rails.

Neil asked them “There are 300 Java developers downstairs, why don’t you want to rewrite it in Java?” The answer was “Frankly, we don’t want them to touch it.”.

Neil convinced them to go with Rails.

They started out in January of 2007 and built the team at 1 new pair of developers to the project every two weeks. At this poin
t they have 11 pairs of developers, 8 business analysts, an iteration manager, 6 quality assurance, a project manager and a client principle.

One of the key points that Neil made here is that “technology isn’t as important as responsiveness to business needs”. There are a lot of people in the technology world that don’t get that. The reality is that most customers don’t care about what the underlying technologies are, they only care that their business requirements are met.

One of the things that Neil pointed out very strongly, and actually spent a lot of time talking about, is the importance of the testing and specifically the way that they did them. One of the interesting stats that he threw out is that they have 3.2 lines of test code for every line of production code. There’s currently close to 100k lines of test code.

Obviously, this is a lot of code so they have had to pull together a number of other resources and tools to put together to actually run all of the projects. One of them that struck my fancy is DeepTest. It can do distributed testing of your Ruby code. Another one is Selenium grid. This does distributed running of Selenium tests.

One of the side effects of all of this distributed testing is that they have no setup and tear down methods in the tests. Rather all of the tests are completely standalone.

There were a number of social engineering things that they did that were very successful. They have a theme song for broken builds and theme songs for each person that plays on a successful check ins.

Agile, Rails and the Cloud: Why companies can’t afford to ignore the efficiencies of modern development approaches

Ian McFarland finished off the day with a talk about why modern development approaches matter to business. This is a very important thing to talk about and think about for businesses. The reality is that not nearly enough people spend time considering.

He started talking about Agile development and walked through many of the core tenants. He put forth fairly compelling arguments that you really do need to follow the tenants of Agile. For example, having the customers setting the priorities on the things that you are building matters because it helps you produce business value faster. He spent quite a bit of time arguing that you really do need to do paired programming. Everyone learns more faster, gets distracted less and the team knowledge goes up dramatically.

After that, he switched to talking about Rails. He’s got data that switching from Java to Rails proved out to have have 2-4x productivity gain for the developers.

Then he talked about the Cloud. To steal words from Brian Prince to help paraphrase Ian’s thoughts here – “Don’t be a plumber!”. Unless it’s critical to your business to run your own infrastructure, you should outsource the infrastructure. Actually, he made a strong argument that you should outsource a number of things. As I’ve said for a long time, if it doesn’t add to your companies stock price, why are you building it? There are times that you have to run your own infrastructure such as regulatory issues or business needs that make it more advantageous to have it internal.

At the end, he made a very contentious statement that Rails is not ready for the Enterprise. There are a number of reasons for this and mostly it comes to the fact that Enterprise is actually not ready for Ruby. The actual barriers are being solved. For example, companies such as Engine Yard are solving cloud issues and the like.

 

Now for dinner – more tomorrow!