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.
- Someone gets an idea.
- Someone, possibly the same person, prototypes the idea and involves a small group of people to refine the idea.
- 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.
Oh Jake, tsk tsk, no design docs!
Welcome to the world of what we call ‘Rapid Application Development’ – its not made up as an excuse for lack of doc – http://en.wikipedia.org/wiki/Rapid_application_development
It’s worked for us but we now have some growing pains. As you get more customers, more and more requirements flood in and your team grows to cope, documentation becomes a necessity. If nothing else than to help team members understand who is building what.
We are not fabulous at the doc thang but we are getting better … especially now Im remote and whinging all the time for doc. But there is still room for iterative innovation which will be addressing requirements that the customer has not even thought of yet :0) Which, lets face it, is what keeps the development team happy and motivated – that and donuts and coffee.
Oh Jake, tsk tsk, no design docs!
Welcome to the world of what we call ‘Rapid Application Development’ – its not made up as an excuse for lack of doc – http://en.wikipedia.org/wiki/Rapid_application_development
It’s worked for us but we now have some growing pains. As you get more customers, more and more requirements flood in and your team grows to cope, documentation becomes a necessity. If nothing else than to help team members understand who is building what.
We are not fabulous at the doc thang but we are getting better … especially now Im remote and whinging all the time for doc. But there is still room for iterative innovation which will be addressing requirements that the customer has not even thought of yet :0) Which, lets face it, is what keeps the development team happy and motivated – that and donuts and coffee.
One way to look at Connect is to view *it* as the design document. It conveys the current thinking of the requirements, based on feedback from live and continuous usability studies and anyone can look at it to see what the current state of requirements are. It’s just a lot more dynamic (and a lot richer in content) than a word doc. As long as the investment/return ratio is in line, *how* you gather requirements should be open.
One way to look at Connect is to view *it* as the design document. It conveys the current thinking of the requirements, based on feedback from live and continuous usability studies and anyone can look at it to see what the current state of requirements are. It’s just a lot more dynamic (and a lot richer in content) than a word doc. As long as the investment/return ratio is in line, *how* you gather requirements should be open.
hmm. Seems to me you are just making a case for agile methodologies, albeit with shortcuts!
But I don’t see anything exclusive to Web 2.0. Even the idea of “perpetual beta” is not exactly groundbreaking (could make a few jokes at this point).
So what is the real message and meaning of Connect?
I’d suggest its not really about web/enterprise 2.0 at all, not even about methodologies. It’s about being the intentionally disruptive force that provokes innovation elsewhere. In other words, driving for an indirect but exponential payoff.
So from that point of view, where Connect itself is not necessarily a “product” with longevity but a means of stimulating the applications dev and aria teams to adopt and extend “connect” innovations, then how you build it and whether you wrote any doc is pretty irrelevant;)
What’s more important is how you can best isolate, evaluate and evangelise the “innovations that worked”.
hmm. Seems to me you are just making a case for agile methodologies, albeit with shortcuts!
But I don’t see anything exclusive to Web 2.0. Even the idea of “perpetual beta” is not exactly groundbreaking (could make a few jokes at this point).
So what is the real message and meaning of Connect?
I’d suggest its not really about web/enterprise 2.0 at all, not even about methodologies. It’s about being the intentionally disruptive force that provokes innovation elsewhere. In other words, driving for an indirect but exponential payoff.
So from that point of view, where Connect itself is not necessarily a “product” with longevity but a means of stimulating the applications dev and aria teams to adopt and extend “connect” innovations, then how you build it and whether you wrote any doc is pretty irrelevant;)
What’s more important is how you can best isolate, evaluate and evangelise the “innovations that worked”.
Paul,
I like the cut of your jib. We aren’t intentionally disruptive, but we have been trying to provoke (I like that word) innovation. We are a part of Apps Strategy after all, and I think we can all agree that the old ways could use a jump start, e.g. sitting in a dark room showing slides on how you think we should do stuff won’t cut the mustard anymore. People are 1) too busy, 2) too comfortable with the old ways and 3) too focused. Focus in this case is not a good thing b/c it can blind you to innovation.
Anyway, we do what we can. Time will tell. Keep reading and commenting.
Jake
Paul,
I like the cut of your jib. We aren’t intentionally disruptive, but we have been trying to provoke (I like that word) innovation. We are a part of Apps Strategy after all, and I think we can all agree that the old ways could use a jump start, e.g. sitting in a dark room showing slides on how you think we should do stuff won’t cut the mustard anymore. People are 1) too busy, 2) too comfortable with the old ways and 3) too focused. Focus in this case is not a good thing b/c it can blind you to innovation.
Anyway, we do what we can. Time will tell. Keep reading and commenting.
Jake
Jake,
You should also check out Extreme Programming
http://www.extremeprogramming.org/
It’s been around a while and talks of these short iterations.
Tim’s observation that as the team gets bigger the need for documentation increases. With an Enterprise Software vendor the team can run into thousands. I believe there is a need for some departure from the waterfall model, but the rapid development methodologies bring an equal number of issues for large development organizations.
Jake,
You should also check out Extreme Programming
http://www.extremeprogramming.org/
It’s been around a while and talks of these short iterations.
Tim’s observation that as the team gets bigger the need for documentation increases. With an Enterprise Software vendor the team can run into thousands. I believe there is a need for some departure from the waterfall model, but the rapid development methodologies bring an equal number of issues for large development organizations.
Dude, you know I’m familiar with Extreme Programming, we talked about what we could use of that years ago in Dev.
Why can’t we use a smaller team approach or something, anything? The agile method has merit too. You can’t tell everyone to read something like “Winning with Software” and then implement none of the suggestions. That’s not a useful exercise.
Tim has unique experience with documentation.
My point is that change is needed. You agree we need change, but . . .
Why not try what you think works from agile methods, mixed with the waterfall method? You can be the case study.
Jake
Dude, you know I’m familiar with Extreme Programming, we talked about what we could use of that years ago in Dev.
Why can’t we use a smaller team approach or something, anything? The agile method has merit too. You can’t tell everyone to read something like “Winning with Software” and then implement none of the suggestions. That’s not a useful exercise.
Tim has unique experience with documentation.
My point is that change is needed. You agree we need change, but . . .
Why not try what you think works from agile methods, mixed with the waterfall method? You can be the case study.
Jake
Jake… I agree, of course. Check this out… ran into it yesterday -> Secrets to Amazon’s success:
http://www.37signals.com/svn/posts/600-secrets-to-amazons-success
“Teams are small. They are assigned authority and empowered to solve a problem as a service in anyway they see fit.
Work from the customer backward. Focus on value you want to deliver for the customer.
Force developers to focus on value delivered to the customer instead of building technology first and then figuring how to use it…”
Jake… I agree, of course. Check this out… ran into it yesterday -> Secrets to Amazon’s success:
http://www.37signals.com/svn/posts/600-secrets-to-amazons-success
“Teams are small. They are assigned authority and empowered to solve a problem as a service in anyway they see fit.
Work from the customer backward. Focus on value you want to deliver for the customer.
Force developers to focus on value delivered to the customer instead of building technology first and then figuring how to use it…”