MISTAKE NUMBER ONE to never make:

After writing about 90% of a thoughtful, detailed comment, your f**king comment software suddenly blinked my comment out of existence.

This is the number one reason why a commenter leaves a website. Number two: Oppressive over moderation. Number three: spam negligence.

I haven't got time now, so I'll get to the point: Don't change the font. White space is your enemy on slashdot. Bring back some curvy corners. GET RID of that awful floating menu bar. It feels like I have an eyelash in my eye. Respect your commenters: No one comes here for your home page. We come here to talk with each other about what we find on your home page. and FIX YOUR COMMENT SOFTWARE.

This is a fascinating thread.

Cisco lost its vision as a company at least a decade ago. They are making most of the mistakes made by large companies with no business vision beyond meeting their financial projections. As a consequence, Cisco is slowly shrinking -- think General Motors in 2004 or so. In a few years, a larger company (maybe Chinese or Indian) will buy what's left of them.

I once met with a group of about a dozen Engineers -- all of them were excellent professional people. Their group had lost three supervisors in fifteen months and been transferred through two departments. Every one of them was concerned about their evaluation status -- they had had no real chance to contribute to Cisco in about eighteen months, and it did not have anything to do with their ability to perform. Each of these people knew he/she was going to hit the bottom of any layoff list that Cisco HR kept, because they had simply not been given anything productive to do for two years. This is what happens to good professional employees when a large company loses its vision, and it doesn't happen to just one small group: It will usually happen to hundreds of mismanaged professional and support groups at a time, all through a large company.

I am NOT convinced that this article is accurate. I don't think that Cisco has 80,000 domestic employees any more. Three years ago, they had two thirds of that number, and there have been layoffs since. Cisco also employs several times as many employees in India and China, as they employ here. Does this announced layoff also affect their overseas staff?

Cisco also relies on thousands of temporary employees to manage their workload. Are they going to send all their temporary employees home, before laying off, well; whomever they intend to layoff? If so, their layoff will be well over 10% of their workforce; not 5% -- and these percentages double if their domestic employee staff numbers only 50,000 or so.

The point isn't that we don't figure these things out for ourselves.

The point is; that employers and banks aren't giving us a choice.

tt77

There isn't a single convicted Felon in prison somewhere, who doesn't agree with you.

tt77

The points the author notices are effects; not causes.

In the 1950s, San Jose and its suburbs adopted an urban growth strategy that was essentially no planning strategy at all. They minimized zoning and urban planning, assuming that giving developers the freedom to develop land without much oversight would somehow produce a quality urban environment as a side-effect.

So San Jose, Santa Clara, Sunnyvale, Campbell, Mountain View and Cupertino spread out because developers opted to build where land was cheap. However, city streets were not extended in a sensible way. To run personal errands on Saturday, we had to start driving five miles (and through a dozen stoplights) just to find a grocery store. Three or four other errands could require fifteen to twenty miles. Add traffic and stoplights, and it could take you five hours or more, to run just three local errands.

In addition, cities here allowed commercial property to mix a little too closely with residential property. This raised crime rates, lowered property values, and made everything ugly. No one planned for parks or shopping centers or other public amenities. When shopping centers were finally built, traffic patterns were ghastly. When planners were forced to route freeways through the area; they were routed where the land was cheap; not where they were really needed -- first they cut neighborhoods in half, and then in quarters. Parks were placed, twenty years late, where more land was cheap, or where well-to-do neighborhoods were still located.

All this turned the valley into a happy little piece of Houston, Texas, only with worse freeways.

The good things about Silicon Valley arose from areas that were planned: Stanford. Large Aerospace companies along Bayshore freeway. Aerospace died, but by then, silicon had taken the place of airplanes. Then silicon died. Today, we run on software and business momentum from the old days, but the momentum is formidable.

... the Valley is no longer egalitarian, the way it was in the 50s and 60s. We have a greater disparity between the rich and the poor than almost any city along the Pacific Coast, and the rich here still love Libertarian chaos... so, real estate prices are too high. Rents are too high. No parks. poor schools. Easily 7000 homeless just in San Jose. Tens of thousands of homes foreclosed over the last seven years. And even with Google Maps; local business are infernally hard to find and ugly when you get there.

As bad as all this is, it won't ultimately kill the valley. I think lack of professional creativity and opportunity will finally kill us. Large companies here never did value what the Harvard Business School calls 'disruptive technology.' They do not hire creative problem solvers. Business startup costs used to be low: Today, they are through the roof, and getting higher. Venture Capital has ruled the roost since 1997 or so, they are getting stronger, and they do not value original ideas.

