Category: development

No backlog

The backlog has lots of benefits in the software development process, but is it necessary?  Could there be more to gain by just trusting your crew will do the right thing at the right time?

It occurred to me while tracking Github commits on a project that I didn’t need to maintain a backlog or a burn down chart or any of those kinds of things anymore.

Everyone was watching each other’s commits, commenting on issues, and chatting when they needed to.  I could see what everyone had done the day before.

They were all in synch enough to collaborate on the output when it helped to collaborate or work independently when that was more effective.

What could I add? Remind them of all the things they haven’t done? That’s uninspiring for everyone involved.

How does everyone know what to work on next?

The devs know what’s important, and they know how to do their job efficiently…let them work it out. If they don’t know what’s important it will become obvious in their commits. Then you can just steer when the emphasis is wrong rather than mapping hours to tasks.

They may in fact want to maintain a list that works like a backlog.  But maybe that should be a personal productivity choice, not something that’s imposed by someone else.

What about all those things you want to do that aren’t getting done?

I’ve never had a feature that really mattered to me just fade from memory. In fact, having no backlog forces a sharper focus.

How do you know when things will get done?

Your devs will tell you, and they will be accurate if it’s a personal agreement between you rather than a number on a spreadsheet.  If you have a deadline that really matters, then just be clear about that.  That becomes framework within which to operate, a feature of the code.

What if the developer doesn’t understand the requirements?

Well, do you actually really need to spell out requirements? Aren’t your developers tasked with solving the need? Let them pitch a solution to a problem, agree on it, and then let them run with it.

Of course, I don’t know how well this approach would work in a team larger than maybe 8 people, or a large-scale project with multiple parallel streams to it.  And maybe the chaos does more harm than good over time.

Clearly, I’m exaggerating for effect a little here, but I wonder a lot about how far you could go with this approach and where it really breaks down.

I think a lot of folks want things like backlogs because one can establish a meaningful agreement and reduce tension between people who organize stuff and people who create stuff.  But it’s often used to protect one side from the faults of the other rather than join them up to create a stronger whole.

But all projects and teams are different.  And it can be very tricky working out what should be done, by whom and when.

I think what I’m suggesting is that rather than making decisions around time and resource where success is measured by how effectively activity maps to a plan, maybe the better way to lead a software project instead is to adjust decision making according to the appropriate abstraction level for the project.  That way you can value quality and creativity over precision of delivery.

For example, the resources required to build, say, a global transaction platform vs a web page are very different.  And your teams will not allow you to rank them together.  You have to zoom in or out to understand the impact of those two projects, and that will then affect how you allocate resources to make them each happen.

Once that discussion has been had and everyone has agreed on what they are supposed to be working on, make sure they have enough caffeinated beverages and get out of the way.

Keep an eye on their commits each day.  And drop the backlog.

It’s incredibly liberating.

The business of network effects

The Internet platform business has some unique challenges. It’s very tempting to adopt known models to make sense of it, like the PC business, for example, and think of the Internet platform like an operating system.

The similarities are hard to deny, and who wouldn’t want to control the operating system of the Internet?

In 2005, Jason Kottke proposed a vision for the “WebOS” where users could control their experience with tools that leveraged a combination of local storage and a local server, networked services and rich clients.

“Applications developed for this hypothetical platform have some powerful advantages. Because they run in a Web browser, these applications are cross platform, just like Web apps such as Gmail, Basecamp, and Salesforce.com. You don’t need to be on a specific machine with a specific OS…you just need a browser + local Web server to access your favorite data and apps.”

Prior to that post, Nick Carr offered a view on the role of the browser that surely resonated with the OS perspective for the Internet:

“Forget the traditional user interface. The looming battle in the information technology business is over control of the utility interface…Control over the utility interface will provide an IT vendor with the kind of power that Microsoft has long held through its control of the PC user interface.”

He also responded later to Kottke’s vision saying that the reliance on local web and storage services on a user’s PC may be unnecessary:

“Your personal desktop, residing entirely on a distant server, will be easily accessible from any device wherever you go. Personal computing will have broken free of the personal computer.”

