Author Topic: Why projects take longer than you think  (Read 4148 times)

0 Members and 1 Guest are viewing this topic.

Offline Vtile

  • Frequent Contributor
  • **
  • Posts: 993
  • Country: fi
  • Ingineer
Re: Why projects take longer than you think
« Reply #25 on: April 16, 2019, 11:29:21 pm »
Half a day wasted because of an unforeseen technical problem outside my control, and the half hour I'd saved on building the board was gone many times over.

This is what ends up killing otherwise well thought out estimates - the "unknown unknowns".   Really the only things we can estimate reliably is work that we have done before, down to the last detail - and even that can go wrong!
New Firmware from HW supplier.
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 2875
  • Country: us
Re: Why projects take longer than you think
« Reply #26 on: April 17, 2019, 12:16:29 am »
The problem that typically cause overrun is "thought/planning process".

Most tend to think how things should go, then add up how long.  How it should go isn't often the way things works.  Unexpected turns in the corner, things doesn't react as expected...

Have a pessimist plan and manage the project progress, have an optimist manage the pessimist and the team.
 

Offline floobydust

  • Super Contributor
  • ***
  • Posts: 3593
  • Country: ca
Re: Why projects take longer than you think
« Reply #27 on: April 17, 2019, 01:27:39 am »
When did the project schedule and deadlines become so absolute, hard-ass?
Estimates, ball park and jitter used to be acceptable. You could be behind or ahead a month, no biggie.

Now, I find employers bring out the Firing Squad if things are "late".
It's very bad for stressing young engineers that buy into it and work super hard to catch up to the dictated deadline. I see it burn some of them out. Very destructive, Mr. Musk.
 

Offline Tomorokoshi

  • Frequent Contributor
  • **
  • Posts: 885
  • Country: us
Re: Why projects take longer than you think
« Reply #28 on: April 17, 2019, 01:51:31 am »
When did the project schedule and deadlines become so absolute, hard-ass?

...

My sense is that shift occurs in any industry when it transitions from "high-tech" to "commodity". For instance, in successive waves appliances, radio, television, video recorders, computers, and now internet applications are making that shift. During the transition phase, the goal of being a market leader with some feature drives the whole "time to market" push, followed by cost-reduction.

We happen to discuss it now because this forum is centered on the electronics equipment and software industry.

It's just that now there really isn't a "high-tech" class of products anymore - everything is a commodity. An iPhone, which would have been mind-blowingly high-tech in the '80's, so much so that such things were almost completely missed by science fiction, is a commodity.
 

Offline SilverSolder

  • Super Contributor
  • ***
  • Posts: 2522
  • Country: 00
Re: Why projects take longer than you think
« Reply #29 on: April 17, 2019, 11:13:35 am »

It's just that now there really isn't a "high-tech" class of products anymore - everything is a commodity.

That's an interesting observation.  We have gotten used to new tech very quickly and take it 100% for granted.  Probably because hardly anyone feels the innovations have threatened their livelihoods...   Will this carry on with the next wave of "high tech", when it arrives (AI)?
 

Online TerraHertz

  • Super Contributor
  • ***
  • Posts: 3712
  • Country: au
  • Why shouldn't we question everything?
    • It's not really a Blog
Re: Why projects take longer than you think
« Reply #30 on: April 17, 2019, 01:42:55 pm »
Heh. I knew this. It's one of the reasons I retired early.

Because even _routine_ well understood development projects suffer from this effect, so tend to blow out and become destroyers of enjoyment of life.
But I don't want to develop ulcers over boring stuff like I used to do for a living. I want to stress out over projects I think are worthwhile. To be worthwhile they must be both cool, and things that have never been done before.

Unfortunately with _those_ types of things, the unforseen problems really blow out. Especially if a project is complex, with many interdependent strands, all independently tending to get stuck and hold up everything else. Such things cannot be pursued in a commercial context, because they are just impossible under any kind of realistic funding model. Not even crowd funding can work, because failure and absurd delay is the norm.

This is why I adopt the 'fanatical hermit scraping by in a cave' development model. More or less.
Collecting old scopes, logic analyzers, and unfinished projects. http://everist.org
 

