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."

This has nothing to do with Web 2.0

[chatgris]

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.

Free labor, really.

[rodrigoandrade]

I think this has more to do with the free man-hours devs get from users testing amd troubleshooting their products, then anything else, really.

Not feasible in some markets

[the4thdimension]

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.

Noise to Signal Ratio

[Daryen]

In my experiences with developing and using web 2.0 apps I have found that there is a lot of problems with useless information.

The perfect example of this is Slashdot, even with the moderation system it is still full of useless, off topic, biased, and jaded information. This isn't to bash Slashdot, it is far and above one of the best communities around.

The problem with using Web 2.0 is how much work it is. If you require registration than you will have to maintain logins, and if you don't you have to deal with hordes of advertising spam and junk posts. Even if you do maintain logins you'll still have to sort out unsavory individuals somehow.

Most corporate websites won't have the kind of dedicated moderation staff Slashdot and other community driven sites have, so the problem will be even worse.

Application developers will need to think long and hard about whether a truly "web 2.0" system of application development is worth the work it will create.

WTF?

[topham]

"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.

Re:WTF?

[D Ninja]

Kind of makes me wonder what the other 43 percent of respondents thought would be good requirements for future developers...

(fr)Agile

[lateralus_1024]

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.

No thanks

[Collective 0-0009]

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!

Re:WTF?

[micromuncher]

Agree; 9/10 of the developers I know have no problem solving skills. Got so frustrated in one code review recently I yelled at the guy "Didn't you take the same courses I did?" We graduated compsci together. He was using floats for UIDs, arrays/iterative searches for keyed lookups, and violating encapsulation at every turn. Algorithms, data structures, complexity, and OOP 101 were foreign concepts.

You can lead an ass to water, but you can't make him drink.

Re:Prior art

[samkass]

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.

It's even better

[Moraelin]

It gets even better. "Fifty seven percent of the respondents said that problem-solving and analytical skills will be key requirements for next generation developers." Heh, so then the other about 43% believe that you can be a developer/programmer _without_ problem-solving and analytical skills? And, wait, it's supposed to be a new and web-2.0 thing that now a whole 57% see a need for those skills? I.e., that previously even _more_ PHB's thought that any drooling retard is just as fit to be hastily drafted into programming?

I mean, geesh, every single method you write _is_ problem solving, and involves analytical skills. It's design all the way to the bottom, to paraphrase the old turtle quote. You may get the big structure handed to you from some architect, but every single decision like "do I split this loop into a separate method?" or like "do I use <insert patern> here?" _is_ a design decision, and _is_ problem solving.

It's all designing one big huge Rube Goldberg-style, incredible machine out of the available blocks and patterns. And sometimes given frameworks and libraries that fit the problem at hand at hand, well, just about as much as a model boat, a pool table and an anvil fit the problem of catching a mouse. And you have to figure out how to fit it all together. And at any time analyze what you have, what is still missing after taking the existing parts into consideration, etc. And you must also achive the secondary goals of security, maintainability, and the like. Surely nobody thinks you can solve such a problem -- or any other problem, for that matter -- without problem-solving skills, right?

Well apparently wrong. Almost half of the polled people actually do think that you don't need problem-solving skills.

It would explain a lot about the sad state this industry is in...

Re:"Perpetual beta" = it sucks, forever

[pdq332]

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.

Re:oh comon

[Bogtha]

"Incremental, fast and includes clients" certainly has the risk of scope creep, but with proper change management, that can be mitigated. The benefit, however, is transparency. You don't get the developers going off and wasting lots of time building the wrong thing. You don't get a continual state of development where it's never production-ready. The end effect is that it breeds a culture where you get used to delivering production-quality code. It sounds pathetic, but that's actually a rare skill. There's far less opportunity to dig yourself into a deep hole of failure, because as soon as you get a few inches down, the clients start complaining and your management can't make excuses.

So yesteryear's developers didn't solve problems?

[hawkeesk8]

"problem-solving and analytical skills will be key requirements for next generation developers" Are they kidding me? Since when was this requirement "new"? The problem that will confront your typical corporate development environment will be the same problems that have *always* confronted large bureaucratically heavy development environments. The list starts with the fact that the shear size of such environments makes it near impossible for them to be agile. That is why most great new stuff comes from small start-ups. The business model of large corporations is risk adverse and would rather wait to see what is trendy and then just buy it (and thus destroy it.)