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."
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.
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.
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.
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.
The bottom-line: corporate development teams need to get to know their users."
Corporate developers dating their users! More at 11.
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
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.
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.
My blog
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.
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.
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.
---- Teach Peace. It's Cheaper Than War.
"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 ?
davecb5620@gmail.com
"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
Always Be in Beta. (Picture Alec Baldwin saying that in your face over and over.)
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.
"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.
The Long Now Foundation
You mean we'll have even number branches (e.g. Web 2.2 and Web 2.4) for stable releases?
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.
you mean, like, "don't"?
Five Web 2.0 app dev lessons for enterprise IT
Nothing new here.
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?
Slashdot sorts out unsavory individuals by modding their wicked humor up! +1 Funny
Mods, please note: this post is Insightful!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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.
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...
A polar bear is a cartesian bear after a coordinate transform.
Next generation developers? I thought those were already requirements. Wait! Did someone not tell Microsoft?
~ A quote from a formerly employed programmer.
I use irony whenever I can, but my shirts are still wrinkled...
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" ...
Test
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...
Coldmoon over Dark water...
...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:
It's always nice to see blatant garbage ridiculed. Thanks. :)
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?
"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.)
rootsmith Inc.
Unlike software which have a shelf live of a few years. Web 2.0 projects rarely last a few months.
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 ?"
"And the meaning of words; when they cease to function; when will it start worrying you?"
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!
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.
Wishful thinking, perhaps? You can never make any change completely fearlessly in most projects. Unit tests can do a lot to help increase your confidence and catch bugs early, but they are not a substitute for knowing what you're doing and understanding its implications, and neither are they foolproof.
For one thing, it's impossible to get 100% test coverage for most projects. If you don't have full coverage, you can always break something in a gap.
For another thing, if you have a few thousand lines of code and you're worried enough about bugs to write a few thousand more lines of unit tests, how can you possibily be confident that the extra few thousand lines are themselves bug-free and testing what you think you're testing?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Well, I'm still not impressed. So basically:
- "18% cited the need to work with online communities"... as more important than analytical thinking and problem solving skills.
I'm sorry, but that skill profile fits a PR guy, or marketing, or generally your first line of interface with the users. The programmers don't and _should_ _not_ be the one working directly with a mass of 10 million online members, each wishing a different thing and half of them thinking they're so important that their question must be answered in 5 seconds flat. (I was just surfing for mods for a game, and, literally, in one thread someone had posted a _demand_ and 8 minutes later he was revolted that he's got no answer yet. Yes, 8 minutes.) You wouldn't even give that community access to your level 2 support, because, frankly, they're too expensive and a limited resource. So why would you ever let your programmers do that, to such extent that that skill is more important than the skill used in programming?
So basically 18% are truly and monumentally clueless.
- "Meanwhile, 24% said that code generation is the key long-range development skill."... so, if I get it right, it's more important to write lots of lines of code, than to be any good at actually solving a problem with it or what the problem really is.
I'm sorry, but the very existence of this category rubs me the awfully wrong way. It's the kind of people who'd think (and obviously thought) my ex-coleague Wally was a great coder, because he included whole tens of megabytes of open-source sources in his projects (with his name plastered on it.) And even stuff that had no relevance to the problem at hand. E.g., I swear to the elder Gods, I found the sources for a file chooser dialog in a server-side servlet-based project. E.g., instead of just making his ant script generate the EJB home and remote stubs (something he never really understood), he just did it by manually deploying once, and then decompiled the IBM-generated classes and included those sources in his project. Of course, now if you changed an EJB and ran the build script, you'd get the wrong stubs. (Effectively the old ones for the old class, decompiled and recompiled again.) Plus whole obfuscation layers and, I swear to the elder gods again, an (obfuscated) stateless "state machine".
But hey, it's lots of lines of code.
Briefly, I'm no less worried.
And I don't think the "already have a steady supply of developers with problem-solving skills" is an excuse at all, either way I can understand it.
Assuming you mean, basically, "they all have problem solving skills, let's test them primarily by some other criterion", that's basically based on a false premise. Like any other skill, it varies greatly among different people. So not all have it to the same extent. Some will be great at it, and some will hardly have it at all, or not enough to actually program anything more complex than "hello world". If you literally put another criterion X above it, you can literally get people who are great at X, but sucky at problem-solving.
It's, if you will, like saying that, bah, for a theoretical physicist job, surely all know physics, so you might as well test them for their appearance and social skills instead. Well, then you wouldn't have hired Einstein, for a start. You'd get someone who's sharply dressed and charismatic, because that's what you tested, but only the Gods know how much physics he actually knows. It can be anything from Feynmann to a devout Flat Earth believer with a degree in dowsing.
If you have more candidates with that skill than jobs, then sort them by skill level or even skill-per-buck, and take the best. Anything else, in end effect, is throwing your hands up and solving the wrong problem instead.
A polar bear is a cartesian bear after a coordinate transform.
use this abominable buzzword. I propose, that from now on, we should only refer to it as "The buzzword that shall never be spoken". This is because by just saying the buzzword, the fabric of space and time itself will rip apart, letting demons and the corrupted souls of marketing people into our reality.
..before they go trying to reinvent the wheel that (ironically) Toyota essentally pioneered over a decade ago with lean development.
I guess version 2.0 of the buzz word was developed too quickly for proper research into existing techniques??
LOL. It is like your 14 yr old rushing through the door to tell you something "new" and exciting they discovered just today...
Web 2.0 means that you use feedback from your customers to improve product?
This is as new and groundbreaking as the recent web 2.0 advancements enabling the Internet to just now be used for collaboration.
Finally there is this little jem "Problem-solving and analytical skills will be key requirements for next generation developers" ...
Its a good thing none of this is necessary for the current generation of developers or I would really be screwed.
Like I'm gonna explain myself. Not f'n likely. Find a thread. Login. Find yourself on /. homepage.
Incompetence is the thin edge of a wedge called corruption.
I've been on the "web" since '72.
Dealing with you has silenced me.
Which doesn't mean I went elsewhere ... ... that's what yuppies do.
bla-yada, kiddos ... yada-blah.
An arguably credible place to make plausibly legitimate arguments ... ... all the while knowing you're in no danger of entailments.
Kidz, it's cliche that the smart are stuhpuhd.
*Don't know how I am? Follow a link ... google ... I've only been online for 2 or 3 decades. fuckwads*
-- When you look to see how the system works, you usually find that it doesn't.
"Quick, incremental updates, along with heavy user involvement, are key characteristics of the emerging software development methods" Are you merely contemptuous of your readers? What part of that is anything like news? "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." Oh, so you're pimping ComputerWord? (For the record, when I wanna go to my local to get drunk, I take a copy of InformationWeek ... shit's so fine, I keep reading even when I'm drunk. Introduces an fascinating non-artistic irony into what follows.)
Why have I not introduced my discourse-based document portal? Cuz you yuppies' kidz are /just plain /stuhpud//.
Folk who earn their salt by sophistry, like other kinds of whores, are not interested in discourse.
Point: I never left. I come back. I was here. I ain't leaving.
*fuckwads*
-- When you look to see how the system works, you usually find that it doesn't.