Offline floobydust

  • Super Contributor
  • ***
  • Posts: 3593
  • Country: ca
Re: Why projects take longer than you think
« Reply #31 on: April 17, 2019, 05:48:31 pm »
Engineering is always the bottle-neck doing product development. Up against impatient executives, managers, investors - it's been getting worse.
So much so that safety lapses are the only beacon saying "stop pushing and rushing us".
Not to self-blame our (engineer) estimating skills at all.

A lot of engineers are realizing "it's no fun anymore" because they started off doing fun hobby projects and then onto the corporate treadmill, which is all about doing things "as quickly as possible".
Creativity is gone, there is no reward for working harder or faster, and you get abused by being chastised for "late" efforts.
The trolls in Accounting can take weeks to issue a P.O. to Digi-key, but engineering can't waste a day.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 7413
  • Country: us
Re: Why projects take longer than you think
« Reply #32 on: April 17, 2019, 06:20:15 pm »
I spent my entire career in construction and there was a lot of estimating and project management (software or not).  Whenever I had to estimate something, I created as many line items as I could think of and estimated them separately.  Then I buried 20% inside every line item.  It didn't really show up as each number was still 'reasonable'.

Then the magic!  I would add a 20% contingency line item entry to the subtotal knowing full well that finance was going to remove it.  I never got that contingency passed the bean counters!  They felt good about constraining the budget and I still had contingency in every task item.

As this was all 'internal' money, it was really just a game.  Everybody had to play and I didn't want to lose.  The company never did post-mortems anyway so once a job was done it was time to move on.  Unless the project doubled in cost, nobody really cared.
 

Offline floobydust

  • Super Contributor
  • ***
  • Posts: 3593
  • Country: ca
Re: Why projects take longer than you think
« Reply #33 on: April 17, 2019, 06:37:19 pm »
Adding fat to project time estimates is really dangerous. It's not "self-correcting" doing this because you are not fixing the delays and inefficiencies within the corporation which will remain or worsen.

People can also think the time estimates are "negotiable" as if we have some strange command over space-time.

When I add a little fat to time estimates, people squawk over how long it will take and then issue an ultimatum:
Instead of hiring more people because the project is resource-limited, they just create a fake schedule to please the executives.

The engineers know the project schedule is all a fantasy, nobody listened to them, but they are then flogged when things "fall behind".
I've seen it so many times, products that are years behind schedule with engineering looking like a inept business unit.
It's actually a failure of the project management basics - listen and honour the engineer's time estimates, and add staff if required.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 7413
  • Country: us
Re: Why projects take longer than you think
« Reply #34 on: April 17, 2019, 07:14:02 pm »
The reason for breaking a project down into as many line items as possible is to get as close to understanding the real 'scope of work' as possible.  There are so many projects where the total scope is unknown that it is just better to try to get a handle on it right up front.  In my business it was things like asbestos abatement, code changes since the original construction, handicap access, and on and on.  Not necessarily obvious at first glance.
 Break it all down, understand the true scope of work.

The reason for padding the estimate of each line item is that it will all be contracted.  I couldn't control the incoming quotes, all I could do was try to use the cost of previous work to forecast this project.  Sometimes we would go out to contractors and get bids for various trades (general construction, electrical, HVAC, painting, engineering, etc) but not always.  Sometimes it was design/build and most sometimes we would just wing it.

In a perfect world, there would be plans and specs on the work before it went out to bid.  Alas, the world isn't perfect and we didn't have time to serialize the project.  It's OK to wing it!  Just don't crash and burn.
 

Offline schmitt trigger

  • Super Contributor
  • ***
  • Posts: 1740
  • Country: mx
Re: Why projects take longer than you think
« Reply #35 on: April 17, 2019, 08:00:00 pm »
Engineering is always the bottle-neck doing product development. Up against impatient executives, managers, investors - it's been getting worse.

Creativity is gone, there is no reward for working harder or faster, and you get abused by being chastised for "late" efforts.

The trolls in Accounting can take weeks to issue a P.O. to Digi-key, but engineering can't waste a day.