But the client layer is merely a piece of the much larger puzzle, in my opinon.

Dare Obasanjo more recently broke down the different ideas of what “Cloud OS” might mean:

“I think it is a good idea for people to have a clear idea of what they are talking about when they throw around terms like “cloud OS” or “cloud platform” so we don’t end up with another useless term like SOA which means a different thing to each person who talks about it. Below are the three main ideas people often identify as a “Web OS”, “cloud OS” or “cloud platform” and examples of companies executing on that vision.”

He defines them as follows:

  1. WIMP Desktop Environment Implemented as a Rich Internet Application (The YouOS Strategy)
  2. Platform for Building Web-based Applications (The Amazon Strategy)
  3. Web-based Applications and APIs for Integrating with Them (The Google Strategy)

The OS metaphor has lots of powerful implications for business models, as we’ve seen on the PC. The operating system in a PC controls all the connections from the application user experience through the filesystem down through the computer hardware itself out to the interaction with peripheral services. Being the omniscient hub makes the operating system a very effective taxman for every service in the stack. And from there, the revenue streams become very easy to enable and enforce.

But the OS metaphor implies a command-and-control dynamic that doesn’t really work in a global network controlled only by protocols.

Internet software and media businesses don’t have an equivilent choke point. There’s no single processor or function or service that controls the Internet experience. There’s no one technology or one company that owns distribution.

There are lots of stacks that do have choke points on the Internet. And there are choke points that have tremendous value and leverage. Some are built purely and intentionally on top of a distribution point such as the iPod on iTunes, for example.

But no single distribution center touches all the points in any stack. The Internet business is fundamentally made of data vectors, not operational stacks.

Jeremy Zawodny shed light on this concept for me using building construction analogies.

He noted that my building contractor doesn’t exclusively buy Makita or DeWalt or Ryobi tools, though some tools make more sense in bundles. He buys the tool that is best for the job and what he needs.

My contractor doesn’t employ plumbers, roofers and electricians himself. Rather he maintains a network of favorite providers who will serve different needs on different jobs.

He provides value to me as an experienced distribution and aggregation point, but I am not exclusively tied to using him for everything I want to do with my house, either.

Similarly, the Internet market is a network of services. The trick to understanding what the business model looks like is figuring out how to open and connect services in ways that add value to the business.

In a precient viewpoint from 2002 about the Internet platform business, Tim O’Reilly explained why a company that has a large and valuable data store should open it up to the wider network:

“If they don’t ride the horse in the direction it’s going, it will run away from them. The companies that “grasp the nettle firmly” (as my English mother likes to say) will reap the benefits of greater control over their future than those who simply wait for events to overtake them.

There are a number of ways for a company to get benefits out of providing data to remote programmers:

Revenue. The brute force approach imposes costs both on the company whose data is being spidered and on the company doing the spidering. A simple API that makes the operation faster and more efficient is worth money. What’s more, it opens up whole new markets. Amazon-powered library catalogs anyone?

Branding. A company that provides data to remote programmers can request branding as a condition of the service.

Platform lock in. As Microsoft has demonstrated time and time again, a platform strategy beats an application strategy every time. Once you become part of the platform that other applications rely on, you are a key part of the computing infrastructure, and very difficult to dislodge. The companies that knowingly take their data assets and make them indispensable to developers will cement their role as a key part of the computing infrastructure.

Goodwill. Especially in the fast-moving high-tech industry, the “coolness” factor can make a huge difference both in attracting customers and in attracting the best staff.”

That doesn’t clearly translate into traditional business models necessarily, but if you look at key business breakthroughs in the past, the picture today becomes more clear.

  1. The first breakthrough business model was based around page views. The domain created an Apple-like controlled container. Exposure to eyeballs was sold by the thousands per domain. All the software and content was owned and operated by the domain owner, except the user’s browser. All you needed was to get and keep eyeballs on your domain.
  2. The second breakthrough business model emerged out of innovations in distribution. By building a powerful distribution center and direct connections with the user experience, advertising could be sold both where people began their online experiences and at the various independent domain stacks where they landed. Inventory beget spending beget redistribution beget inventory…it started to look a lot like network effects as it matured.
  3. The third breakthrough business model seems to be a riff on its predecessors and looks less and less like an operating system. The next breakthrough is network effects.

