Primary Menu

Category Archives: Conference

I’m thrilled and honored to be doing another speaking tour through Europe. I’m getting to visit a number of countries that I haven’t visited before and some old favorites. I’ll be speaking on PHP, Ruby and other non .NET technologies on Azure.

The talk that I’m going to be doing in most places is PHP/Ruby on Azure or Leveraging Azure with Non-Microsoft Languages:

Windows Azure is Microsoft’s Cloud Computing offering. It is more than a simple scalable hosting option as it is truly a platform as a service offering. This allows you to focus on your application rather than the configuring and managing your infrastructure whether you are writing C# or VB.NET or even languages such as PHP or Ruby which are first class citizens in Windows Azure. The Windows Azure Platform includes Windows Azure, which is the OS and hosting environment for web and background services, as well as non-relational storage, queues, and a blob storage for everything from videos to mountable virtual drives. Additionally, the Windows Azure Platform includes SQL Azure, a fully relational database as a service, and Windows Azure AppFabric for industry standards compliant identity management and a service bus for message passing.

But there remain the questions around why, when and how you should move to the cloud, especially if you are using PHP or Ruby. Should I put everything in Windows Azure? Do you have to convert everything you have to ASP.NET? Do you have to write code specifically for Windows Azure? What if my current applications depend on MySQL and/or memcached?

There’s a lot of good news here as it is relatively straight forward to get running in Windows Azure. Once your application is running, however, now you need to look at how to fully leverage the platform offerings architecting for the best usage of the different roles and the various aspects of the Windows Azure offerings such as the AppFabric and SQL Azure. This will help your application make the most efficient usage of CPU, bandwidth, storage and all of the things that cost in a cloud hosting scenario.

In this half day session, we will begin with the why of Windows Azure talking about when it makes sense to make a move and what the prudent migration paths are for your organization. During this time we will tour the various aspects of Windows Azure. Then we’ll delve into the technical aspects of how to run your PHP/Ruby code on Windows Azure. Once we have that mastered, we will move onto leveraging the Windows Azure platform to its fullest.

The full schedule is as follows (and yes, this is a lot of countries in not very many days)

I love Ireland. I hope to someday live there. I spoke there about a year and a half ago on RIA and got to meet a few of the folk but mostly worked with Martha Rotter. I got to make a number of friends last time and I’m really looking forward to seeing them again.

This is my first time to Portugal. I’m really looking forward to meeting the local DPE team (Luis Alves Martins and Sergio Martinho). I’m speaking at the university. it looks like a beautiful venue – http://bit.ly/avsYU9. I just wish that I had more time here to explore the local culture.

My brother has spent a lot of time in Austria but I’ve never been. I have met Mario Szpuszta back when he and I both spoke at JAOO in 2008 in Denmark. That was an awesome conference. I’ll also get to met Rolf Mistelbacher. Another thing I’m really excited about is that I’m going to spend enough time to actually see some of the city.

At PHP UK, I’m actually not talking about Azure. Rather I’m doing a keynote titled The Lost Art of Simplicity (Full slides on slideshare). This is actually the original reason that I’m coming to Europe in the first place. I’m honored to be asked to do the keynote and am beholden to Scott MacVicar for the invitation and to Johanna Cherry for making everything work smoothly.

Also, as a side note I’ve met a bunch of people from Norway while at the PHPUK conference and they’ve assured me that the polar plunge was decent training for my visit but I’d enjoy it regardless.

March 4 – Amsterdam, The Netherlands – PHP User Group

I haven’t actually met Bram Veenhof in person but have been working with him over the past couple of years on a couple of things.I’ve been to Amsterdam several times but mostly just to the Airport and the Microsoft offices there, both of which are awesome. I’m thrilled this time to actually have a little time to explore the city.

I’ve been to Brussels once before and I’m really looking forward to going back. I’ve not get Katrien De Graeve and Rudy Van Hoe but are two of the other people that I’ve been working with closely over the past couple of years.

March 6,7 – Kilkenny, Ireland – hanging out and speaking at Wordcamp Ireland

Again, I love Ireland and hope to live there someday. I’ll be in Kilkenny at Wordcamp Ireland.

It’s going to be a lot of fun and I’m really hoping that there’s lots of good conversation. Please let me know via comments or via twitter if you’re able to make it to one of the sessions.