In your first sentence, you forgot to include marketing. Their favorite spiel: Our main competitor ALREADY HAS gone into production with their product, and they will steal ALL of our customers.

In your second sentence, my experience is: if somehow you were able to perform a miracle, upper management will expect that you perform similar feats routinely. That will eventually burn you out.

In your third sentence, it appears that you and I work for the same company!! What I will do, if I really require something urgently, I'll charge it to my personal CC, and then getting reimbursed from the petty cash account.
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 3631
  • Country: us
Re: Why projects take longer than you think
« Reply #36 on: April 17, 2019, 08:34:09 pm »
I find the general mechanism in the OP credible, and it simplifies the problem enough to study the other end of the problem.  Now that you know some projects are going to blow up, and have a statistical estimate for it, you can evaluate risk in proposals better.  You can't just bid the worst case, you will never get work.  You can't bid the best case, you will always lose money.  Now you can get a justifiable guess for the point at which you will on average come out ahead.

Which only leaves one problem.  There will almost always be someone more desperate or ignorant than you who will bid below the break even line.  Leading to the management despair and pressure described in many of the posts here. 
 

Offline schmitt trigger

  • Super Contributor
  • ***
  • Posts: 1740
  • Country: mx
Re: Why projects take longer than you think
« Reply #37 on: April 17, 2019, 08:51:16 pm »
Catalina;
It can actually become worse....if the design is for a cost-sensitive, high volume product. The design engineers, faced with relentless cost and time pressures will take shortcuts, which will translate into daily pain for the manufacturing facility.
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 3631
  • Country: us
Re: Why projects take longer than you think
« Reply #38 on: April 17, 2019, 10:27:06 pm »
Catalina;
It can actually become worse....if the design is for a cost-sensitive, high volume product. The design engineers, faced with relentless cost and time pressures will take shortcuts, which will translate into daily pain for the manufacturing facility.

That MAY be just a variant of what I said.  The owners of the manufacturing facility could in principal know that those short cuts will lead to pain, in fact that they will lead to financial losses on the project unless they get lucky.  But the alternative is to skip the shortcuts, develop a solid product, and get none of the market.  It is a choice between the possibility of making money (if you are lucky) and the assurance of losing money if you do it right.  Both choices suck, and the engineers and manufacturing guys don't like the better one.
 

Offline basinstreetdesign

  • Frequent Contributor
  • **
  • Posts: 364
  • Country: ca
Re: Why projects take longer than you think
« Reply #39 on: April 18, 2019, 01:01:19 am »
On the subject of generating elapsed-time effort estimates.  No other part of the project preparation or execution process is fraught with as much self-deception,  inaccuracy and even blatant horsehockey as this part is.

I am sure that most, if not all engineers, have at some time been suddenly asked by a superior to make a prediction of performance in one circumstance or other.  Many times when one is put into such a position the temptation to give a very pleasing response cannot be wholly avoided.  One wants to say that it can be done in two weeks.  Only later when it actually turns out to be two months is the truth revealed.  This occurs because at the moment we are asked, an astonishing thing happens: we become super-engineers.

We start to think that we can do the hardware design almost as fast as it takes to scribble it down on paper or get it captured to CAD...
We think that any meeting will take only 5-10 minutes because nobody will argue...
We think that debugging will be short because nothing will go wrong...
Design reviews will not turn up any unexpected problems...
Software will work first time as hoped...
We will be at best efficiency for the duration of the project...
Nobody will get sick..
We will not wake up with a hangover from the bad weekend before...

Why does this happen?

It happens for many reasons some of which are given below but most importantly, it happens because we choose to allow it to happen.  If we can delude ourselves into thinking that nothing bad will happen as a result then we may not correct ourselves as we should.

It happens because at the time we are asked to quote on the task, we are faced with the unpleasant possibility that our audience (the client or supervisor) may not like what he hears.  We don't want to face the reaction that may be forthcoming if s/he doesn't like it.  So we tend to bend our belief in ourselves in order to deliver a more pleasing (if completely unrealistic) picture.

I have seen people actually break out in a sweat and stammer at this point.