Network EffectsNetwork effects happen when the value of the entire network increases with each node added to the network. The telephone is the classic example, where every telephone becomes more valuable with each new phone in the network.

This is in contrast to TVs which don’t care or even notice if more TVs plug in.

Recommendation engines are the ultimate network effect lubricator. The more people shop at Amazon, the better their recommendation engine gets…which, in turn, helps people buy more stuff at Amazon.

Network effects are built around unique and useful nodes with transparent and highly accessible connection points. Social networks are a good example because they use a person’s profile as a node and a person’s email address as a connection point.

Network effects can be built around other things like keyword-tagged URLs (del.icio.us), shared photos (flickr), songs played (last.fm), news items about locations (outside.in).

The contribution of each data point wherever that may happen makes the aggregate pool more valuable. And as long as there are obvious and open ways for those data points to talk to each other and other systems, then network effects are enabled.

Launching successful network effect businesses is no easy task. The value a participant can extract from the network must be higher than the cost of adding a node in the network. The network’s purpose and its output must be indespensible to the node creators.

Massively distributed network effects require some unique characteristics to form. Value not only has to build with each new node, but the value of each node needs to increase as it gets leveraged in other ways in the network.

For example, my email address has become an enabler around the Internet. Every site that requires a login is going to capture my email address. And as I build a relationship with those sites, my email address becomes increasingly important to me. Not only is having an email address adding value to the entire network of email addresses, but the value of my email address increases for me with each service that is able to leverage my investment in my email address.

Then the core services built around my email address start to increase in value, too.

For example, when I turned on my iPhone and discovered that my Yahoo! Address Book was automatically cooked right in without any manual importing, I suddenly realized that my Yahoo! Address Book has been a constant in my life ever since I got my first Yahoo! email address back in the ’90’s. I haven’t kept it current, but it has followed me from job to job in a way that Outlook has never been able to do.

My Yahoo! Address Book is becoming more and more valuable to me. And my iPhone is more compelling because of my investment in my email address and my address book.

Now, if the network was an operating system, there would be taxes to pay. Apple would have to pay a tax for accessing my address book, and I would have to pay a tax to keep my address book at Yahoo!. Nobody wins in that scenario.

User data needs to be open and accessible in meaningful ways, and revenue needs to be built as a result of the effects of having open data rather than as a margin-based cost-control business.

But Dare Obasanjo insightfully exposes the flaw in reducing openness around identity to individual control alone:

“One of the bitter truths about “Web 2.0” is that your data isn’t all that interesting, our data on the other hand is very interesting…A lot of “Web 2.0″ websites provide value to their users via wisdom of the crowds appproaches such as tagging or recommendations which are simply not possible with a single user’s data set or with a small set of users.”

Clearly, one of the most successful revenue-driving opportunities in the networked economy is advertising. It makes sense that it would be since so many of the most powerful network effects are built on people’s profiles and their relationships with other people. No wonder advertisers can’t spend enough money online to reach their targets.

It will be interesting to see how some of the clever startups leveraging network effects such as Wesabe think about advertising.

Wesabe have built network effects around people’s spending behavior. As you track your finances and pull in your personal banking data, Wesabe makes loose connections between your transactions and other people who have made similar transactions. Each new person and each new transaction creates more value in the aggregate pool. You then discover other people who have advice about spending in ways that are highly relevant to you.

I’ve been a fan of Netflix for a long time now, but when Wesabe showed me that lots of Netflix customers were switching to Blockbuster, I had to investigate and before long decided to switch, too. Wesabe knew to advise me based on my purchasing behavior which is a much stronger indicator of my interests than my reading behavior.

Advertisers should be drooling at the prospects of reaching people on Wesabe. No doubt Netflix should encourage their loyal subscribers to use Wesabe, too.