If you tweet about this – please use the hash tag #phpazuretour and #cityyourecomingto!

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.

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:

What is RIA?

What technologies are considered RIA technologies?

When should you use RIA?

When should you not use RIA?

What’s the learning curve for desktop developers to jump into RIA?

What’s the learning curve for web developers to jump into RIA?

What are the best practices for RIAs?

What are the worst practices for RIA?

How does one deal with multiple form factors?

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.

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:

What is Scale?

What’s the difference between Scale and Performance?

What are the ways to scale an application?

How do you determine what scale you need?

What is cloud computing?

What is Azure?

How well does PHP work on Azure?

What considerations are needed to run on Azure?

How do you geo-locate an application?

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.

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.

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.

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.

“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…”

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.

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.

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.

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.

I recently did a keynote at the Central Ohio Day of .NET and a session at Kalamazoo X called “The Lost Art of Simplicity. I have to say that I’ve not been as excited about a specific talk in quite a while.

I posted the slides to SlideShare and I’ve signed up for speaker rate for this session. I would love some feedback.

The Lost Art of Simplicity – Presentation Transcript

sim·plic·i·ty (sm-pls-t) n. 1. The property, condition, or quality of being simple or uncombined. 2. Absence of luxury or showiness; plainness. 3. Absence of affectation or pretense. 4. a. Lack of sophistication or subtlety; naiveté. b. Lack of good sense or intelligence; foolishness. 5. a. Clarity of expression. b. Austerity in embellishment.

Let’s start off by talking about what simplicity is. The official dictionary definition has 5 parts. We are going to focus in on the first definition. Simplicity is the property, condition or quality of being simple or uncombined. This is a beautiful statement that is unfortunately missing in much of our current application development.

When we talk about something being simple, often people just right to the fourth definition assuming that it’s lacking sophistication or good sense and intelligence. That it’s foolish. As technologists, our tendency when we see something that’s simple is to say “Oh, I could write it in a weekend”. There’s a fair amount of NIH (Not Invented Here) tendencies that are just part of our culture. This is a dangerous concept.

The last definition is the one that I really like. To have a something that has “Clarity of Expression” is awesome. Put that with the first definition and we really have something. I’m striving to solve problems in ways that are “Simple and uncombined” with “Clarity of Expression”.

One of the great things about the human race is that we are a race of problem solvers. And we take great pride in our solutions. The issue is that the solutions that we are most proud of are the ones that only we can understand.

The best ideas, however, are the ideas that are immediately obvious once someone shows it to you. It’s that head smack “Duh” moment that accompanies those great ideas that I really like.

Can I get report of sales by geography? How about splitting that by demographics such as age or gender? What’s the effect of our current marketing efforts on sales of our latest line and how does that differ by geography or demographic? Could I enter a contact I met at the picnic into our CRM? Could that be blue?

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and
a lot of courage — to move in the opposite direction. – Albert Einstein

Our biggest fear is that the user is going to go get a copy of Access or something equally destructive and try to solve the problem themselves. Often they can effectively solve the short term problem and in the process bring down the enterprise…

And this is a dangerous thing because as they open up the simple tools such as access and solve just their problem, they are potentially causing other issues like data redundancy throughout the company or duplicating efforts with another group. Often these solutions are even done with ignorance to larger concerns such as privacy laws.

Even so, they are solving their problem in the short term and that was their goal.

Most of the fundamental ideas of science are essentially simple, and may, as a rule, be expressed in a language comprehensible to everyone. – Albert Einstein

To head that off, we just, we start throwing our favorite technologies and designs at the problem to solve it in the most “elegant” way. This quickly results in over engineering the task at hand.

One immediate and obvious danger is that we take that simple request and roll it into the next version of the application that’s going to be 18-36 months down the road ignoring the fact that it’s a pain that the user is feeling today. What happens when, 18 months down the road, the user that has requested that feature has solved the problem some other way? Or if that user is not even employed by the company anymore?

It takes a long time to make something complicated simple, but if you do, it will work w/o problems for a long time. – F. Andy Seidle, http://faseidl.com/

And the solution that results is not only over engineered but it’s reminiscent of a certain coyote with all of the possible ways that it can fail. The reality is that the more complex a problem is, the more ways that it can fail.

