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.