Web 2.0 Lessons For Corporate Dev Teams 142
jcatcw writes "Quick, incremental updates, along with heavy user involvement, are key characteristics of the emerging software development methods championed by a new generation of Web 2.0 start-ups. A survey conducted for Computerworld showed that an overwhelming majority of the respondents said that traditional corporate development teams could benefit from Web 2.0 techniques, specifically the incremental feature releases, quick user feedback loops and quality assurance programs that include users. Fifty seven percent of the respondents said problem-solving and analytical skills will be key requirements for next generation developers. The bottom-line: corporate development teams need to get to know their users."
oh comon (Score:0, Interesting)
I wish all this was true. Incremental and fast and includes clients. Sounds like a recipe for disaster to me. Sorry but I really have not seen development teams using such methods successfully.
"Perpetual beta" = it sucks, forever (Score:5, Interesting)
I'm not impressed with the "perpetual beta" and "using your users for Q/A" concept. Remember, the users can leave.
I've seen this happen with Tribe. [tribe.com] Tribe was a nice little social networking system for people in the San Francisco area. Then, in 2007, they went "Web 2.0", with a system that let you "customize your home page".
At first, this drove the users nuts, as they tried to find a home page layout that would work. "Tribe.net bug reports" became the most popular forum. After a while, most users got their home page to some format that would work (the default was awful) and didn't have overlapping panes, then stopped using the new, fancy features. Users began to leave; some users even set up a competing system in disgust. As more users left, Tribe tried to charge for some features. More users left.
Tribe is now down to two employees and a fraction of its user base of two years ago.
Re:Free labor, really. (Score:3, Interesting)
Yeah - I had to sit through a two hour session online plodding through a MS Partner Program exam that crashed at - yep - two hours in. And the only solution was to start over.
Ugh.
Re:Free labor, really. (Score:3, Interesting)
had to sit through a two hour session online plodding through a MS Partner Program exam that crashed at - yep - two hours in.
When BrainBench first started up, they offered their tests for free. I took a few for fun. Got a few of their "certs", but taking timed tests on a slow server was frustrating.
Re:Noise to Signal Ratio (Score:5, Interesting)
I really don't think the article is saying "we should do intranets like web 2.0 websites! and have all user generated content!"
They are simply saying, Instead of say having an internal software dev project, and having a huge design timeframe, huge development time frame, and then 3 months for test/fix/ship, the project should be built incrementally, using the same techniques as a lot of web 2.0 startups use...
release early, release often, work with the users, incorporating their feedback quickly into the project. Instead of doing 1-2 years of design, 1 year of dev, then releasing a beta that no one can use, solves no ones problems, and in general was a complete waste.
Instead, start prototyping early, releasing things to users or a group of users, and building the software iteratively with them instead of saying "this is what we built, learn how to use it" say "help us build this so it solves your problems in the best way possible"
Re:oh comon (Score:5, Interesting)
The whole system works quite well. The major hurdle usually comes around when management gets involved. They want to see change requests and hold pointless meetings and shift people around, etc. Because we are contractors, we can usually bypass management and the system works rather well.
Re:Prior art (Score:4, Interesting)
The only thing different I saw was that Wesabe has no QA staff and lets its users and CEO do the testing. What the article didn't mention was this was probably due to lack of financing to actually hire a SQ team rather than preferring to run a software company w/o QA.
Re:oh comon (Score:3, Interesting)
Exactly. We do this for an internal app in the company, too. What you absolutely need (and why it works well for internal stuff, IMHO) is someone from the dev team who is there for the users. Someone who knows their jobs, talks to them, helps them with bugs (absolutely critical: if you do quick incremental updates, you need to take the occasional pain of bugs off the users shoulders quickly), explains to them what this is all about, and so on. A gardener for users, so to speak.
It works fantastic for us.
Re:This has nothing to do with Web 2.0 (Score:3, Interesting)
This has nothing to do with Web 2.0 and is instead similar to the Agile software development process.
Yes and no. It's true that the Agile people had this pretty well figured out well before the Web 2.0 wave.
However, part of the reason that Agile methods have so much uptake is that the Web 2.0 companies are releasing early and often, both showing that it can be done and forcing their competitors to step up the pace. I also give some credit to the Rails people, who built a framework that supports key Agile practices like unit testing and short feedback loops.
Re:Not feasible in some markets (Score:5, Interesting)
For instance, my company develops health care diagnostic solutions, some of which are heavily regulated. While many of our tools and products could highly benefit from this design approach, federal regulations simply make it an impossibility.
You'd be surprised. There are a number of medical device people who are active in the Agile world. Yes, you can't push new code to somebody's pacemaker every morning, so there are some limits. But they are definitely applying Agile lessons even in heavily regulated spaces, so it's worth checking them out.
Re:oh comon (Score:1, Interesting)
The whole system works quite well. The major hurdle usually comes around when management gets involved. They want to see change requests and hold pointless meetings and shift people around, etc. Because we are contractors, we can usually bypass management and the system works rather well.
I guess it's safe to assume that the internal website isn't subject to SOX compliance requirements...
It really, really works but... (Score:2, Interesting)
I wish all this was true. Incremental and fast and includes clients. Sounds like a recipe for disaster to me. Sorry but I really have not seen development teams using such methods successfully.
...you need to couple it with EFFECTIVE and relevant feedback from the development team to the customers, testers, and users.
It is not enough to just acknowledge the feedback from your users, rather you need to make them an integral part of the process and SHOW that their opinions count.
Developing software can no longer be dictated from the "top" by decree or from the feedback of small subsets of your user base. And contrary to your assertions, this approach has been very successful in both of the startups I have had the pleasure of being involved in over my career.
Developing software is not about "this would be neat" or "we think this will be useful"; rather it is about solving problems and the more targeted that software is as re the users needs, the more successful it will be over the long run. And IFO never saw any value in ignoring or marginalizing the user/customer...