As a solution ramps up in complexity and “cleverness” it quickly becomes more fragile because there are more moving parts and more possible points of failure. Just because something is using the latest or coolest technology, doesn’t mean that it’s the best idea. If that latest or cool technology reduce complexity in some way, such as reducing the number of tools, streamlining process or raising the bar on the usability then there is a good argument to leverage it.

The Innovator’s Dilemma that disruptive innovations are almost never the result of technological breakthroughs but are instead recombination’s of existing and often inexpensive technology in forms the former market leaders don’t pursue. – Clayton Christensen

In all of this, we are missing the obvious. There are known simple solutions to a lot of the requests that we get on a day to day basis.

The first thing that we have to get over is the NIH complex that we all have. When you get a new request is your first thought, I can build that… Or is your first thought, I bet that’s been built…

The second thing that we have to recognize is that the simple solution is probably the right one. If the solution that we have come up with is a so complicated that we are amazed with ourselves and proud of it, it’s probably the wrong direction.

Dealing with complexity is an inefficient and unnecessary waste of time, attention and mental energy. There is never any justification for things being complex when they could be simple. – Edward de Bono

We can’t keep down this destructive path of building more and more complex solutions that take eons to develop when the users have needs that we are not addressing in the short term.

We need to be very careful about the lure of complexity. We should not fall into the trap of thinking that if it’s hard to design, it must be good; that if it’s using the latest technology, it must be good; that if all our friends think it’s really cool, it must be good. – Gerry McGovern

We, as the IT world, tend to go rampant with technology with little to no thought to the consequences. Even though we are trying to make people’s lives easier, at best we do no harm. At worst, we cause a lot of pain and anguish for our users.

The answer that a lot of us, and I’m guilty of this too, turn to is to vet our ideas and our UI designs with our peers. The issue is that our peers are also technologists who are just as geeked as we are about X new technology. This just perpetuates the problem.

Things should be made as simple as possible, but not any simpler. – Albert Einstein

Let’s take a short step back and examine how complexity comes to our applications in the first place.

Often complexity sneaks in under different names. One of my favorite is “Enterprise” which almost automatically means a complexity multiplier of 10. The idea here is that we have to be “Enterprise Quality”. This implies a certain engineering rigor, stability and scalability. One huge issue that I have with this term is that if you look at a mid to large sized enterprise with 10k, 20k or even 50K users you are still looking at a user base that would be considered a rounding error on some of the larger consumer facing applications such as Facebook, Twitter, Wikipedia and the like.

The whole point of human-centered design is to tame complexity – Don Norman

Often the complexity is as simple as not understanding our users.

I was recently in a long envisioning session with a customer about the next version of their client facing applications. We spent a lot of time hashing through their current application and came up with a number of ways that we might be able to save time or give a better experience. But at some point I backed up and asked the question, what are the top three things that your customers do with the application? If we knew that, we could focus on surfacing those to three tasks in the UI to help cut complexity and time out of the user’s day. The reality is that they couldn’t answer that question. There were some guesses and opinions thrown out but nothing definitive that they could throw out. Their homework assignment was to go back and find that out.

I find this as an issue in a lot of customer engagements. Very few companies actually know how many of their users are using Windows 98 or IE5 but there is an assumption that it’s an issue so a lot of complexity is built into the system in order to accommodate what might very well be a small portion of their audience.

The other side of this issue is that there’s what the users say that they want and what they actually need. There are some simple examples. “Could you Web 2.0ify my site?” “I need a X (where X is some buzzword that they just read in some article) technology application” Or any other place where technology enters requirements. This is where we need to redirect the user’s requirements by asking them about their goals and aspirations and then start figuring out what they need from that. “Oh, you want to cut down on the amount of text that your users have to type while increasing the accuracy of their reporting? How about we replace that block of text by allowing them to select a picture of what they are looking for? Yeah, we can do that without requiring them to wait on the page to reload.”

I apologize for the length of this letter, but I didn’t have time to make it shorter. – Mark Twain

An unfortunately common problem that I see in the industry is that given group of developers knows one or two technologies and approach every problem with that technology as the solution. The reality is that that there are tremendous number of technologies at their disposal from web applications to desktop applications to mobile applications to hybrid solutions of all of those. You need to approach each problem with an open mind as to what is the best solution for that problem. Sometimes you’ll find that the solution is not actually a technical solution at all.

The real solution here is to take the time to explore all of the possible solutions, technology based or not.