Major companies here are all slowly dying (like they always have -- remember Fairchild Instruments, DEC and Atari?) -- the difference is; that it is much, much harder to start a new company here than it used to be -- and new companies are where the big companies come from when the old companies finally die.

tt77

Even successful services at Google can die. Looking at their history, Google kills about three out of five successful services.

Google services usually experience an influx of popularity and income when first released. Over time, they gradually return a smaller fraction of their expenses. When a mature service begins to lose money, Management decides whether to update itor to kill it. Maybe a third of the time, management decides to kill it. It only takes a few decision cycles for an individual service and its number comes up.

Projects supporting services are kept loosely coupled. This works in Google's favor. This minimizes the effect that killing a service has on other services. When a service dies, most members are simply laid off -- even the good ones. The rest of the workforce seldom finds out. Over time, it is risky to work at Google.

Google is full of services that are on their way to dying, including Google Sites and Google Docs. Employees use these services internally, but they are woefully behind their competition and are becoming a productivity bottleneck. I believe they are close to being re-evaluated. With competing open source services like WordPress and LibreOffice, it might be easy for Google to just open source the code and reassign (or lay off) project employees.

Microsoft is also neglecting MS Word for similar reasons. MS Word is a bloated, mature app that doesn't make much money any more. It has collected lots of bugs that are expensive to fix. There isn't enough money to fix them. The new Ribbon UI has failed in the marketplace. It is bundled with an Office Suite that has its own problems. Some open source word processors are now better in many ways. Microsoft could have a Google surprise in store for us.

tt77

I hate this policy, of selling our public bandwidth to private corporations. I just hate it.

Airwaves are public. The Government should not be selling property that belongs to all of us. Leasing or licensing bandwidth for some specific period of time is one thing, but transferring ownership is another. We should not "privatize" this.

I am dismayed to see so many politicians and technical types just accepting actions like this, without any policy discussions taking place -- beyond closed-door meetings at the FCC, which are not shared with the public.

tt77

This whole thread is quibbling about taxing pennies on employee lunches, when Google works overtime to avoid paying taxes on billions of dollars on its profits. I'm surprised that not one person in this thread has noticed the disparity. Did you notice?

http://www.huffingtonpost.com/2012/09/20/microsoft-taxes-profits-offshore_n_1901398.html
http://www.bloomberg.com/news/2011-10-13/irs-auditing-how-google-shifted-profits-offshore-to-avoid-taxes.html
http://www.bloomberg.com/news/2012-12-10/google-revenues-sheltered-in-no-tax-bermuda-soar-to-10-billion.html

Really. Buy some perspective.

sc

NOTE: I have no friggin' idea why; but the /. editor stripped all my paragraph tags out of my original post. Here it is again, but in a much more readable form. I apologize.

Technical documentation is bad because very few software projects identify documentation as a task they need to accomplish, in their Project Plan. Marketing does very little in their PRD. Engineering does next-to-nothing in their FS.

When it finally does occur to the Project Manager that customers will need something, the engineers on the team think that it's a piece of cake. They already have an Engineering Specification; surely customer documentation can be easily extracted from the Project Spec -- the technical team can just 'wing' it the last month of the project, and everything will be fine.

... so the project deadline approaches. The spec has become grossly incomplete and out of date. The Engineering team has no idea who the buyers will be. Engineers generally lack the writing skills they need, to prepare long, detailed documents. They haven't defined anything; outlined anything; identified questions that users would ask. The Marketing team (involved by this time) doesn't really know how to write, either -- but they think they do; and they also think that usual Marketing bluster will get them by.

So things go wrong. Engineering and Marketing get in a fight, which wastes time. Sensing doom, the first few Marketing people leave the project. As a compromise, the Project Manager forces the Lead Engineer to assign someone on his team to document the product. The Lead Engineer assigns the most junior Engineers on the team. They fail to produce anything usable, because the Lead Engineer has also placed documentation last on their list of project priorities.

By this time, the Project Manager realizes he/she has a serious problem. To calm everybody down, he/she hires a technical writer at the last minute. He treats the writer pretty much as a secretary: No technical briefing. Not integrated onto the team. The Engineering Lead has placed the doc files under Engineering version control, where every misplaced semicolon in a doc file unnecessarily breaks the nightly build.

The Project Manager still expects the documentation to be finished on the same minute of the same hour of the same day that the product is released as an alpha/beta/PR -- sometimes a few weeks early, so it can theoretically go through QA first.

