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 approach really isn't feasible in certain markets, even though I can agree it would help. 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.
I wouldn't be surprised to find that many other markets are regulated in a similar fashion that prevents this.
Crackin' Wise - Blogging about whatever we want
"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.
I happen to be knee-deep in Agile development in a corporate environment, as a lowly junior developer. The teams are definitely meeting every day and it is hyper-collaborative in that respect but user involvement is still handled by marketing and trickles down to R&D at a slowly and ambiguously. I see this as our weak point. The slow pace could be a positive so that we don't spin out of control, but the quality of information we get is where things are most dangerous, imho. I imagine a start-up would be small enough to include developers in the customer-collaboration process.
If you think
I hate the bombardment of updates I have to run now. Windows, Adobe, some install manager, Adobe, Java, Abobe... You get the idea.
But the reality is that this "agile" stuff only makes sense if you are improving the product. I don't want to install 38 updates to get acrobat 8.1.4 and get nothing (read: improved or added features) in return! Make the product stable for 6 fscking months! Also don't realease a major update every year!
So companies that like to sell software based on 12-18 month releases will never move to a true "agile" development... that would mean upgrading features and basic functionality without the end user paying for it... GASP!
I finally updated my sig, but now it's lame.
Agile, "extreme", and other iterative development models go back more than 10 years... that's just when Extreme Programming was the buzzword and made it big. It's pretty much always been a waterfall vs. spiral world in software project planning.
And none of it has anything whatsoever to do with web 2.0.
Getting things in front of users fast is key to user acceptance. However, it has to be managed well. Users often don't actually know their requirements, and everyone has emotions and priorities that are disproportionately represented relative to their actual value. You can really easily end up chasing your own tail or always being behind the ball because you're always reacting instead of acting.
E pluribus unum
One should make a distinction between software intended for general use outside of a corporate setting and software intended for use in corporate backrooms. Agile development only works when the users are invested in the software. So you're 100% right about the former case: general users aren't usually invested enough in a piece of software to stick around and help out the developers by providing usability comments and such. People get paid to do that in corporate dev shops - why does anyone think general users will do that for free?
On the other hand, user involvement and management involvement are critical to internal corporate software development. User involvement is needed to properly understand the business cases and provide usability feedback, and management involvement is needed to make overall feature decisions with an eye on keeping down costs and enhancing efficiency. Agile development helps deliver software that addresses business issues at a low cost.
As a professional developer, the main risk is that internal users will come up with a feature request only to have it watered down or rejected by management in order to keep development costs down. Then the users are unhappy with me, I'm unhappy with the managers, and I end up providing a "most-of-the-way-there" product that satisfies no one fully, but keeps savings flowing into senior management wallets. (Management can force the users to use the software, at least until someone board member's brother-in-law sells us an alternate solution.)
But I tend to favor the Agile Development process in that case too because about the only leverage I have is the fact that I've involved the users and managers at every step, documented the software as well as the decisions, and a have trail of accepted release candidates.