\”Think simple\” as my old master used to say – meaning reduce the whole of its parts into the simplest terms, getting back to first principles. – Frank Lloyd Wright

There’s, unfortunately, not a magic solution to the issue of complexity. Simple is hard.

Often you have to come up with several complex solutions that you can boil down to the simple solution. Often, in an effort to find the right solution, I will solve or at least map out solutions to a given problem in several different ways with a number of technologies ranging from desktop to web to mobile to non-technology solutions. Kind of like going to a shoe store and trying on a ton of different styles and sizes of shoes, you can get a lot of interesting ideas from checking out al
l of the different solutions. You might be surprised by the solutions that make the most sense at the end of the day.

Simplicity is not the goal. It is the by-product of a good idea and modest expectations. – Paul Rand

All of that said though and as much as I’m talking about Simplicity in this talk, the reality is that Paul Rand has it right. “Simplicity is not the goal. It is the by-product of a good idea and modest expectations”.

Never again will I make the simple into the complex. Something of true value does not become more valuable because it becomes complicated. – Donald Curtis

One of the biggest problems is that we try to, for a large number of reasons, try to boil the ocean with our applications. When we build out our project plan and it’s going to be an 18 month cycle before the users get a new version, they are going to go to battle tooth and nail to get their feature request on the docket because they know that if they are not able to get it in this release, it’s going to be at least 36 months out. All of these features crammed into a release adds not only a lot of complexity but a lot of risk to the endeavor.

We have to get past the misperception that features equal value. Features do not equal value. Solving people’s problems equals value. The amount of complexity and risk that we add with these massive project plans hurt out ability to solve someone’s problem in a reasonable time frame.

The ability to simplify means to eliminate the unnecessary so that the necessary may speak. – Hans Hofmann

You need to start small. Even if you know that the end game is far bigger, what’s that first step? What’s the minimal set of features that you need to get started? This is a struggle for a lot of people as we all want to go for the big vision. The natural tendency is to think that more is better but in a lot of cases, more just gets in the way of success.

This is a core concepts that groups like 37 Signals have held. Their motto is that the first order of business is to get running and start building a customer base. You can worry about scaling later. But if you spend too much time worrying about scaling up front, you’ll never get out there to build the customer base in the first place.

On the other side of the coin, you need to have a clear concept of the future as you are getting started. I often see applications that are built with no concept future requirements and accidentally build in roadblocks to success. There are a lot of simple things that you can do that will future proof your application to some degree. It’s not hard to build in, if you start from the beginning with a tiered and separated architecture so that you can replace bottle necks if they start to pose a problem.

This is sometimes a hard balance to hit but it’s an important one to tackle.

There are a lot of straight forward things you can do such as adopting some of the great architectural patterns such as MVC (Model View Controller) or MVP (Model View Presenter) combined with great practices such as Test Driven Development (TDD). TDD is more than just building regression tests. It forces you to design and build your application in a modular fashion that allow you to make changes and modifications to your application quickly and with confidence. MVC and MVP are architectural patterns that work well with TDD and provide for great separation of concerns to further provide the agility that you need to grow and scale your application over time.

The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features. – Nielsen Norman Group

So where to from here?

As I look into the future, I see a world where we are working hand in hand with our users to solve their real needs rather than reacting to what they say that they want and confusing checklists of features with value. I dream of the day when we are able to respond to the users needs as quickly as we can get them to express those needs to us to the point of being able to forecast and proactively provide exactly the functionality that the user needs, nothing more, when they need and not a moment before they do.

To do that, we need to forgo our egos, our love of complexity and our die hard grip on our favorite technologies and focus on the user.

All artwork used in this presentation is licensed under Creative Commons by Frits Ahlefeldt, aka hikingartist Support his amazing craft at http://hikingartist.com

Before I finish, I need to say a quick thank you to Fritz Ahlefeldt. He’s a Danish artist with obvious talent. He publishes a large amount of his work under creative commons. If you like this art, you can see much more at http://www.hikingartist.com and support him and his amazing craft.

I’m looking forward to evolving this talk as I move towards CodeStock and DevLink. I know that there was a really nice progression in just a week between Central Ohio Day of .NET and Kalamazoo X as my message got a lot crisper and more direct based on a lot of great constructive advice I got from Michael Eaton, Michael Wood, Jim Homes and more.

