The AppsLab

Driving Innovation, Get It?

By Jake • August 29th, 2007 • View Comments

Recently, Paul was telling me about a conversation he had with an internal product team about Connect. The conversation went something like this:

Product Manager: We love what you’re doing with Connect, and we want to learn more about it. Are your design documents online?
Paul: We don’t have any design documents.
PM: How did you know what your users wanted? Did you do surveys or usability studies?
Paul: No. We each had an idea of what we wanted to build. We did a few rounds of mockups, huddled in a conference room to prioritize features, and then, Rich built it.
PM: (Silence)

Or some similar approximation, I’m paraphrasing. I found this interesting because it’s typical of reactions we get. People are surprised at how we built Connect, because our methods run against tried-and-true software development principles. The same can be said for all new web application development. Let’s use Google as an example.

1. Someone gets an idea.
2. Someone, possibly the same person, prototypes the idea and involves a small group of people to refine the idea.
3. Rinse and repeat, with larger groups each time, longer cycles between new feature releases and different Greek letters.

This is Tim O’Reilly’s “perpetual beta” tenant for Web 2.0. Compare this to more classic models of software development, like the waterfall model. I’m sure you can see the cultural shift that’s required to go from a straight line or cascading model like this one to a short, iterative cycle model one like the perpetual beta. It’s like asking someone to switch from a straight-line religion (birth-school-work-death-afterlife) to a circular one (birth-school-work-death-rebirth) or vice versa. You’re going to get shocked surprise and resistance.

Let’s pause for the disclaimer: Although I work for Oracle, I don’t endorse any particular software development model or religion. What I say has no bearing on anything related to Oracle or even to my own personal life. I’m just talking.

This is why I’m so against the term Enterprise 2.0 and all its trappings. First, it’s completely derivative, and doesn’t even copy a good original. Raise your hand if you’re really in love with Web 2.0? I don’t see any hands. Second, you can’t expect enterprises to accept the tenants of Web 2.0 without some tweaking, which is what the term suggests to me.

What’s the right answer? We need to mix and match what works in both models to get the best new enterprise solution we can. We’ve been preaching this from the beginning internally. New web is not about technologies; it’s about people.

You can’t just shove blogs, wikis, RSS and social networking down people’s throats, slap a beta label on it and call it a day. The best way to get results is by participating in the new web and cherry-picking the principles that work for you, for your customers, and for your products. Let’s compare the models and their principles.

The requirements and design phases are basically the same in each model. Requirements collection is always key, and knowledge about your customer is assumed. Once you’ve identified a need, you probably have an idea of what to build. Whether you write a detailed design or simply produce mockups to show what you’re hoping to build isn’t really critical. Both models have requirements and design.

The main difference is deployment, which in turn affects testing. As a PM, I spent a lot of time testing products I had designed. I hate testing. Everyone hates testing. A PM will know pretty much how a feature or product should be used after design in complete. Testing intended use is easy. Most of the testing effort goes into predicting how a product will be used in a way you didn’t foresee, i.e. the corner cases.

This is where deployment can really help development. As a single person, or even as a team, you can’t test every scenario. So why not let your customer use the product. There’s a huge difference between testing and using a product. Use is how you uncover design flaws. Use allows you to make a product better. So, by deploying to customers early and often, you get more use and less testing.

Maybe this boils down to ego. In the waterfall model, development takes longer. Therefore, customers expect the finished product to be airtight and bug-free, and the software company assumes it should be too because they invested so much to make it perfect. When it isn’t, everyone is unhappy. This leads to finger-pointing. You’re software’s buggy. You’re not using it as designed. It’s not designed for me. We have thousands of customers; we can’t design only for you. You’re ugly. You’re fat. OK, maybe not that last two.

In the cyclic model, the software producer says up front, this ain’t a fully-baked pie yet, but we’d really like you to have a taste and tell us what you think. This makes the customers feel important because they now have a perceived say-so in the product, some pride in ownership. In turn, the software company gets free or cheap resources to helps find bugs, freeing some development resources to work on other, new projects. Of course, these other, new projects will ultimately benefit the customers. So, this symbiotic relationship feeds everyone’s egos, and all parties stay relatively happy.

Of course, our little experiment is just that, an experiment. Affecting change is hard, but we’re hoping that Connect will get people thinking. The more people who borrow what they find useful about Connect or our methodologies for their products, the better. This is how we’re hoping to drive innovation.

Possibly Related Posts

• Testing is Tough
• Connect is Just the Beginning
• “Looks Good, Works Well”
• Hug a Developer
• What’s Next?