Slashdot Log In
Web 2.0 Lessons For Corporate Dev Teams
from the august-came-early-this-year dept.
Related Stories
This has nothing to do with Web 2.0 (Score:5, Insightful)
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.
Agile
The irony just drips off the page.
Free labor, really. (Score:2, Insightful)
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 (Score:4, Interesting)
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 (Score:5, Insightful)
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.
"Perpetual beta" = it sucks, forever (Score:5, Interesting)
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 (Score:4, Insightful)
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.
Not feasible in some markets (Score:3, Insightful)
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 (Score:5, Interesting)
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.
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.
Noise to Signal Ratio (Score:2, Insightful)
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 (Score:5, Interesting)
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"
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.
Didn't that used to be known as Open Source methodology ?
"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.
Kind of makes me wonder what the other 43 percent of respondents thought would be good requirements for future developers...
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.
I would wait for Web 2.1 (Score:5, Funny)
Re:I would wait for Web 2.1 (Score:4, Funny)
Personally, I'm waiting for "Web for Workspaces 3.1".
"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.
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?
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!
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?
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.
So yesteryear's developers didn't solve problems? (Score:2, Insightful)
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 ?"
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!
..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...
Re:oh comon (Score:2, Informative)
Re:oh comon (Score:5, Interesting)
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 (Score:5, Informative)
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.
It's even better (Score:3, Insightful)
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...
Corporate developers dating their users! More at 11.
Carbon dating or more modern methods of determining age?
Re:oh comon (Score:3, Insightful)
"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.
It really, really works but... (Score:2, Interesting)
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...
And when was the last development team you've seen actually try? We geeks prefer to hide in cubicles instead of working with people, and management prefers 12 year plans.
It's not just the dev teams responsibility.
Management has to enable and support this as well, not in the least by kicking some non-dev butt when needed.
With a mature methodology, consequently applied, and management buy-in; there is little reason why working smarter AND better wouldn't work.
