What's wrong with "server/web"-based applications?

This is a response to Paul Graham's essay.

He's probably right about a lot of things. But I'm going to nitpick everything else to hell, and misquote things liberally while I'm at it.

Why am I doing this, because although the article looks well written and thorough, it's pretty much just a hodge-podge of contradictory statements. Also I'm pretty proud that I typed this whole rant and only made two obvious spelling mistakes.

The losses for users

One: your data! No their data! Instead of having your data right at your fingertips, where you can lose it. It is their data sitting on a server somewhere, and you have to hope and pray that they'll play nice and not blow it all away.

I'm not saying it's better to have to micro-manage your data, but at least you feel like you have some control.

To quote the article: "when people lose their own data, [..] they can't get that mad, because they only have themselves to [blame]. When a company loses their data for them, they'll get a lot madder." Yeah that's what I want!!! To get a whole lot madder. Like the one thing that's missing in my life is aggravation. I need to get madder, a whole lot madder! That'll make me feel good!?!? Is that what people are worried about, that computers aren't frustrating and don't make us feel powerless enough.

Two: Upgrades WILL BE BIG SHOCKS, and there's nothing you can do about them. Think about (insert name of web application or service) that changed their user interface without telling their users, and called it welcome to the new (insert name here).

Again I'm not saying everything is sunshine and rainbows, but at least if you hear Windows Vista sucks donkey balls, you can wait for Windows 7 (like I did, out of lazyness, just as much as anything else).

Again the big deal is that you get to choose when to upgrade or whether to upgrade at all. Remember "with web-based applications, everyone uses the same version" and all your base are belong to us!

Three: Web-based software "SHOULD" be "better in every way"! Web-based software "WILL" solve "every problem ever conceived"! These statements have exclamations marks here, because they are orders (or perhaps wishful thinking propaganda) and not factual statements.

Four: Did I mention upgrading stuff behind my back pisses me off? Well with "server-based software [you can do] three to five releases a day (sic!)". Yeah that's what I want, a 50% chance the webmail client I'm using will change while I'm still writing a g0d!DM email!

Remember with web-based software "you can make changes almost as [carelessly as you would if you were coding up some toy project without version control]".

Five: Incremental change? Decremental change? With small frequent changes you can't tell whether you're going up or down. I've still to see a stock-ticker type app that tells you how much or less sucky (insert-name-here) became on any particular day.

Six: Bad things are impossible by "because I said so". Right "we're thinking it's a great idea to never have to release software before it works, but what if we promised to deliver a new version of the software by a a certain data"? Oh well "with-based software you wouldn't promise that because there are no versions!" Oh right a user wants a feature and you make a promise, but you're like there are no versions, so I can't give you a date! Hang in there kiddo, it'll be in there someday, but it'll probably be incremental, and we won't tell you about it. So you know what just keep clicking refresh from now until rapture.

Seven: "Users get to debug the software"! Yippee! where do I sign up for that? And more genius stuff like we had so few bugs we didn't need a database, but of course you should test changes (what against a non-existing database) before releasing them. And "as long as you fix bugs as soon as they are reported, far fewer people will see the bugs". Oh really, that only works if you can actually fix bugs as fast as people can report them (you have no users, or your software is perfect), and you don't introduce a trillion others bugs in the process of adding every hacky fix you can think of instantly to your codeline.

By making your users guinea pigs you ensure that everyone sees bugs that only a few beta-testers should have seen. And small changes can blow lots of things when they corrupt user data that is only on your servers.

Eight: "fixing fresh bugs is easier than fixing old ones". "You're more likely to break things fixing old bugs". What is this supposed to advocate, removing fresh bugs, ignoring old bugs, adding fresh bugs?

Nine: Functional programming is awesome because without side-effects everything is easy!

Ten: "bugs became almost a game". "the users who encountered them were likely to be advanced users [...] Advanced users are more forgiving about bugs". No they are not. Non-advanced users will often think they have done something wrong. Advanced users will know when your stupid application is broken and will get madder, way madder, when there is no way to get around it.

THE BIG LIE

Adding people to a software project will slow it down!

Wrong!

Let's say 1 out of every ten programmers is super-duper-efficient.

If you have 2 programmers, chances are neither of them knows what they are doing. But let's say you're lucky and 1 does and 1 doesn't well the first guy will have to keep debugging all the crap the second guy adds, but since there's only two of them maybe he can beat the other dude up.

But as you keep adding more people the chances of getting someone who knows how to do X increases. So with 100 people, you have an X-expert, a Y-expert, a Z-expert. And they form a team of people who get things coded, and the other people can do all the other 90% of stuff that is useful and needs to be done, but programmers don't know how to do, like finding clients, and managing your budget, and testing your software (in case your users get tired of being guinea pigs).

This idea of adding more programmers and productivity (even average productivity) going down is based on the idea that you already have the dream team working for you, and you're going to add morons to the mix.

But since the variance is so high and since there are unique skills that are rare, there's probably a lot to be gained from just adding more people.

What's the catch? The original quote from the original source is right, you can't add people to a project that is late and behind schedule and suddenly fix things because everyone has to get up to speed.

But the argument for the rest of it is weak because it's based on N people communicating without hierarchy. And that's not what is going to happen. There's going to be a hierarchy, and managers will manage, and higher ups will manage them, etc. Add if there is no hierarchy one will form and then in that situation whoever knows what to do will assume leadership and force their hand or someone who doesn't have a clue will take command, but in either case n! is not what the communication will look like.

This site best viewed with Lynx or Mozilla or Konqueror or any standards compliant browser!

and also. The all-powerful ed has also contributed!.