Ask Slashdot: Why Do Popular Websites Add New Features So Sparingly?
dryriver writes: If you are a user of a popular professional desktop software program, it is not uncommon for that program to get anywhere from 5 to 20 major or minor new features and functions about once a year to stay desirable and competitive. But it seems that hugely popular internet-based sites and services like Instagram, Facebook, YouTube, Google Search, Gmail, Outlook, WhatsApp, Telegram and others get major new features/changes much, much slower than desktop software. Quite often you'll come across a barrage of breathless news articles that say "Popular Internet Service X will add Y feature starting from April 1st." It is often one single and very obvious feature or functionality being added that people have wanted for years, not a cluster of 5 or 10 funky new functions at the same time.
Why is this the case? How is it that desktop software with just a few hundred thousand users and no more than a few dozen coders working can add 5 to 20 major new functions in just one year, and do this year after year, but a major internet-based service with tens or hundreds of millions of users and presumably hundreds or thousands of techies working behind the curtain keeps everyone waiting three years or longer to build a much requested feature into the system, and then only rolls out that one desired feature to great fanfare as if it is a huge achievement? Is it really that much harder to code major new features into an internet/cloud service, versus coding major new features into desktop software; or is this a deliberate business model that has become popular?
Why is this the case? How is it that desktop software with just a few hundred thousand users and no more than a few dozen coders working can add 5 to 20 major new functions in just one year, and do this year after year, but a major internet-based service with tens or hundreds of millions of users and presumably hundreds or thousands of techies working behind the curtain keeps everyone waiting three years or longer to build a much requested feature into the system, and then only rolls out that one desired feature to great fanfare as if it is a huge achievement? Is it really that much harder to code major new features into an internet/cloud service, versus coding major new features into desktop software; or is this a deliberate business model that has become popular?
A major service website (like the ones listed in TFS) is defined by its basic function. Facebook provides communications between users. Google is a search engine, Outlook is a mail program, YouTube shows videos. Once the major function of the website is defined and accepted, adding new features and functionality will be confusing and offputting to the users.
Applications, on the other hand, must support new types of data, new data locations (ie cloud services), different display and printing options and etc. In terms of continually updating applications is for some vendors (*cough* Microsoft *cough*) is a source of revenue.
When you talk about why are there lots of coders for websites versus few for Applications, I would point out that you aren't looking behind the scenes at a website - many coders are required to implement new technology to bring the services faster and more reliably to more users as well as keeping ahead of the bad guys.
Mimetics Inc. Twitter
...the desktop software is the product, and thus needs to be upgraded for the revenue stream to keep up.
For all of the web sites cited, YOU'RE the product, and you can't be upgraded.
Actually is is more complex then that.
Factor 1: Money, A website will normally make its money by the number of people using the site. Vs an Application that needs people to buy it.
So to get more money out of the customer you make an app and add new features they may or may not need, just so people will pay for the upgrade.
Factor 2: You deploy to everyone. A feature will normally be a trade off of some sort. So you can't use a website at version 3 while someone else uses version 2 unless you have a complex set of compatibility layers going on. Which in itself causes probable because version 3 has 4 feature that version 2 doesn't and the guy on version 2 really wants that one feature added to his version. However the others on version two doesn't. For the application owner if they are on version 2 they can wait for version 4 which fixes the problem in version 3 that they didn't like.
Factor 3: Wider audience. Just as Slashdot beta has such a backlash, when there is a big audience the minority is bigger and has a much louder voice.
If you have 100 users 1% hates the upgrade you get one annoyed customer which you can deal with. If you have 1,000,000 customers then that 1% would be 10,000 annoyed customers, who will then gang up and be a real force to recon with. Vs not changing stuff then the people who want new stuff would be arguing what in particular they want.
Factor 4: What is broke for some is fine for others, and also what is fine, may actually be a problem in the future. The old Slashdot in the late 1990's didn't have the DOM comment system. You clicked on Reply it would bring you a reply screen, once you were done it would then reload all the comments back. Taking a lot of bandwidth that isn't needed for a few kilobytes of data saved.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.