The many explicit clues about my interests I leave around the Internet — my listening behavior at last.fm, my information needs I express in del.icio.us, my address book relationships, my purchasing behavior in Wesabe — are all incredibly fruitful data points that advertisers want access to.

And with managed distribution, a powerful ad platform could form around these explicit behaviors that can be loosely connected everywhere I go.

Netflix could automatically find me while I’m reading a movie review on a friend’s blog or even at The New York Times and offer me a discount to re-subscribe. I’m sure they would love to pay lots of money for an ad that was so precisely targeted.

That blogger and The New York Times would be happy share revenue back to the ad platform provider who enabled such precise targeting that resulted in higher payouts overall.

And I might actually come back to Netflix if I saw that ad. Who knows, I might even start paying more attention to ads if they started to find me rather than interrupt me.

This is why the Internet looks less and less like an operating system to me. Network effects look different to me in the way people participate in them and extract value from them, the way data and technologies connect to them, and the way markets and revenue streams build off of them.

Operating systems are about command-and-control distribution points, whereas network effects are about joining vectors to create leverage.

I know little about the mathematical nuances of chaos theory, but it offers some relevant philosophical approaches to understanding what network effects are about. Wikipedia addresses how chaos theory affects organizational development:

“Most of the focus on chaos theory is primarily rooted in the underlying patterns found in an otherwise chaotic enviornment, more specifically, concepts such as self-organization, bifurcation and self-similarity…

Self-organization, as opposed to natural or social selection, is a dynamic change within the organization where system changes are made by recalculating, re-inventing and modifying its structure in order to adapt, survive, grow and develop. Self-organization is the result of re-invention and creative adaptation due to the introduction of, or being in a constant state of, perturbed equilibrium.”

Yes, my PC is often in a state of ‘perturbed equilibrium’ but not because it wants to be.

How to fix building construction bureaucracy

Sometimes I forget to step outside of our little bubble here and see how people use or in fact don’t use the Internet. When I get that chance I often wonder if anything I’m doing in my career actually matters to anyone.

Usually, however, I’m reminded that even though the Internet isn’t weaved into every aspect of everything, it has great potential in places you might not consider.

For example, I’ve been remodelling my house to make room for a new little roommate due to be delivered in September. I’m trying to do most of the work myself or with help from friends and neighbors. I’m trying to save money, but I also really enjoy it. It’s a fantastic way to reconnect with the things that matter…food, shelter, love and life.

Well, I made the mistake of working without permits fully aware that I probably should have them. It’s my natural inclination to run around bureaucracy whenever possible.


As luck would have it, just as the pile of demolition debris on the sidewalk outside my house was at its worst, a building inspector happened to drive by on his way to another job. He asked to see my permit to which I replied, “The boss isn’t here. Can you come back later?”

The building inspector just laughed. After pleading a bit and failing, I started making calls to get drawings and to sort out the permits.

It was at this moment I realized how much building planning and construction could benefit from the advances made in the Internet market the last few years. The part of construction that people hate most is the one that is perhaps the most important. And it is this part that the Internet is incredibly well-suited to improve.

Admittedly, the permit process was not actually that painful and relatively cheap, too. I have spent in total maybe 1 day dealing with permits and drawings, so far, with a bit more to come, I’m sure.

But the desired effect of permitting jobs is sorely underserved by its process.

At the end of the day what you want is the highest building quality possible. You want builders using proven methods with at least semi-predictable outcomes. You want to make sure nobody gets hurt. And you want incentives for people to share expertise and information.

Rather than be a gatekeeper, the city needs to be an enabler.

One of the brochures I read called “How to Obtain a Permit” includes a whitelist of project types. I’m apparently allowed to put down carpets and hang things on my walls without a permit. Glad to know that.

Strangely, after explaining all the ways the city asserts itself into the process, on the very last page of the brochure it then says, “Remember, we are here to assist you. If you have any questions about your project, please give us a call!” I didn’t meet one person in the 6 queues I waded through the first morning who wanted to help me. They were mostly bored out of their brains.

