Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: FCC Complaint URL (Score 1) 248

by scribble73 (#46845783) Attached to: New White House Petition For Net Neutrality
If you want to support Net Neutrality, then you have to post a comment on the FCC website. The FCC has to formally consider every single comment it receives on its website, through its comment/complaint process.

You can say anything you want, but constructive, helpful comments are more important than personal comments.

The FCC doesn't make it easy to post your comment on this particular proceeding. Here is the link you need to follow. In the 'proceeding' text field at the top of the form, type the number '14-28.'

http://apps.fcc.gov/ecfs/uploa...

Comment: Not useful. (Score 1) 311

by scribble73 (#46817341) Attached to: In the US, Rich Now Work Longer Hours Than the Poor
Last week, CNN found a new issue they hoped would distract from criticism of their relentless Maylasian air crash coverage. CNN newsreaders took to the air to ask, "... what could the KKK do, to improve its approval rating? They actually had guests who discussed the question with straight faces.

This pretended study is another one of those strange, invented approaches on an ongoing tragic issue... an angle that sounds intelligent on its face until you think about it for just two or three seconds. Then you realize how perfectly insulting this phoney approach to a real issue really is.

Go ahead -- tell the maids down at your local Best Western Motel that rich people work more than they do. Then drive a few blocks down to your nearest Home Depot parking lot. Tell those unemployed men waiting at the nearest corner hoping to find a casual, sub-minimum wage job from you, that they are on "recreational" time.

The editors of the Economist magazine ought to be horsewhipped for printing this story. SlashDot ought to be purple with shame for reprinting it. Seriously. I don't come here to read quasi-Libertarian krap like this.

Comment: Were are the temp employee questions? (Score 1) 177

by scribble73 (#46186771) Attached to: At my current workplace, I've outlasted ...

This is not a well-constructed quiz. The problem, is that the poll doesn't recognize temporary employees.

Normally, I wouldn't bother commenting. It's a quiz, and who cares about temp employees, anyway?

... but this is an example of a significant blindspot for Slashdot employees. Apparently, you guys don't realize that companies like Google, Apple, Cisco, Facebook, Microsoft, Yahoo, Oracle (and others) hire a significant portion of temp employees to do their real day to day work. They hire only the few people they need, to supervise the temps they retain. Temporary employees have larger, and very different problems than this quiz implies.

Is this important to SlashDot? I'd say so. I think you should have a feature every day, that reports on something involving temporary workers. There are a Hell of a lot of us.

Comment: Fix Everything (Score 1) 1191

by scribble73 (#45008519) Attached to: Come Try Out Slashdot's New Design (In Beta)
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.

Comment: I am skeptical about this article (Score 1) 139

by scribble73 (#44576665) Attached to: Cisco Slashes 4,000 Jobs
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.

Comment: Not well put, but you make some good points ... (Score 5, Insightful) 395

by scribble73 (#44143517) Attached to: How Silicon Valley's Tech Reign Will End
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

Comment: Re:Replace MSWord (Score 1) 226

by scribble73 (#44052189) Attached to: Google's Crazy Lack of Focus: Is It Really Serious About Enterprise?
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

Comment: I hate this policy (Score 3, Insightful) 88

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

Comment: Perspective, perspective (Score 1) 631

by scribble73 (#43402165) Attached to: No Such Thing As a Tax-Free Lunch At Google?
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

Comment: Re:How Documentation Really Happens (Score 1) 418

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.

Comment: How Documentation Really Happens (Score 1) 418

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.

Comment: Re:Yo, Jimmy, I've got an idea: (Score 1) 608

by scribble73 (#34576422) Attached to: Should Wikipedia Just Accept Ads Already?
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

Line Printer paper is strongest at the perforations.

Working...