Hacker News Reader

Comment by eagsalazar | Hacker News Reader

How many people are honestly required to maintain iGoogle? Full time? One? Two if they browse the internet most of the day.

Just leave it up for christs sake. I wonder if this isn't about forcing people to other services.

Take the developers and let it keep going. No new commits, it works!

View on HN

While that certainly does seem appealing, zombie projects can have serious impact elsewhere in the company. For instance, if a security bug is found in some piece of common infrastructure, you'll have to pull the update and deploy the new code. Seems simple, but in the months or years since the last deploy, many other pieces of infrastructure have changed and now you have to integrate, test and safely deploy a product for which nobody is familiar.

This is not just speculation, either. The project I worked on at Google had to deal with such zombie products all the time, and they were a HUGE drain on productivity for us.

There's also the whole problem where there is no love for maintenance work, and you have to create massive new systems to get anywhere. This biases things towards creation, deployment, and then flying the coop. The zombie projects which follow are inevitable.

The whole thing about "the one which is deprecated and the one which isn't ready yet" is rooted in reality.

You really think it takes 1 person to maintain iGoogle? In a corporate environment with so many users, business rules and systems/infrastructure I'd imagine it is quite a few.

No way. I'd be exceptionally surprised if more than one developer is dedicated to it. All the components inside iGoogle are already supported by their respective teams. News, Calendar, Finance -- in iGoogle these services are accessed by RSS or JSON API's that already exist.

It should theoretically be possible to make iGoogle a 100% client-side one-page app and require zero maintenance, or additional resources.

You are ignoring the cost of maintaining software. That is huge. "Working" is a relative term.

I'm not ignoring it at all. I'm just calling bullshit on the idea that the cost is anywhere near "huge".

1 developer, 75% time. That's it. If they are north of 2 developers they are doing something very wrong.

Even granting your premise, who wants to be the ONE developer stuck working on some project that clearly has no future?

Indeed, 1 google developer is going to be north of $100K/year, and if you're going to trust them to run a project, even a zombie one, probably significantly higher. Even worse is the loss of their expert advice and productivity on projects that actually deserve it.

Please explain.

I have sites that run for years without me editing a single line of code or any other sort of maintainance. Backups run automatically, so do regular clean-ups of the database and certain directories.

What sort of maintainance would you say a largely client-side application like iGoogle does require?

Edit: anybody care to explain the random downvoting?

Are your sites written in C++ and being attacked by China and Russia? Do they have plug-ins for several hundred apps, many of which work with ever changing external websites? Do your sites integrate with critical email and advertising accounts? I would not be surprised to learn they were burning $1M a year on iGoogle.

Re. random downvoting, it happens on tablets. Chill, somebody else will be along shortly to vote the comment up out of the gray.

Attacks: I would guess that is dealt with on a netwok level for all of Google, not individually per app.

Plugins: Just drop the external sources that change their APIs.

Accounts: Accounts are managed by Google Accounts, not by individual apps.

iGoogle is mainly a client-side script that displays small amounts of data. Still think there is not much "maintaining" to do.

It is client side in the www.google.com domain. Meaning it can potentially attack other services in that domain like, oh, most other Google services. You'd want more than just a lone intern watching over it in his spare time.

Reply on news.ycombinator.com