Has anybody used the Delphi technique or the "Wide-Band" Delphi" technique to job estimation.  I hear it is supposed to be somewhat accurate.  At least more accurate than just asking the doers what they think because it forces those whose estimate disagree with the groups average estimate to justify their answers.  This is how it is described (my words):

The Delphi Technique:
The task or task list is then shopped around to each member of the group for their opinion on the work effort required for each task.  They each should make their best estimation of the time needed, in days/weeks, not hours, for each task and report it to s/he who is responsible for collecting them.  The results are tabulated and labelled as the “First Approximation” or some such.  As with most things these results will show most guesses for each task grouped around a mean with a few which fall significantly away from the mean value.  Those group members who submitted the latter sort are asked, in the presence of the entire group, to explain their guess.  After listening to all of the arguments each group member is asked to guess again on the entire list of tasks.  This new set of values is tabulated.  Lo! And Behold!  The new “Second Approximation” values fall in more closely collected sets around new mean values with fewer anomalous values.  A second discussion is held.  If these new values still do produce anomalous values then a third set of guesses may be asked for.  This is usually as far as the technique will be useful (and as far as the patience of the group will allow).

The "Wide-Band" Delphi" technique is the Delphi Tech combined with some arithmetic based on the Three-Point (Optimistic, Pessimistic, Most Likely).
STAND BACK!  I'm going to try SCIENCE!
 

Offline electromotive

  • Regular Contributor
  • *
  • Posts: 87
  • Country: us
Re: Why projects take longer than you think
« Reply #40 on: April 18, 2019, 04:33:27 am »
The illustration above about using a personal credit card to expedite a Digi-Key order hit way too close to home, and it seems relatively common. To put some numbers on it, let's say an engineer with a burdened cost of $100,000 per year works on a project with an expected budget of $1,000,000. An order of $100 is necessary to move a key part of the design forward.

So suppose it's Wednesday the 1st at 5:30 PM and to expedite an issue you want to make a Next Day Digi-Key order for delivery on Thursday the 2nd. The boss left at 5:00 PM, and he as the one credit card for the group. So it's entered by 6:00 PM but it won't get processed anyway until the next day because Purchasing leaves at 4:00 PM. But then it doesn't get processed because the purchaser took Friday the 3rd off, so now it doesn't get ordered until Monday the 6th, but they did 3-day delivery instead of next day, making it arrive on Friday the 10th.

Did this save any money anywhere in the process? What is the value of expediting blocking processes like that? Would a $1000 credit card per engineer be worth while? The liability on a $1000 credit card is... $1000. With an engineer who is answerable to what is purchased, so ordering cookies or golf balls probably won't happen. What is the liability of a week of delay? $10,000?

Look at all the relative orders of magnitude here. The little tasks get in the way large responsibilities, like priority inversion in some embedded system.


Imagine this.... (I lived it)

The year is 2013. I'm the lead industrial engineer for the largest rift and quartered hardwood sawmill in the United States. We're in the middle of trying to turn the mill around after some crazy mismanagement by previous owners -- the bank had taken over the mill, and an investment firm had since bought it from the bank. We needed production of at least 61,000 BFD per day. The mill was at 14,000 - 18,000 BFD when I was brought in to turn it around.

I started going through all of the operations to see what was going on. An entire planing mill was down, but why? They were out of $0.11 bulbs for the Optical Comparator used to sharpen the planer knives and nobody cared enough to let someone higher up know. An 11 cent bulb was costing $120k / day in lost production. I ordered a box of 100, stocked 10 in the supply cabinet by the comparator, and put the remaining 90 in the designated area in maintenance storage. Total cost: $11.70 delivered.

Next, the sawmill was having trouble keeping blades sharp. It was basically a giant bandsaw mill -- the blades were about 30 feet in diameter, about 1/8" thick, and 8-10" across. What was the problem? Apparently some of the control boards for the automatic sharpener had let out their magic pixies and so the machine had to be manually operated because there was no limit function or reset working. The part was obsolete, but I managed to find one and had it overnighted. Total cost: $271.86 shipped.

Meanwhile, I had the dead board sent to my office. I rebuilt it, made a new version in Eagle, and was ready to order new PCBs to have on stand-by.

