The New Road

What I learn from Project Runway

Chongo replied to my Ruby rant, and gave some wise insights that it's about the people and not the language. That's very true. What I find is that engineers have development styles that they fall into. For example, some like to experiment, make lots of versions, and see what works and what doesn't. Others like a more spec'd approach. You give them the spec, they write the code, if the code equals the spec the project equals done.

Organizations generally fall around those types as well. Some have a lot of process; the marketing people talk to the customers, then talk with the architects, the architects then translate that into designs and then engineers implement the designs. Where other organizations have the engineers talk directly with the customers, then deliver pre-release code to get feedback directly from the customer, and make changes to match.

I call that latter approach the 'Project Runway' approach, since it's what they do on that show. The producers come up with some idea, they tell the designers. The designer then work on something. Then the host comes in and gives them feedback. Then they incorporate that and release it. Obviously, more cycles of feedback would often times be better. But what are the advantages? Lots of clothes are produced. Some suck. Some rock. But at least stuff gets out there. Plus the cycle time on development is reduced. And bad design ideas get killed early.

If Project Runway were run like spec-driven process-heavy software shops it would look like this. There would be three levels of people between the customer and the clothes. The marketer would talk to the customer and get some 'general impressions'. For example, the customer likes crocodile skin handbags. Then they would talk to the architect who would broaden those 'general impressions' into some wider perspective. At this point the design would be something like; build a object toting system with interchangeable exterior elements. Since two days is lots of time, this process of broadening the marketing ideas takes one and a half days.

All the while the engineers who are actually going to construct the clothes, not knowing anything about what's going on, spend there time building the perfect sewing machine that can create sails for sailboats in two minutes. When the engineers are finally given the "object toting system" design they scramble because they only have four hours left in the two day schedule to build the impossible. Obviously their amazing sewing machine was a complete waste of time, since they aren't building sails for sailboats. So they scrap that. Somewhere along the line one of the engineers finds a paper bag. They glue some random felt cutouts on it and deliver it to the marketers. That matches the spec. Job complete! A job well done all around.

The result? The customer, having told the marketer that they specifically wanted a crocodile skinned handbag is drop-jawed at the sight of the paper bag with felt cutouts.

Unfortunately, this is what happens so often in software jobs. The engineers are either too close to the customer, and are driven mad by ever changing requirements. Or so far away from the customer that they have no idea who is going to use what they build, or how they are going to use it.

This is why systems like Ruby on Rails appeal to me. I'd much rather error on the side of being too close to the customer. I like to spend some time with them, see what they want, go off and prototype something simple, then bring it back and say "Is this what you mean?" Then get their feedback, incorporate it, and continue the cycle. Yes, it's hard to know when you are done. And yes, it means lots of code rewrites. And yes, it means lots of schema changes. But that's natural. It's software, which means that you can change it.

I know when things are bad in the heavy process world when the engineers sit around arguing about technology stacks, or the size of fields, or they spend their time writing random pieces of technology that don't relate to what the company is doing (the sewing machine specifically for sails on sailboats.) It's busy work. And frankly, it's safe. The engineers can always say they 'were working' and 'solving problems'. When really all they were doing were debating the fine points of computer science. The hard work is in solving actual customer problems.

After I wrote the Ruby rant I had a look over at The Server Side to see what they thought of Rails. The Server Side is all about Java technologies. It's obnoxiously named The Server Side because it implies, wrongly, that Java is the only legitimate implementation language for web servers. Anyhow, the rant against Rails was exactly as I would expect there. It's all about the implementation, without any mention of how Rails could actually help get customer working functionality sooner. Threading and scalability FUD this. Domain model that. EJB and JDO this. And XML configuration that. Whatever. Java certainly supplies ample material for computer science debate with it's forty-five different persistence technologies, and more language specs than you can shake a stick at.

This is why Rails wins and Java loses. Chongo is right. It's not about the technology stack. It's about the teams that use it. If the team is close the customer and rapidly iterating to get to the customer requiements, which is really hard work, then it will win. And Rails allows you to do that. If you just sit around all the time debating tech, and ignoring the customer, then you are going to lose.

I particularly enjoy the scalability FUD that Java folks sling at Rails; "Ok, Rails scales to thousands of transactions, but what about billions." My answer is simple. If the application needs to handle billions of transactions, then the problem I'm going to have, is how to spend all of the money from my options. And it will be some other poor chumps problem to get Rails to scale to billions of transactions. No canned system, not Java, not .NET, not Rails, handles scalability seemlessly. Google doesn't use any standard technology stack. They can't. It's all custom. The only real scalability solution is innovative engineers who can adapt quickly and solve the scaling problems that pop up where you least expect them.

P.S. This is why .NET wins as well. .NET projects ship. They ship crap spaghetti code. But they ship, and that's what counts. IMHO, Rails is better because there is less code, less spaghetti, and more inherint structure to the project. Rails has inherint opinions about stuff. This is a view, this is a model, this is how you connect wih the database, this is how you do HTML, so on and so forth. And that will help drive Rails adoption because most people will be doing things the Rails way. So it will be easier to hire for Rails skills.