The Kalamazoo X conference, while being put on by the technical community, is a very different sort of conference. You’re not going to hear “technical” talks. All of talks pertain to technical folk but it’s a step back from the nuts and bolts that we usually deal with day in and day out and focusing on the topics that are really important.

Jeff Blankenburg will be giving Six Tips for Improving User Experience. Jeff is one of those amazing people that cross easily between the designer and developer world and can talk to either group with complete credibility. Again, he’s bringing great experience to the table as his roots in development are in the digital marketing arena.

Leon Gersing will lead a discussion about Change. Leon is a great software craftsman who has worked in all types of development shops from large consulting shops and independent software vendors to the small and nimble consulting shops working in technology ranging from his much loved Sharepoint to Ruby on Rails. His deep passion and experience combine to make him a dynamic and engaging speaker.

We have the great fortune to hear from Jim Holmes twice speaking on 3 Tips to Improve Your Development Process and Leadership 101. The first talk is a great talk that is important to anyone doing development regardless of their current process, tooling or any other variables.

Jim’s second talk on Leadership 101 couldn’t be given by a more perfect guy. Jim is a born leader in the truest sense of the word. Management, as a role on a team, can be given to someone regardless of their qualifications. Leadership is proven and earned over time. Jim’s led the CodeMash conference, which he downplays but he is the head cat herder. He doesn’t play a “management” role but rather leads through great thought leadership, influence and enablement of the people around him. But he knows when the buck has come to his desk and he has the ability to make those hard decisions that are required of a true leader. I’ve heard Jim speak on similar topics in the past and I can attest that he’s bringing real world hard fought battle proven experience to the table. You can get some of his thoughts on the topic reading his blog post about Leadership 101.

Brian Prince will be reprising his Soft Skills talk. This is a great talk that speaks to the non-technical side of our jobs that we all need to work on. I’ve seen, and actually delivered once when Brian came down with the plague the night before the Grand Rapids Day of .NET, this talk before. It strikes to the heart of how you, as a technical person, need to work on and grow your soft skills. It’s not fuzzy feel good bits, it’s things that will actually help you in your career.

And I’ll be speaking on the Lost Art of Simplicity. I’ve decided to go to war with complexity. Simplicity is a lost art in the application development space.

The Wikipedia definition of Simplicity is “Simplicity is the property, condition, or quality of being simple or un-combined. It often denotes beauty, purity or clarity. Simple things are usually easier to explain and understand than complicated ones. Simplicity can mean freedom from hardship, effort or confusion.”

This is a beautiful statement that we often lose sight of when we are building our applications. Instead we are on a never ending quest to fill out a checklist of features or to build something clever forgetting about the actual needs of our users to get a specific task done. This session takes complexity to task and challenges you to bring simplicity to the center of your development with some straightforward ideas and guidance.

Best of all, you don’t have to choose between the all of these great sessions. I was terrified that I’d be in a time slot opposite of Jim Holmes and A: miss his talk and B: have to compete with him for audience.

As per the announcement by Michael Eaton, the conference format has been radically altered to be a single track conference with 20-30 minute sessions rather than the typical 4 track conference with 70 minute sessions. This will let me catch all of the sessions and it gives a new energy to all of the sessions as the speakers have to stay very tight to their topic and come with high energy to hit the time limit. I’ll be working with Mike to make sure that we have the hook ready to go for people that go over. That might include me…

As you can tell, the Kalamazoo X Conference will be a very different conference than you’re used to. Now, it does cost $20.00 for professionals and $10.00 for students. That’s a VERY reasonable price for the quality of the speakers, topics and format that the organizing committee has been able to assemble.

Wow I’ve been swamped. There’s so much to blog about in the past couple of weeks so I’m just going to catch some of the highlights.

Ann Arbor Day of .NET was on 5/5/2007. It was fantastic! It sold out at 250 people and of that there were 210 people show up. That’s actually really good as most free events have a 40% droppoff and they had less than 20% droppoff. The only downside on the day was that with less than a 20% droppoff – pizza was a little short at lunch.

They are actually thinking about going to every 6 months instead of every 12 months. I think this would be fantastic!