So, for $283.56 I brought mill production from 15,000 BFD to 45,000 BFD. In other words, that investment made back $90,000 in lost productivity.... PER DAY.

I put together a massive SQL system to make it easier to run reports and track production, and had brought production back to 58,000 BFD when they sacked me for "spending too much money". I had spent just over $800 to get to this point. That $800 total earned back $129,000 in losses per day. But hey, I was spending too much money. They're virtually bankrupt now. Production is only a few thousand BFD a month now.
 
The following users thanked this post: MagicSmoker

Offline floobydust

  • Super Contributor
  • ***
  • Posts: 3593
  • Country: ca
Re: Why projects take longer than you think
« Reply #41 on: April 18, 2019, 06:14:52 am »
Some manufacturing workplaces don't want everything working.
They like a leisurely pace and I've seen crews sabotage equipment so they get to do very little work on their shift, with the line down. Or sabotage anyone's work to fix things.

Or they are so cheap and the rule is to spend absolutely nothing. Not a penny. They flip out if you splurge and buy paper towels or a screwdriver. $800 is outrageous  ;)

 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Why projects take longer than you think
« Reply #42 on: April 18, 2019, 08:32:21 am »
...nobody cared enough...

There's the problem, right there in a nutshell.

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Why projects take longer than you think
« Reply #43 on: April 18, 2019, 10:20:29 am »
The problem that typically cause overrun is "thought/planning process".

Most tend to think how things should go, then add up how long.  How it should go isn't often the way things works.  Unexpected turns in the corner, things doesn't react as expected...

Have a pessimist plan and manage the project progress, have an optimist manage the pessimist and the team.

yup  :D
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15575
  • Country: gb
Re: Why projects take longer than you think
« Reply #44 on: April 18, 2019, 10:23:11 am »
I have a solution for this whole thing that works for me:

I charge 4x my initial (internal) estimate and give 10% back if I complete the work early. Surprisingly people piss their pants excitedly about being ripped off in this way, especially the second and third times  :-DD
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Why projects take longer than you think
« Reply #45 on: April 18, 2019, 10:29:44 am »
When my team planned the Sonoko project, we were not considering a lot of things do not react as expected, for example a big problem with the Linux kernel, and ZERO collaboration from guys on the internet.

the mistake was: to assume that someone was still interested in legacy ppc405 chip

so we are still all alone with a lot of unsolved problems  :-//
« Last Edit: April 18, 2019, 10:32:48 am by legacy »
 

Online bd139

  • Super Contributor
  • ***
  • Posts: 15575
  • Country: gb
Re: Why projects take longer than you think
« Reply #46 on: April 18, 2019, 10:34:56 am »
The trick is to go with all the popular shit even if you hate it because you can usually google your way out of a hole faster than having to shape a new wheel.
 

Offline NANDBlog

  • Super Contributor
  • ***
  • Posts: 4661
  • Country: nl
  • Current job: ATEX certified product design
Re: Why projects take longer than you think
« Reply #47 on: April 18, 2019, 10:49:13 am »
Very interesting read. I fully appreciate the investigation.
I am actually wondering how this applies to HW dev. Because I have to make estimations about my time, and sometimes I really have hard time explaining what is going on. Take for example, they want a widget for x amount of money, and they want it in 6 months. It would take something like a few days to actually make something that would do what the widget does, and then some time for the others to code something, however a bunch of things happen in real life.
A) I cannot spend 100% of my time on the project cause other things are as well important.
B) We need a second and a third prototype, because one little thing is broken
C) Because there is a price target, I have to have several designs made, organize meetings with suppliers, manufacturers, gather information about prices, availability, compare them, make several effort estimates. Even organizing the meetings is several weeks.
D) You need a custom thingamabob for it, where the tooling needs several months to be made.
 

Offline schmitt trigger

  • Super Contributor
  • ***
  • Posts: 1740
  • Country: mx
Re: Why projects take longer than you think
« Reply #48 on: April 18, 2019, 02:47:13 pm »

C) Because there is a price target, I have to have several designs made, organize meetings with suppliers, manufacturers, gather information about prices, availability, compare them, make several effort estimates. Even organizing the meetings is several weeks.
D) You need a custom thingamabob for it, where the tooling needs several months to be made.