Instead, the city should be putting that brainpower to work finding ways to lubricate conversation and collaboration around solving building problems. If the building community was in fact a community powered by thoughtful city-employed engineers, then I would be much more interested in working with them. I might even become dependent on them.

For example, if they helped me organize, store, print and even share my plans, then I’d be more than happy to let them keep my most current drawings, the actual plans I’m using to build with. If they could connect me to licensed contractors and certified service providers, I’d gladly give them my budget.

As it stands, my incentive is to avoid them and hide information whenever possible.

Imagine if I was able to submit a simple SketchUp plan to a construction service marketplace. I could then sit back and watch architects and interior designers bid for the planning work. My friends in the network could recommend contractors. Tools and parts suppliers could offer me discounts knowing exactly what I needed for the job. I could rate everything that happens and contribute to the reputation of any node in the ecosystem.

Imagine how much more value would be created in the home buying market if a potential buyer could see all this data on a house that was for sale. I might be able to sell my home for a higher price if my remodel was done using highly reputable providers. There would be a financial incentive for me to document everything and to get the right certifications on the work.

Imagine lenders knowing that I’m an excellent remodeller based on my reputation and sales track record. I might be able to negotiate better terms for a loan or even solicit competing bids for my mortgage on the next house I want to invest in.

At every step in the process, there is a role for the city government to add value and thus become more relevant. Then the more I contribute, the more it knows about what’s happening. The more it knows, the more effective it can be in driving better standards and improving safety and legislating where necessary.

My mind spins at the possibilities in such a world. Of course, when you have a hammer everything looks like a nail. But it seems to me that the building permit and inspection business is broken in exactly the places that the Internet is more than capable of fixing.

Are big product launches necessary?

A commenter in Mark Glaser’s recent post on MediaShift about the USA Today redesign sheds light on a problem that Internet companies seem to struggle with a lot.

“I think there may be a lesson to be learned in how to roll these things out. Most of the problems people are having are usability issues that it is nearly impossible for designers/developers who are in the weeds to notice.”

Similarly, Scott Karp asked the right question:

“Could it be that it’s really the social media revolutionaries who “don’t get it” when they assume that what the people want is to rise up against the media autocracy and take control, when in fact what most people want is to get high quality information from a reliable source?”

Unfortunately, even if you do the user research the recommendations of the studies often don’t fit into tight product release deadlines. And the studies often just support product direction rather than fully investigate a user need.

But the problem isn’t the research, it’s the product roadmap. In order to deliver a big punch in the market and cut through the noise, you need to be bold. And big changes that get noticed by big audiences require a lot of planning and complicated scheduling. Big changes are expensive on many levels.

But do you really need a big punch?

Most of my favorite online services tend to evolve organically as if responding to the way people are using the tools. Last.fm, for example, subtely rolls out new features that can occassionally have a significant impact on my usage. They had a pretty crappy web-based player for a long time. Of course, they upgraded it, as I knew they would, and I found it when it was relevant for me to look for it. There’s no amount of marketing they could have done to make me upgrade, and if they had done heavy marketing I might have actually been annoyed with them and considered a competitor.

The online media market is way too fickle to annoy your loyal customers.

But what about reaching new customers? Subtelty won’t win market share.

Admittedly, when you have a hammer everything looks like a nail, but the lessons of the web services market can be instructive. When you empower people to build businesses (or audiences) with your core offering, then you create a multiplier effect and reach all kinds of markets that you might never reach otherwise.

Winning market share in online media can happen by giving people the ability to distribute your offering for you, to create loyal customers for you out of their own customers, to build their own buzz for your product because they have an incentive for it to succeed.

Building the kind of passion required for a distributed customer model like this will never come from big bang marketing. It comes from fostering trustworthy relationships, establishing meaningful brands, proving tangible value, and responding quickly to market changes.

It’s not about noise. It’s about relationships.

I tend to agree with most online media insiders who appreciate the conceptual breakthrough for USA Today online and the balls to act on it, but I would be surprised if any of the positive comments in the blogosphere came from USA Today readers. And if USA Today damaged their relationship with their readers with this redesign, then they have made an incredibly costly mistake.