I kicked off the day with a session on User Experience technologies at Microsoft. I borrowed from some of the materials that we are putting together for the upcoming ArcReady (Check the site for dates and times across the entire central region – Detroit on 5/25 in two weeks for all those that attended Day of .Net). We dipped into WPF, AJAX and Silverlight. My favorite demo is the Silverlight Airlines Demo. It shows a truly out of the box user experience that’s not all glitz and glammor but a truly solid UI for a true business application. Many of the demos, while showing off the platform really well, are marketing apps that show lots of 3D and animation. My customers often look at the glitzy demos and say that they are not doing 3D so they don’t look at the technologies. What they are missing is that there are real benifits here with enabling truly rich interfaces that go well beyond text and pictures.

I had two more 30 minute sessions. In both of those sessions the overwhelming requests were to have more Silverlight content. I had nothing prepared for these sessions but they went really well. In the first session, I pulled Don Burnett, who started Michigan Interactive Designers, out of the crowd and asked him to do a tour around Expression Blend and Silverlight. He got up, completely unscripted, and did a fantastic job! I will definitely be bringing him in to do more demos and presentations – especially when we have a designer based crowd. It turns out that he used to work with Bill Wagner (my former business partner when I was at SRT Solutions) on the Lion King Animated Storybook.

In the second session, I was on my own but I showed Top Banana, the DLRConsole (python and javascript version – IronRuby will be released as a CTP from CodePlex later this year) and talked about the .NET support in Silverlight 1.1 Alpha. Yes – I actually wrote some Python and did a simple overview for people at the conference. It was a fun day!

Here are some of the resources that we talked about during the three talks:

I’m not normally overly excited about the large Microsoft events, however, I’m really looking forward to the MDC Detroit next week.

The idea behind the show is that it’s taking the most critical sessions from PDC and repackaging them in a one day format.

I’ve had a chance to go through a lot of the content and see what all is going to be show. The cool part about it is that the vast majority of the talks are doing a demo. This is a big departure from a lot of the multi-city roadshows that Microsoft puts on and it’s a good thing. You’ll actually get to see code running. You’ll see applications being built. The other thing is that these demos are real world. It’s not hello world style demos. In my talk, I’m actually building a full line of business HR application that reads and writes from the database.

The talk that I’m doing is the Silverlight talk. Those of you who know me are not shocked by that. 🙂 The cool part is that there are two parts to the talk. First, I’m going to show what you can do with current and shipping technologies. Then I’m going to show you what’s coming next.

Web technologies not your bag, there’s still plenty to see. Specifically, there are three different tracks. I’m in the Client and Presentation track. I’m just happy that there’s a lunch between me and Billy Hollis. That’ll give the audience to forget how awesome he was before coming and hearing me.

AGENDA

Time Table

Azure Services Platform for Cloud Computing

Client and Presentation

Tools, Languages and Framework

7:00-8:30

Registration and Breakfast

8:30-10:00

The day starts off with a keynote presented by Ron Jacobs. If you’ve not heard Ron speak before, you’re in for a treat. He’s a dynamic and engaging speaker on any topic.

The Professional Developers Conference (PDC) is one of my favorite conferences. But it is an investment, especially when you factor in the cost of airfare and a week in a downtown LA hotel, in addition to the cost of the conference. In today’s unstable economy, some people missed out on a lot of cool technical content.

But, the MSDN Developer Conference (MDC) is bringing the PDC to you! The MDC is a day-long conference with three parallel tracks, summarizing the essentials of the PDC, for only $99. These events will be held in 11 major cities across the US. Hear all of the exciting announcements around the Azure Services Platform, Windows 7, and Visual Studio 2010 – the session lineup is pretty compelling.

And of course, there are great giveaways and swag! The most exciting thing is that all attendees will receive a Windows 7 Beta DVD. If the Windows 7 Beta is not available at the time of the event, the DVD will be shipped to you when it becomes available.

There are other worthwhile gatherings happening at the MDC:

Community Courtyard: Perhaps you’ve seen the PDC content already, but want a chance to discuss it? Maybe you have questions or still just don’t get what the excitement around Azure is all about. The Community Courtyard is an Open-Space-like environment, where attendees can propose topics to discuss and convene their own sessions! Leaders in the development community as well as Microsoft employees will be hanging around to answer questions and participate in the conversations.

WomenBuild: This interactive workshop is open to both men and women. Participants utilize Lego bricks to explore different solutions to the same problem, and celebrate the true meaning of diversity.