Through all this, no one (except the writer) has thought to ask what the customers (including the technical customers) actually need to know.

It always ends badly for everybody -- because the Project Manager and his initial team ignored their documentation requirement because it didn't look like it would cost enough to require their management time.

While Microsoft deserves some criticism; other large companies are worse (and more cynical about it). ... just make a list of the largest companies in Silicon Valley. None of them have instituted business processes that have a prayer of producing the tech documentation anyone can easily use. When they finally produce usable docs for a product, it's on the third or fourth version, several YEARS after the original deadline.

Open Source projects generally handle Documentation worse than this.

Technical documentation is bad because very few software projects identify documentation as a task they need to accomplish, in their Project Plan. Marketing does very little in their PRD. Engineering does next-to-nothing in their FS. When it finally does occur to the Project Manager that customers will need something, the engineers on the team think that it's a piece of cake. They already have an Engineering Specification; surely customer documentation can be easily extracted from the Project Spec -- the technical team can just 'wing' it the last month of the project, and everything will be fine. ... so the project deadline approaches. The spec has become grossly incomplete and out of date. The Engineering team has no idea who the buyers will be. Engineers generally lack the writing skills they need, to prepare long, detailed documents. They haven't defined anything; outlined anything; identified questions that users would ask. The Marketing team (involved by this time) doesn't really know how to write, either -- but they think they do; and they also think that usual Marketing bluster will get them by. So things go wrong. Engineering and Marketing get in a fight, which wastes time. Sensing doom, the first few Marketing people leave the project. As a compromise, the Project Manager forces the Lead Engineer to assign someone on his team to document the product. The Lead Engineer assigns the most junior Engineers on the team. They fail to produce anything usable, because the Lead Engineer has also placed documentation last on their list of project priorities. By this time, the Project Manager realizes he/she has a serious problem. To calm everybody down, he/she hires a technical writer at the last minute. He treats the writer pretty much as a secretary: No technical briefing. Not integrated onto the team. The Engineering Lead has placed the doc files under Engineering version control, where every misplaced semicolon in a doc file unnecessarily breaks the nightly build. The Project Manager still expects the documentation to be finished on the same minute of the same hour of the same day that the product is released as an alpha/beta/PR -- sometimes a few weeks early, so it can theoretically go through QA first. Through all this, no one (except the writer) has thought to ask what the customers (including the technical customers) actually need to know. It always ends badly for everybody -- because the Project Manager and his initial team ignored their documentation requirement because it didn't look like it would cost enough to require their management time. While Microsoft deserves some criticism; other large companies are worse (and more cynical about it). ... just make a list of the largest companies in Silicon Valley. None of them have instituted business processes that have a prayer of producing the tech documentation anyone can easily use. When they finally produce usable docs for a product, it's on the third or fourth version, several YEARS after the original deadline. Open Source projects generally handle Documentation worse than this.

Most of us are familiar with the for-profit Corporation legal model. When we say, "run like a business," this is usually what we are referencing. The "not-for-profit" corporate model also works, and might work in this case, too. NPR is probably not an ideal example, but the St. Petersburg Times probably is a better example. They run a daily newspaper that runs on advertising but their journalists are isolated from their executives and advertisers, and the 'not-for-profit' charter protects them from the takeovers that have destroyed so many other daily newspaper compeditors over the last twenty years. I think Wikipedia could probably adapt that 'not-for-profit' model successfully, and do away with their hot and cold running begathon forever. sc

I appreciate the book reviews posted here. This thread obviously has a problem with this review (good as it is) because they can't figure out what the product does. Moodle isn't alone. Open source projects often fail because they don't explain what their products do. Definitions seem obvious to the skilled, idealistic and insightful engineers who create OS software, but definitions and overviews are NOT obvious to anyone else. Further; The OS engineers who write docs often lack the skills they need to write documentation that helps their users. When their docs fail, their product fails -- and they never quite know why. So Moodle (whatever it is) needs to be defined; so I can no longer put "whatever it is" in parentheses when I refer to it. I need to see Moodle defined in terms of the specific problems it solves for me. Briefly tell me how Moodle works -- then break out a list of functions it performs, and tell me what each function does. Be specific. Include brief examples. Once you give me a practical sense for what your product produces for me, I'll be ready to read about installation, configuration, customization, admin tasks, content creation and session-building for students. ... but be specific -- appending an acronym to a product name is not a definition. sc