Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Web 2.0 Lessons For Corporate Dev Teams

CmdrTaco posted more than 6 years ago | from the august-came-early-this-year dept.

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

cancel ×

142 comments

Sorry! There are no comments related to the filter you selected.

oh comon (0, Interesting)

Anonymous Coward | more than 6 years ago | (#24277337)

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.

Re:oh comon (2, Informative)

lethian (1288114) | more than 6 years ago | (#24277673)

I believe Meebo.com uses this development method. It seems to work well for them.

Re:oh comon (4, Interesting)

Normal Dan (1053064) | more than 6 years ago | (#24277915)

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.

Re:oh comon (2, Interesting)

Knuckles (8964) | more than 6 years ago | (#24278123)

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:oh comon (2, Interesting)

jeffshoaf (611794) | more than 6 years ago | (#24278721)

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

Re:oh comon (1)

dubl-u (51156) | more than 6 years ago | (#24279079)

I guess it's safe to assume that the internal website isn't subject to SOX compliance requirements...

It depends on your SOX auditor, but if you've got a sane one, there's no reason you can't follow an agile process with, at most, minor modifications from what you'd see in an Extreme Programming book.

Re:oh comon (4, Informative)

dubl-u (51156) | more than 6 years ago | (#24278251)

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.

How does this work in regulated industry? (1)

HeWhoMustNotBeNamed (1058944) | more than 6 years ago | (#24279035)

How does this work in regulated industries like insurance where changes affecting pricing and eligibility require filing updates to the manual with each state's Department of Insurance?

Re:How does this work in regulated industry? (1)

dubl-u (51156) | more than 6 years ago | (#24279173)

How does this work in regulated industries like insurance where changes affecting pricing and eligibility require filing updates to the manual with each state's Department of Insurance?

Good question. Maybe somebody who does that kind of work can speak up, but here's my take:

My first move would be to put a bunch of unit and acceptance tests around pricing and eligibility code. If we know we can't accidentally trigger a regulatory refiling, then we could change the system in other ways fearlessly.

Once you know you can't break things accidentally, then it seems like you could throw the question back in the laps of the guys in suits. If they request a change that requires re-filing everything, then you tell them so. If they want it, that's great. If not, that's also great.

It's even better (2, Insightful)

Moraelin (679338) | more than 6 years ago | (#24278397)

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:It's even better (1)

The Redster! (874352) | more than 6 years ago | (#24280033)

Was worried by that survey myself. So I went hunting for the actual survey article [computerworld.com] . Sounds like they were picking one of several "most important" skills. I would guess(hope) the other 43% chose other options because either they already have a steady supply of developers with problem-solving skills, or they're respondents who are proficient in those other skills hoping for a job.

Re:oh comon (2, Insightful)

Bogtha (906264) | more than 6 years ago | (#24278581)

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

Re:oh comon (1)

asplake (1222050) | more than 6 years ago | (#24280335)

In many contexts - mine being a large trading system for which I'm dev manager - scope screep isn't even a problem to be mitigated. Our job is to please our clients by delivering maximum business value, and it's inefficient (and even unreasonable) to demand perfect requirements before any work gets done. Change management for me is simply about having the tools to know exactly what I'm releasing and the confidence that changes have been tested adequately, not about constantly pushing back on change.

Re:oh comon (1)

bberens (965711) | more than 6 years ago | (#24280495)

I've found this only works if you have a client who doesn't want to force you into a fixed bid contract. That also means that you've got a history with the client and they already trust you.

Re:oh comon (0)

Anonymous Coward | more than 6 years ago | (#24278695)

emerge world?

It really, really works but... (2, Interesting)

Coldmoon (1010039) | more than 6 years ago | (#24278789)

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

This has nothing to do with Web 2.0 (5, Insightful)

chatgris (735079) | more than 6 years ago | (#24277359)

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.

Re:This has nothing to do with Web 2.0 (1)

pohl (872) | more than 6 years ago | (#24277951)

It's unfortunate that you were moderated a 'troll', when it's obvious that you're correct on this. Agile methods predated Web 2.0, and it's tragic that the latter movement is somehow getting credit, in this article, for the former. What's next? Is Web 2.0 going to get credit for OO?

Re:This has nothing to do with Web 2.0 (3, Funny)

johannesg (664142) | more than 6 years ago | (#24278091)

Agile ... the Next Big Buzzword.

The irony just drips off the page.

Re:This has nothing to do with Web 2.0 (1)

bytesex (112972) | more than 6 years ago | (#24278487)

Some people are just too young to remember, you know. They came about when agile was /old/.

Re:This has nothing to do with Web 2.0 (1)

johannesg (664142) | more than 6 years ago | (#24280975)

I know. Although I haven't really seen any major new methodology rise since Agile. Maybe I'm losing track. Maybe you should get off my lawn.

Re:This has nothing to do with Web 2.0 (2, Interesting)

dubl-u (51156) | more than 6 years ago | (#24278321)

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.

Web 2.0 usually have very short life span (0)

Anonymous Coward | more than 6 years ago | (#24279511)

Unlike software which have a shelf live of a few years. Web 2.0 projects rarely last a few months.

Free labor, really. (2, Insightful)

rodrigoandrade (713371) | more than 6 years ago | (#24277381)

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.

Re:Free labor, really. (2, Interesting)

AndGodSed (968378) | more than 6 years ago | (#24277469)

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. (2, Interesting)

Animats (122034) | more than 6 years ago | (#24277565)

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:Free labor, really. (1)

dubl-u (51156) | more than 6 years ago | (#24278555)

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.

That's definitely one source of benefit. And generally, people are happy to give it. There are a variety of beta-quality products I use, and am glad to give early feedback because it helps me get a product more in line with what I want. When I don't have the time to deal with beta-quality stuff, I pay up for a finished product.

From a developer perspective, I love this, too. You never really know what people are going to do with something until you give it to them. If you're Microsoft, you'll sit there piling up several years' worth of guesses, and then find out all at once how you did. I think it's much safer and saner to release early and often, so you can correct your small problems before they become big ones. If I had to pay users to do that, I probably would, but so far, there seem to be plenty of free ones.

Re:Free labor, really. (1)

RAMMS+EIN (578166) | more than 6 years ago | (#24280613)

I disagree. I think agile development (not web 2.0 - whatever that is) is really a useful methodology. Rather than developing the product for an extensive period of time and finally confronting the customer with what you've cooked up, you periodically show them what you've made and let them provide input on future directions. As a customer, I would like that. I can see progress is being made, and I can spot early if things are going in a direction I don't like.

On the other hand, I have come to appreciate the waterfall model as well. It's good when you know in advance what you want, and it makes it easy to assign different people to work on different parts of the system. When done right, I think it can save a lot of overhead compared to agile development, and you know what you will finally end up with. As a customer, I would value that, because I can go about my business while the software is being developed by others. I'd still want to check on them once in a while, though; something that most customers I've dealt with actually don't seem to do.

So I think both models have their strength. Waterfall is good if you know or can determine in advance what you want built. You analyze the requirements, design the beast, and implement it, and if the specification was good and the devs and testers did their job, you'll have a product that does exactly what you ordered. Agile is good if you don't exactly know what you want. It fits an evironment where there is lots of innovation or competing products - you'll want to add features as you go, in response to changing ideas of what you think will drive customers to you. Waterfall is awful for that, because your product will be outdated by the time it is finished. On the other hand, agile doesn't give you much of an indication of what you will eventually end up with and what it will cost you.

Prior art (5, Informative)

heffrey (229704) | more than 6 years ago | (#24277423)

This is called "agile development" and pre-dates Web 2.0 by around 10 years. Taco's having a bad day it seems.

Re:Prior art (0)

Anonymous Coward | more than 6 years ago | (#24277889)

You think Taco knows enough about real software development to understand this?

Re:Prior art (3, Interesting)

Black-Man (198831) | more than 6 years ago | (#24277981)

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:Prior art (4, Insightful)

samkass (174571) | more than 6 years ago | (#24278013)

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.

Re:Prior art (1)

heffrey (229704) | more than 6 years ago | (#24278387)

Well I'm sure agile goes back right to the start of software development. It's the natural way for very small teams to work. But agile the "movement" didn't really crystallise until around 10-15 years ago.

I suppose all this is my point. Anyone who things these methods were pioneered by Web 2.0 knows very little about software development.

Re:Prior art (1)

quanticle (843097) | more than 6 years ago | (#24280651)

You can really easily end up chasing your own tail or always being behind the ball because you're always reacting instead of acting.

Too true. However, I'd argue that a well-managed agile process can give you more initiative. There's nothing quite like coding up a feature, putting it before the product development people, and getting feedback, all within a workday.

As you say, though, it has to be well managed, with a strong project manager who can step on behalf of the developers when the product development folks ask for features that would be prohibitively costly or time consuming to implement.

Re:Prior art (-1, Offtopic)

sm62704 (957197) | more than 6 years ago | (#24278257)

Taco's having a bad day it seems

You mean CmdrTaco. "Taco" is a Mexican guy here in Springfield who is surely having a far worse day than CmdrTaco. He just got out of the hospital; he was in a taxi that got T-boned by an SUV. Broke a lot of bones and had a lot of internal injuries. The guys down at the Blue Grouch tell me he's using a walker.

Worse, his girlfriend's butt ugly, too.

Re:Prior art (1)

The End Of Days (1243248) | more than 6 years ago | (#24279615)

I gotta wonder, do you ramble on about nothing in particular to people around you, as well?

"Perpetual beta" = it sucks, forever (4, Interesting)

Animats (122034) | more than 6 years ago | (#24277435)

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:"Perpetual beta" = it sucks, forever (1)

iMac Were (911261) | more than 6 years ago | (#24277935)

Tribe was a nice little social networking system for people in the San Francisco area. Tribe is now down to two employees and a fraction of its user base of two years ago.

That's because they all died of AIDS.

Re:"Perpetual beta" = it sucks, forever (4, Insightful)

pdq332 (849982) | more than 6 years ago | (#24278421)

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:"Perpetual beta" = it sucks, forever (1)

dubl-u (51156) | more than 6 years ago | (#24278597)

I'm not impressed with the "perpetual beta" and "using your users for Q/A" concept. Remember, the users can leave.

The upside is that if you do it right, they're more involved than ever. Google was in beta for years, as was Flickr. I was fine with that; being an early adopter and watching the product evolve was exciting, especially when they did something in response to user feedback.

Re:"Perpetual beta" = it sucks, forever (1)

brianjlowry (1015645) | more than 6 years ago | (#24280471)

Additionally, when I visited Tribe.com, I received a 404... maybe they are gone for good.

Re:"Perpetual beta" = it sucks, forever (1)

Animats (122034) | more than 6 years ago | (#24280705)

Additionally, when I visited Tribe.com, I received a 404...

Try "tribe.net [tribe.net] . Looks like somebody forgot to update "tribe.com", which "tribe.net" apparently owns but is in domain hold for bogus Whois info.

Hrm... (0)

Anonymous Coward | more than 6 years ago | (#24277439)

The bottom-line: corporate development teams need to get to know their users."

Corporate developers dating their users! More at 11.

Re:Hrm... (1)

sm62704 (957197) | more than 6 years ago | (#24278571)

Corporate developers dating their users! More at 11.

Carbon dating or more modern methods of determining age?

Not feasible in some markets (3, Insightful)

the4thdimension (1151939) | more than 6 years ago | (#24277447)

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.

Re:Not feasible in some markets (5, Interesting)

dubl-u (51156) | more than 6 years ago | (#24278361)

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:Not feasible in some markets (1)

quanticle (843097) | more than 6 years ago | (#24280711)

At the same time, some of the lessons of Agile development may still be of use to. For example, the Agile method advocates heavy use of unit and integration tests to establish a baseline for current behavior and to catch regressions. This attitude towards automated testing is useful no matter which industry one is in.

Open source at work (1)

DavidPutnam (1330049) | more than 6 years ago | (#24277461)

It's almost too obvious, isn't it? Look at what everyone else is doing and copy the things that work the best. Oh well, somebody gets to make a living by pointing things like this out.

Not Web/2.0 but open source... (1)

pieterh (196118) | more than 6 years ago | (#24277465)

Very few web/2.0 apps are open source, and while this makes a nice buzzword it hides the truth: the real revolution in software development, still not practiced in many corporates, is the competitive, open, standards based approach used by open source teams.

You cannot do "incremental releases" to products used in critical systems (the risk is too high) but you can make the technology transparent, easy to understand, easy to contribute to, and based on clear standards.

eggs in space of qiuery cataplasm (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24277483)

elf smolny friend Lebedour? Cat is what power oif ten song busted!

Re:eggs in space of qiuery cataplasm (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24278519)

This is Topic 2.0, doofus, get with the program.

Noise to Signal Ratio (2, Insightful)

Daryen (1138567) | more than 6 years ago | (#24277495)

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.

Re:Noise to Signal Ratio (5, Interesting)

pavera (320634) | more than 6 years ago | (#24277771)

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:Noise to Signal Ratio (1)

Knuckles (8964) | more than 6 years ago | (#24278173)

And it's good to remember that nothing of this has anything to do with Web 2.0 :)

Re:Noise to Signal Ratio (1)

dubl-u (51156) | more than 6 years ago | (#24279025)

And it's good to remember that nothing of this has anything to do with Web 2.0 :)

I think the one tie is that before Web 2.0 a lot of people would hear about these approaches and say "unpossible!" Now that you can point to plenty of successes that work like this, people can't be as casually dismissive.

Re:Noise to Signal Ratio (1)

quanticle (843097) | more than 6 years ago | (#24280801)

I think the one tie is that before Web 2.0 a lot of people would hear about these approaches and say "unpossible!" Now that you can point to plenty of successes that work like this, people can't be as casually dismissive.

Perhaps. But, another equally likely scenario is that this sort of fast development cycle was impossible back then. Many of the tools and languages advocated by Agile proponents and Web 2.0 startups have only come into prominence over the last few years. One of the most important things for Agile development is thorough, robust tool support. Its much more difficult to do Agile/Web 2.0 development without IDEs, unit testing frameworks, and version control/configuration management. As these tools have caught on in the corporate world, using the Agile process has become much easier.

Re:Noise to Signal Ratio (1)

megaditto (982598) | more than 6 years ago | (#24277947)

Bad SNR on Slashdot? You must have a very low tolerance for noise in that case.

On a typical article of 200-300 posts you get maybe 5-10 useless ones (1. frist psot 2. goatsex suxors 3. turd in the library 4. racist junk for the sake of racism 5. some redundant posts giving the same wikipaedia link 6 times withint one minute)

That's pretty much it, unless you consider ideas you disagree with to be noise (in which case you should remember that there is no "-1, I Disagree" moderation option)

Re:Noise to Signal Ratio (1)

larry bagina (561269) | more than 6 years ago | (#24278215)

You forgot the lame jokes, the followups by people explaining it was a joke, the followups by people who didn't realize it was a joke and try to repeat it, the complaints about the editors, the complaints about the moderators, the dupe/oldnews posts, and the people who didn't read the article and comment on something unrelated.

Re:Noise to Signal Ratio (1)

BigDogCH (760290) | more than 6 years ago | (#24278987)

Oh, and the posts that summarize the different types of posts. And the posts that add one last thing that the previous poster forgot.

How Slashdot "sort(s) out unsavory individuals" (0)

Dareth (47614) | more than 6 years ago | (#24278121)

Slashdot sorts out unsavory individuals by modding their wicked humor up! +1 Funny

Mods, please note: this post is Insightful!

Re:Noise to Signal Ratio (1)

bytesex (112972) | more than 6 years ago | (#24278927)

Trust me, slashdot was like this way before the first person coined the term 'web 2.0'.

Just like I was tell my boss last night (5, Funny)

Anonymous Coward | more than 6 years ago | (#24277499)

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.

Re:Just like I was tell my boss last night (1)

bytesex (112972) | more than 6 years ago | (#24278957)

Thank you. I needed that. I must admit - I was out of touch.

Business-speak (1)

Nerdposeur (910128) | more than 6 years ago | (#24279003)

...is often no better than literary mumbo-jumbo. Like this article mentioned in XKCD, where the creator of deconstruction (a literary method) describes why he created it:

This type of device may have enabled me to detect not only in the history of philosophy and in the related socio-historical totality, but also in what are alleged to be sciences and in so-called post-philosophical discourses that figure among the most modern (in linguistics, in anthropology, in psychoanalysis), to detect in these an evaluation of writing, or, to tell the truth, rather a devaluation of writing whose insistent, repetitive, even obscurely compulsive, character was the sign of a whole set of long-standing constraints. These constraints were practised at the price of contradictions, of denials, of dogmatic decrees.

It's always nice to see blatant garbage ridiculed. Thanks. :)

Conservative dev orgs have trouble with security (1)

postbigbang (761081) | more than 6 years ago | (#24277505)

Web 2 techniques aren't grounded in the older data processing profile at all, and coding techniques are perceived to allow wicked security holes if underlying data sources aren't totally bolted down.

The concept of hot mashes makes sense, but a lot of web apps are based on browser screen scrapes with forms handling parsers and forms retrieval. When you add layers on top, it's possible to both mangle data and mis-represent what's going on in the back end. Translation: a layer of disconnect with potentials for abuses occurs if standards aren't enforced, and QA is taken out of the loop. Worse, with big hammers you can break anything and with the number of php advisories I've seen as an indicator, corpdevguys are going to face a lot of audit problems.

Re:Conservative dev orgs have trouble with securit (0)

Anonymous Coward | more than 6 years ago | (#24278531)

Test

Web 2.0 techniques (1)

rs232 (849320) | more than 6 years ago | (#24277507)

"Web 2.0 techniques, specifically the incremental feature releases, quick user feedback loops and quality assurance programs that include users"

Didn't that used to be known as Open Source methodology ?

Re:Web 2.0 techniques (0)

Anonymous Coward | more than 6 years ago | (#24277585)

Minus the "source" and "open" parts, yes. And neither really has any "methodology".

WTF? (5, Insightful)

topham (32406) | more than 6 years ago | (#24277511)

"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? (5, Insightful)

D Ninja (825055) | more than 6 years ago | (#24277765)

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

Re:WTF? (4, Funny)

Zerth (26112) | more than 6 years ago | (#24278297)

If they thought problem solving skills were superfluous, it is because they think developers just do what they're told. So probably "listening" skills and good handwriting topped their list.

Possibly powerpoint assistance, formatting support, and powerswitch finding to round out the top five.

Re:WTF? (1)

pruneau (208454) | more than 6 years ago | (#24279167)

Don't worry, those were mostly managers or HR people...

Re:WTF? (1)

D Ninja (825055) | more than 6 years ago | (#24279203)

Ah...but that's precisely what worries me...

Re:WTF? (1)

iMac Were (911261) | more than 6 years ago | (#24279437)

Nice butts. Or big boobies, if you're one of those kinky people who likes to put their wee-wee into a different kind of wee-wee. Euwwww!

Re:WTF? (1)

nfk (570056) | more than 6 years ago | (#24279545)

Problem-creating and synthetic skills, naturally. The software is terrible, but the shrewd marketing compensates.

Re:WTF? (0)

Anonymous Coward | more than 6 years ago | (#24280397)

Missing from the article:

"Fifty seven percent of the respondents said that problem-solving and analytical skills will be key requirements for next generation developers, while the other 43 percent of respondents ranked T&A skills as their top priority."

Re:WTF? (2, Insightful)

micromuncher (171881) | more than 6 years ago | (#24278011)

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:WTF? (2, Funny)

Knuckles (8964) | more than 6 years ago | (#24278241)

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

Of course, it's the wrong end!

I would wait for Web 2.1 (5, Funny)

mrroot (543673) | more than 6 years ago | (#24277521)

.0 releases always have alot of bugs.

Re:I would wait for Web 2.1 (3, Funny)

Hemogoblin (982564) | more than 6 years ago | (#24278919)

Personally, I'm waiting for "Web for Workspaces 3.1".

A.B.B. (1)

Mean Variance (913229) | more than 6 years ago | (#24277523)

Always Be in Beta. (Picture Alec Baldwin saying that in your face over and over.)

Iterative development superior to Waterfall?!? (1)

ActusReus (1162583) | more than 6 years ago | (#24277525)

Much like everything else thrown under the "Web 2.0" umbrella, this story is more 1990's rehash... where someone applies new marketing gloss and pretends it's a new idea.

Redundancy (1)

Narpak (961733) | more than 6 years ago | (#24277537)

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

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

Is it just me, or is this a bit redundant.

But what's the scheme? (1)

krkhan (1071096) | more than 6 years ago | (#24277781)

development teams could benefit from Web 2.0 techniques, specifically the incremental feature releases

You mean we'll have even number branches (e.g. Web 2.2 and Web 2.4) for stable releases?

(fr)Agile (3, Insightful)

lateralus_1024 (583730) | more than 6 years ago | (#24277817)

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.

Re:(fr)Agile (1)

dubl-u (51156) | more than 6 years ago | (#24278677)

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.

You're right; that is a common mistake.

In my view, Agile development is all about making feedback loops effective and fast. Even if you're releasing software regularly, that isn't enough; you have to see how it's affecting the users. Maybe that means developers are directly involved and maybe not, but you should certainly be sitting within easy conversational distance of somebody who does spend a lot of time studying your users.

In short, you're right: going faster doesn't help if you don't look where it's getting you and steer accordingly.

Re:(fr)Agile (1)

BVis (267028) | more than 6 years ago | (#24280357)

They had Marketing handling the beta at my last job. Which is one of the reasons that I'm not there anymore.

Seriously, on what planet is this a good idea? The ability of the average Marketing drone to communicate even the highest level information regarding a problem (for example, 'the website is down' when there's really just a typo on the homepage) is dangerously poor.

It seems to me that agile development is the key to bypassing Marketing altogether. Once the clients start realizing "Hey, we can tell the developers what's broken directly instead of dealing with that twit with the plastic smile and no clue in Marketing," then we'll finally be able to fire all those useless hunks of dead weight and actually start providing the customer with what they need, not what Marketing tells them they need. (Or, even worse, marketing promising the customer the sun, moon, and stars in a man-month, and then getting pissy when reality sets in and what they promised can't be delivered.)

Marketing shouldn't be let within 50 feet of any kind of technical feedback process. They might spill their lattes on it.

No thanks (3, Insightful)

Collective 0-0009 (1294662) | more than 6 years ago | (#24277819)

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:No thanks (1)

dubl-u (51156) | more than 6 years ago | (#24278453)

I hate the bombardment of updates I have to run now. Windows, Adobe, some install manager, Adobe, Java, Abobe... You get the idea.

Well, I'd more call this "Agile done stupid". It's possible to make automatic update processes pretty much seamless from the user's perspective. That some companies aren't good at paying attention to what the user actually wants is a problem that predates Agile methods.

So companies that like to sell software based on 12-18 month releases will never move to a true "agile" development...

I don't think that's necessarily the case. The excellent Java IDE has release and early-access versions. The release version costs money and has a new version every year or so. The early-access version is free, beta quality, comes out frequently, and expires every month or so. Users can pick whether they want stability or features more. This has been working well for them for the last few years, and could see it working well for a lot of people.

Re:No thanks (1)

RAMMS+EIN (578166) | more than 6 years ago | (#24280475)

I am so happy I found Debian. Upgrade your whole system with a single command. And if you run stable, you don't even get newer versions of software - you just get (backported) security fixes. Once it works, it just keeps working. It's almost a pity that a certain release will only be supported for a number of years...

Web 2.0 Lessons For Corporate Dev Teams (2, Funny)

BigGerman (541312) | more than 6 years ago | (#24277827)

you mean, like, "don't"?

Article Summary (1)

littlewink (996298) | more than 6 years ago | (#24277851)

Five Web 2.0 app dev lessons for enterprise IT

  1. Break the barrier between developers and end users and involve users in quality assurance processes.
  2. Keep it simple [i.e., start simple and add as you go].
  3. Stick to the script [i.e., use a scripting language].
  4. Release early and often.
  5. Let the users, not the developers, determine new features.

Nothing new here.

Updates (1)

shagymoe (261297) | more than 6 years ago | (#24277973)

And with all of these little incremental updates, how do you not kick all of your users off of the system repeatedly? Sit around and wait for everyone to log off?

Persistent sessions (1)

dereference (875531) | more than 6 years ago | (#24278245)

I'll assume you're not trolling here. If you find you're ever kicking off all your users to deploy an update, you're doing it wrong. Session persistence is supported by most useful production servers. This can be used to share sessions among nodes of a very small cluster (even two instances of the server running on one machine) or simply save the sessions to disk and restore them after restarting the system. With a little forethought regarding backward compatibility, you won't have any problems. And your users will still be logged in.

Re:Updates (1)

dubl-u (51156) | more than 6 years ago | (#24278471)

And with all of these little incremental updates, how do you not kick all of your users off of the system repeatedly? Sit around and wait for everyone to log off?

Depends on your technology, but by and large you build things in such a way that you can shift load around without people noticing. In web-land, that's generally done with load balancer tricks when upgrading the front end, and a smart service layer when upgrading back-end apps.

Next generation developers??? (1)

HikingStick (878216) | more than 6 years ago | (#24278425)

Fifty seven percent of the respondents said that problem-solving and analytical skills will be key requirements for next generation developers

Next generation developers? I thought those were already requirements. Wait! Did someone not tell Microsoft?

"We know what the user wants. The user wants stuff that looks cool."

~ A quote from a formerly employed programmer.

Next on Web 2.0 (0)

Anonymous Coward | more than 6 years ago | (#24278507)

Web 2.0 companies discover that adding more people on a project doesn't scale as well as previously thought, dubbing what is known in "corporate development teams" as the "man-month" is more "myth than fact" ...

So yesteryear's developers didn't solve problems? (2, Insightful)

hawkeesk8 (682864) | more than 6 years ago | (#24279171)

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

Just as long as you have a vision (1)

gilgongo (57446) | more than 6 years ago | (#24279801)

Incremental change is all fine and dandy, but it can still end up as a pile of crap unless the whole team understands what the "vision" is.

Faced with a billion emails from customers all suggesting different and often conflicting things, people on the team with their own hobby horses and pet projects, and countless other influences along the way, you need to ask "Why? How does this help us become a ?"

Excellent idea to monetize web 2.0 dev practices (1)

di'jital (83268) | more than 6 years ago | (#24279991)

1) Take "The Mythical Man Month",

2) Create a new cover using pastel colors, and put a glossy gradient badge on the cover saying "Web 2.0"

3) Publicize your new edition to a bunch of Web 2.0 Blogs as "revolutionary new insights".

4) Profit!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?