I started messing around with Ruby on Rails for the first time on Sunday. This was after spending all day Saturday tearing down kitchen cupboards, tiled sinks and entire walls for a friend who is remodeling his house, so I got my fill of building last weekend whether real or virtual.

Photo: bruce grant

Trying to figure out how Ruby on Rails worked, I felt like I was remodeling my brain. It was as if I walked into Ikea with just a basic idea of what I wanted my new kitchen to look like and then walked out with design schematics and new appliances an hour later. I suddenly had confidence that I could create a really nice web site with a lot of functionality that was basically inaccessible to me before because of my limited programming background.

The “Ah hah!” moment came for me when I added two words to one of the scripts: “scaffold mydatabase”. When I refreshed my web site, I was adding, editing and deleting data in my database via a web interface. It all automatically just worked. Then literally 15 minutes later I had 2 databases talking to eachother.

It’s mindblowing how much power this environment gives to people who aren’t true coders.

I have a feeling I’ll get stuck and frustrated with what I’m trying to build. But I’m very hopeful Ruby on Rails will get me closer than I could with open source PHP tools. If nothing else, I’ll get a sense for this new trend.

Programming seems to have about a 3 year fashion cycle that also intersects with influxes of new ideas for web applications and a full cycle of students coming out of university. Now we’re at the early stages of a creative explosion on the Internet enabled by things like Rails, open APIs, storage solutions like S3, and JSON. And you can also wrap an idea in any number of different business models in even less time than it takes to build the product itself.

Maybe instead of LAMP (Linux, Apache, MySQL, PHP), we now have RASH (Rails, APIs, S3, Hosted).

There must be similar reactions to breakthroughs in the construction industry when things like cross-linked polyethylene (PEX) hit the market. Of course, construction suffers from bad naming as much as any other trade. Not everything can be as cool as a sawzall or funny pipe.

One of the teams I’m working with has adopted a sort of customized agile-style development process. I really like it, but a few problems are coming up:

1. Just like after a heavy workout, you need a warm down of some sort. You can’t just suddenly stop and declare victory after a sprint. There are always a few more things to do, and your brain muscles need to flush out the acids that built up during the race. And just like that feeling the day after a good work out, it’s hard to actually get momentum going again, and a cheerleader only makes you bitter.
2. Collaborating with other teams in the company is very tricky. Team independence is crucial to the agile process, but that means no two teams are ever in synch. It’s like IM’ing with a friend in Europe. You can catch them for a few minutes in the morning if you get into the office early enough, but by the time you’re ready to actually say something, they’ve logged off and hit the pubs.
3. Similarly, business operations quickly get out of synch with what’s happening on the ground. The roadmap review or the hiring planning or the marketing communications or the performance reporting should all operate with the same “rapid iteration, frequent release” methods.

   For example, in my previous jobs I kept a big whiteboard marked up with all the key metrics of my business. I stared at it all the time. Patterns emerged with each new line row of data which made the short-term decisions much easier to identify. The 3 year plan was then an abstract vision with tangible month-to-month goals. Of course, we weren’t able to act on many of the short-term needs because the planning for the current year was already locked down.

4. It seems hugely important to have an abstract framework to work within as a guiding light when you’re chasing 30 to 60 day goals. But agile development doesn’t necessarily have an end point. The goal needs to feel like a BHAG, yet it needs to be as measurable as the end date of your development cycle.

   For example, a news media site may want to chase down a long term goal of “High customer loyalty”. That goal then needs to be measured in terms of things like repeat visits. And so the result of each sprint should be an understanding of whether or not that sprint had an impact on repeat visits.

There are lots of great things that come out of the agile process including an intense focus on a goal that everyone can work towards and the freedom to postpone things that block progress, among many others. However the process is not without flaw.

At some point, all the IT solutions you can purchase and project management processes you can adopt will hit a ceiling. That ceiling is most likely a need to fundamentally alter the goals and direction of the business itself.

The concept of “Loose Coupling” is great on so many levels. I’ve used it to describe different types of things in ideal worlds, but I’m starting to see that there is a lot of gray area there that can be maddening in real worlds.

Here is Wikipedia’s current definition of it:

“Loose coupling describes a resilient relationship between two or more computer systems that are exchanging data. Each end of the transaction make their requirements explicit and make few assumptions about the other end. Loosely Coupled systems are considered useful when either the source or the destination computer systems are subject to frequent changes.”

I’m working with a small team on a really fun web-based product that weaves lots of stuff together. The core app we’re working on has a very powerful layer of intelligence built into it, but it depends on a stack of data sources and rendering environments that are all partially isolated and not necessarily production-ready.

This means that we can’t really test the product end-to-end. It means there are several layers of troubleshooting that get added to each bug no matter how small. It means we have to fake a service layer here and there to emulate behavior.

I’m realizing now that “loosely coupled” means you have to think a lot harder about each move instead of just cranking out everything from scratch the way you want it to work.

Ultimately, the power of our platform services including things like scalability and user data management will accelerate this product’s ability to reach a more profound state of being than it could without loose couplings. But the cost of glueing all the things together in parallel means that we spend hours in meetings and constantly reshuffle our attack plan.

It feels like running through mid-court of a dodgeball game.