For these pair of items, it usually means having things made in China. This is where The Troubles begin:

From the "lost-in-the-translation" discussions, to the crazy meeting hours (in Chinglish, of course), to their holidays not aligning with ours, to the way the see things vs. your point of view...... and of course, receiving the first production batch which will be found to have a "minor" issue that will render them unusable, more crazy meetings attempting to figure out the issue, agreeing on sorting  criteria, figuring out a correct rework procedure, dealing with the inevitable scrap, paying overtime fees to meet deadlines.... and finally having to air-freight the reworked material.

In the end, the cost will be several times the original quote.
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 2875
  • Country: us
Re: Why projects take longer than you think
« Reply #49 on: April 18, 2019, 06:30:53 pm »
The illustration above about using a personal credit card to expedite a Digi-Key order hit way too close to home, and it seems relatively common. To put some numbers on it, let's say an engineer with a burdened cost of $100,000 per year works on a project with an expected budget of $1,000,000. An order of $100 is necessary to move a key part of the design forward.

So suppose it's Wednesday the 1st at 5:30 PM and to expedite an issue you want to make a Next Day Digi-Key order for delivery on Thursday the 2nd. The boss left at 5:00 PM, and he as the one credit card for the group. So it's entered by 6:00 PM but it won't get processed anyway until the next day because Purchasing leaves at 4:00 PM. But then it doesn't get processed because the purchaser took Friday the 3rd off, so now it doesn't get ordered until Monday the 6th, but they did 3-day delivery instead of next day, making it arrive on Friday the 10th.

Did this save any money anywhere in the process? What is the value of expediting blocking processes like that? Would a $1000 credit card per engineer be worth while? The liability on a $1000 credit card is... $1000. With an engineer who is answerable to what is purchased, so ordering cookies or golf balls probably won't happen. What is the liability of a week of delay? $10,000?

Look at all the relative orders of magnitude here. The little tasks get in the way large responsibilities, like priority inversion in some embedded system.


Imagine this.... (I lived it)

The year is 2013. I'm the lead industrial engineer for the largest rift and quartered hardwood sawmill in the United States. We're in the middle of trying to turn the mill around after some crazy mismanagement by previous owners -- the bank had taken over the mill, and an investment firm had since bought it from the bank. We needed production of at least 61,000 BFD per day. The mill was at 14,000 - 18,000 BFD when I was brought in to turn it around.

I started going through all of the operations to see what was going on. An entire planing mill was down, but why? They were out of $0.11 bulbs for the Optical Comparator used to sharpen the planer knives and nobody cared enough to let someone higher up know. An 11 cent bulb was costing $120k / day in lost production. I ordered a box of 100, stocked 10 in the supply cabinet by the comparator, and put the remaining 90 in the designated area in maintenance storage. Total cost: $11.70 delivered.

Next, the sawmill was having trouble keeping blades sharp. It was basically a giant bandsaw mill -- the blades were about 30 feet in diameter, about 1/8" thick, and 8-10" across. What was the problem? Apparently some of the control boards for the automatic sharpener had let out their magic pixies and so the machine had to be manually operated because there was no limit function or reset working. The part was obsolete, but I managed to find one and had it overnighted. Total cost: $271.86 shipped.

Meanwhile, I had the dead board sent to my office. I rebuilt it, made a new version in Eagle, and was ready to order new PCBs to have on stand-by.

So, for $283.56 I brought mill production from 15,000 BFD to 45,000 BFD. In other words, that investment made back $90,000 in lost productivity.... PER DAY.

I put together a massive SQL system to make it easier to run reports and track production, and had brought production back to 58,000 BFD when they sacked me for "spending too much money". I had spent just over $800 to get to this point. That $800 total earned back $129,000 in losses per day. But hey, I was spending too much money. They're virtually bankrupt now. Production is only a few thousand BFD a month now.

Good going Electromotive!  Every ops manager should read this.  Come to think of it, so should every developer.  Sometimes, we forget how much it costs per hour when a production line is down.
 
The following users thanked this post: electromotive


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf