Slashdot Mirror
Web 2.0 Lessons For Corporate Dev Teams
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."
And is instead similar to the Agile software development process. If the average Web 2.0 monkey had some real software engineering background, maybe their work will be maintainable a few years down the road, and not just rewritten for the Next Big Buzzword.
Open Your Mind. Open Your Source.
This is called "agile development" and pre-dates Web 2.0 by around 10 years. Taco's having a bad day it seems.
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 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.
We need to deliver world-class e-tailers, aggregate bleeding-edge channels while growing our virtual bandwidth and benchmarking one-to-one deliverables. That is not to say that we redefine dot-com experiences and maximize B2C web services all the while revolutionizing end-to-end mindshare and monetize front-end deliverables.
"Fifty seven percent of the respondents said that problem-solving and analytical skills will be key requirements for next generation developers"
Really? To do development you need problem-solving and analytical skills? Since when?
CmdrTaco, what the f are you doing? I'm seriously thinking you've slipped a gear.
.0 releases always have alot of bugs.
I Heart Sorting Networks
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"
This type of development actually works quite well in some cases. My group is contracting for a large company, and are developing/maintaining an internal website for different parts of the company. We often go to the customers themselves and see what they want. We develop something, have them test it, and request changes, upon which we implement right away.
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.
A unique way to learn a language: http://languageloom.com
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.
Works for me. It requires supporting disciplines, though. In my view, that includes a well-meshed team, a very disciplined product management process, strong automated testing, a relentless devotion to code quality, and continual examination of your architectural choices.
It also works for plenty of other people. Flickr released every few hours, and they ended up selling for $20m after 18 months of work. YouTube releases once a week for interface changes and once a month for database changes, and they always have. At a billion views a day, I'd call them pretty successful.
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.