Online services need to roll out important new features constantly. But the days of hitting the market hard with a new product launch are fading. It works occassionally for major releases of things that are really new and require a reeducation of the market, like the iPhone. But fewer and fewer things fit into that category.

At the risk of invalidating everything I’ve said here by quoting a man who’s social and political beliefs go against just about everything I believe, Eric S. Raymond’s “The Cathedral and the Bazaar” included many astute observations about the way Linux development was able to scale so efficiently. Among the lessons is the classic “Release early and often” mantra:

“In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena…or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.”

Product Managers and Marketers need to bake these concepts into their thinking as well or risk missing the wider opportunity, the ultimate in marketing and distribution efficiency — customers as partners.

Photos: marble2, ccarlstead

Top 5 new business ideas

The month of lists has begun, so I decided to rank the business ideas from the last year that could or should be a big deal in the next year. Most of these ideas and companies have actually been around longer than 12 months, but they either reached a certain critical mass or captured my imagination in a new way recently.

1) Scrobbling
All my listening behavior are belong to Last.fm. They figured out how to not only capture what I listen to but also to incentivize me to keep my behavior data with them. Since my listening data is open for other services to use, I am willingly giving Last.fm the power to broker that data with other providers on behalf. That’s a very strong position to be in.

2) Meta ad networks
Feedburner and Right Media figured out that ad networks can be networked into meta networks. Right Media went the extra step and opened up their APIs so that someone can build a white label ad exchange of their own using the Right Media tools. All you need are advertisers and publishers, and you’ve suddenly got a media market of your own. I can’t help but wonder if these guys have stepped into the big leagues with the next really important revenue model.

3) Pay-as-you-go storage, computing, whatever
Amazon impresses me on so many levels even if they don’t know exactly what they’re doing. They are making it happen just by doing smart things with the resources already in their arsenal. Similarly, Flickr understands that the APIs you use to build your web site are the same APIs you want to open up as a service, and it’s paying off handsomely for them. The formula here is one part optimizing resources and two parts confidence that your business won’t crash if you share your core assets with other people. Stir constantly.

4) People-powered knowledge
I really like the Yahoo! Answers experience. I also really like the concept behind MechanicalTurk where knowledge can be distributed as a service. Machines are at their best, in my opinion, when they make humans capable of doing things they couldn’t otherwise do, not least of which is making the universe of human knowledge more accessible.

5) Widget-mania
It wasn’t until I heard about the big revenues GlitterMaker was earning that I realized just how powerful this idea has become the last year or so. Beck’s customizable CD cover reinforced the idea that everything is a tattoo or a tattooable thing if you look at it that way…and many people do. If only I could run AdSense on my forehead.

Indicators of the Ruby on Rails trend

Here’s a fascinating market indicator. I was looking for a Ruby book on Amazon, something for lightweight coders, perhaps a beginner’s guide to Ruby on Rails. What did I find? I found a total of 23 books. 9 of them are hitting the shelves within weeks. All of the others were published within the last 6 months.


Here’s a sampling of what’s coming out soon:

The blogosphere saw the Ruby on Rails thing coming a while back. Now the book publishers see it, too, and they’re all racing to get a piece of the action.

There are other interesting indicators like the fact that Dreamhost offers it preinstalled as part of its hosting package. And you can’t ignore the recent adoption of Agile project management which feeds nicely into the Rails approach, even sharing language and concepts at the same level of abstraction.

Yesterday, I asked Jeremy Zawodny how his experiments with Ruby on Rails are going, so far. He replied,

“It’s frighteningly productive.”

I wonder if the venture and acquisition machines out there will learn how to plug into this market architecture. In 1999, startups did the Sand Hill march using PowerPoint as their weapon of choice. The right buzzwords in the right order and charts pointing high and to the right put many on the IPO course before engineers had been hired.

Investors today are looking for working ideas with real customers.

There’s a perfect storm forming.

Scaffolding web sites with Ruby on Rails

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.

“Iterate and release” has its problems, too

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.

“Loosley Coupled” does not mean “Easy to build”

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.